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.

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.

We have a total of 18 people on the WebStorm team. The team is cross-functional and includes developers, QAs, product and product marketing managers, tech writers, and developer advocates. In fact, speaking of developer advocates, we are looking for one right now.

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.

We have lots of sources of ideas for what we include in the roadmap:

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).

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.

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.

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.

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.

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.