Interview with webstorm: how do we build JavaScript ide?


Building an IDE is an extensive and complex project. It seems obvious, right? But have you ever thought about how all kinds of fragmentary things are combined into a unified environment? What’s going on under the engine? These are some of the most interesting questions.

I sat down with Ekaterina prigara, product manager of webstorm, and talked in detail about webstorm itself, how we build it, and our plans for the future.

Hi, Ekaterina! Let’s start by talking about your role in the webstorm team. What are your responsibilities?

I help the team define product strategies and manage product roadmaps.

I try to analyze and validate ideas and use cases from various sources. Then I brought them back to the team and some insight into what’s going on in the web development ecosystem.

When necessary, I help my colleagues prioritize features and bug fixes, advise on user experience, and coordinate tasks with the IntelliJ platform team.

How big is the webstorm team?

The webstorm team consists of 18 people. The team is cross functional and includes developers, QA, product and product marketing managers, technical writers and developer advocates. In fact, when it comes to developer spokesmen, we’re looking for one right now.

What do IntelliJ platform, IntelliJ idea, webstorm and other JetBrains ides have in common?

Webstorm is built on the open source platform developed by JetBrainsIntelliJ platformabove. Webstorm gets its UI and many features from the IntelliJ platform, such as core editor and git integration. More than 130 people on JetBrains are using the platform, and the webstorm team works closely with them.

At the same time, the functions of webstorm can also be used in other commercial JetBrains ides, such as IntelliJ idea ultimate, phpstorm and pychar professional. In this sense, webstorm itself is not only a stand-alone product, but also a part of all JetBrains ides.

Like most JetBrains products, webstorm comes in three versions a year. How do you come up with ideas about what’s included in the new version? And how do you determine which features don’t work?

We have many sources of ideas about what the roadmap contains:

  • User feedback comes from various channels, such as problem tracker, social media, technical support and user experience research interviews.
  • Other ides and editors, including our own ides in different languages.
  • Personal experience of product team members.
  • The changes we observe in the development ecosystem, such as the emergence of new frameworks, tools, methods, and best practices.

Our roadmap is consistent with our higher-level goals for webstorm and a range of products based on the IntelliJ platform. However, we don’t have a formal way to prioritize. We use a variety of techniques (such as rice) to help us prioritize our tasks, and we often rely on our intuition and experience.

Our roadmap is very flexible. If we feel that the new features are not ready, or there is a more urgent situation (for example, there is an interrupted change when the new framework is released), we will not hesitate to delay the release of the new features.

How do you decide to release high quality products?

We have a full range of quality assurance engineers who work closely with developers. Generally speaking, we have about a month to actively develop and test new versions. QA engineers test new functions and changes as they develop them and look for possible regression. They also work with others on the team to assess the availability of new features and look for missing use cases.

We also started with participating in the early visit program(Early Access Program)”Get early feedback on the new features from users of, and the program will be implemented in each major release.

Let’s continue to discuss more difficult issues. Is JavaScript and its framework developing rapidly and hard to keep up with?

Yes, a lot has happened in the JavaScript ecosystem over the past few years. Even after seven years of working with the webstorm team, I’m still very excited about the emergence of new technologies and the transformation of patterns. JavaScript has come a long way and has become a truly powerful language, let alone typescript.

The biggest challenge for our team is to be very pragmatic about the framework. We and our users have reason to have high expectations for the framework support level in IDE. In order to achieve this level, we need to invest months or even years of development funds. Knowing this, we often try not to rush to support new frameworks. We need to choose based on what we think will be the next big event. Sometimes they don’t succeed, but we try to learn from our mistakes.

In your opinion, if any, which emerging JavaScript related frameworks and technologies are the most promising or interesting?

Ha ha, I have many opinions on various technologies, but when deciding whether webstorm supports a certain technology, I try to be objective and bring the number to the desktop.

One of the things that excites me recently is tailwind. I was a little skeptical at first, but I can understand why it’s so popular.

How do you think webstorm will change in the next few years? Do you have any new directions to explore?

One of our main concerns at the moment is to ensure that experienced and less experienced developers get a good first impression when they start using webstorm. We want ide to be user-friendly and easy to use. At the same time, we hope it can help users better understand their projects and become better developers, no matter what technology they use or what level of experience they have.

We also hope that ide can explain how to run and debug applications, provide insights on code operability, and so on. Balancing simplicity, discoverability, and guidance in the UI is one of the biggest challenges we face.

Is there anything you can share with us about your plan for this year? What are your most exciting features or improvements?

A lot of different things. AndCode With MeCooperative development, improve the experience of running and debugging code on docker and remote machines, improve sharing settings, etc.