WebStorm Under the Hood: How We Build Our JavaScript IDE
Building an IDE is an extensive and complex project. That seems obvious, right? But have you ever wondered how the various bits and pieces come together to form a unified environment? What is going on under the hood? These are some of the most interesting questions.
I sat down with Ekaterina Prigara, WebStorm Product Manager, for a detailed discussion about WebStorm itself, how we build it, and our plans for the future.
Hi Ekaterina! Let’s start by talking about your role on the WebStorm team. What are your responsibilities?
I help the team define the product strategy and manage the product roadmap.
I try to analyze and validate the ideas and use cases we get from various sources. Then I bring them back to the team, along with some insights about what’s going on in the web development ecosystem.
When necessary, I help my colleagues prioritize features and bug fixes, offer advice on the UX, and coordinate tasks with the IntelliJ Platform team.
How big is the WebStorm team?
We have a total of 19 people on the WebStorm team. The team is cross-functional and includes developers, QAs, product and product marketing managers, tech writers, and developer advocates.
What do the IntelliJ Platform, IntelliJ IDEA, WebStorm, and other JetBrains IDEs have in common?
WebStorm is built on top of the open-source IntelliJ Platform developed by JetBrains. WebStorm gets its UI and many features, such as the core editor and Git integration, from the IntelliJ Platform. There are over 130 people at JetBrains working on the platform, and the WebStorm team works closely with them.
At the same time, WebStorm’s features are available in the other commercial JetBrains IDEs, such as IntelliJ IDEA Ultimate, PhpStorm and PyCharm Professional. In that sense, WebStorm itself is not only a standalone product, but a part of all JetBrains IDEs.
Like most JetBrains products, WebStorm has 3 releases each year. How do you come up with ideas on what to include in the new releases? And how do you decide which features don’t make the cut?
We have lots of sources of ideas for what we include in the roadmap:
- Feedback from users, which comes through various channels such as the issue tracker, social media, tech support, and UX research interviews.
- Other IDEs and editors, including our own IDEs for different languages.
- The personal experiences of members of the product team.
- Changes we observe in the development ecosystem, like the appearance of new frameworks, tools, approaches, and best practices.
We align our roadmap with the higher-level goals we set for WebStorm and for the range of products built on the IntelliJ Platform. However, we don’t have a formal approach to prioritization. We use a variety of techniques (for example, RICE) to help us prioritize our tasks, and we often rely on our intuition and experience.
Our roadmap is pretty flexible. We won’t hesitate to delay features until the next release if we don’t feel they are ready or if something more urgent pops up (e.g. breaking changes in the new framework release).
How do you make sure you release a high-quality product?
We have a whole team of quality assurance engineers working closely with developers. In general, we have about a month of active development and testing for a new release. QA engineers test new features and changes as they are developed and look for possible regressions. Together with other people on the team, they also evaluate the usability of the new features and look for missing use cases.
We also get early feedback on new features from our users participating in the Early Access Program, which we run for every major release.
Moving on to more difficult questions. JavaScript and its frameworks are evolving rapidly. Is it hard to keep up?
Yeah, lots of things have been happening in the JavaScript ecosystem over the past few years. Even after 7 years working on the WebStorm team, I’m still very excited about the new technologies that appear and the paradigm shifts that happen. JavaScript has come a long way and has become a truly powerful language. And that’s not to mention TypeScript.
The biggest challenge for us as a team is to be very pragmatic about the frameworks. We and our users all have justifiably high expectations for the level of the framework support in the IDE. To achieve this level, we need to invest months and often years of development. Knowing that, we often try not to rush into providing support for a new framework. We need to make our choice based on what we believe is going to be the next big thing. Sometimes they don’t pan out, but we try to learn from our mistakes.
In your opinion, what up-and-coming JavaScript-related frameworks and technologies, if any, are the most promising or interesting?
Haha, I have a lot of opinions about various technologies, but I try to be as objective as possible and bring numbers to the table when it comes to deciding whether to support a technology or not in WebStorm.
One of the things I’ve been excited about lately is Tailwind. I was a bit skeptical at first, but I can understand why it’s becoming so popular.
How do you see WebStorm changing in the coming years? Are there any new directions you want to explore?
One of our main focuses at the moment is making sure experienced and less experienced developers get a good first impression when they start working with WebStorm. We want the IDE to be user-friendly and easy to get started with. At the same time, we also want it to help users better understand their projects and become better developers, no matter what tech they use or what level of experience they have.
We also want the IDE to be able to explain how to run and debug the app, provide actionable insights about the code, and so on, too. Balancing simplicity, discoverability, and guidance in the UI is one of our biggest challenges.
Is there anything you can share with us about your plans for this year? What features or improvements are you most excited about?
Lots of different things. Collaborative development with Code With Me, improvements to the experience of running and debugging code in Docker and on remote machines, improvements for sharing settings, and much more.
That’s it for this interview, we hope you enjoyed it! If there is anything else you’d like to learn about WebStorm, let us know.
The WebStorm team
Subscribe to WebStorm Blog updates
