Feature Request: Visual Studio Code Support for Jmix

Hello Jmix Team and Community,

I’m writing to request the official development and support for a Visual Studio Code (VS Code) extension or standalone studio for Jmix projects.

Currently, Jmix’s powerful development experience is primarily centered around IntelliJ IDEA via the Jmix Studio plugin. While IntelliJ is a fantastic IDE, native support for VS Code would be a massive benefit for a large portion of the developer community.

Key Benefits of VS Code Support:

  • Wider Adoption: Many developers, especially in the JavaScript/TypeScript and general web development ecosystems, prefer the lightweight nature and speed of VS Code.
  • Alternative IDEs: VS Code’s extension architecture and growing popularity mean many development teams are standardizing on it, and its adoption continues to rise across all languages.
  • Future-Proofing for Cloud/Remote Development: VS Code is perfectly suited for modern development workflows, including:
    • GitHub Codespaces (or similar cloud IDEs).
    • Remote Development via SSH.
    • Self-hosted open-source platforms like Coder (using Cursor or Antigravity/Gitpod-like environments).

Supporting VS Code would allow Jmix to tap into these cutting-edge, remote-first development environments, significantly enhancing the platform’s versatility and appeal.

Suggestion:

We would love to see a Jmix Studio experience (or a highly functional extension) that replicates the core functionality currently available in the IntelliJ plugin—especially the visual designers and configuration helpers—within the VS Code environment.

Thank you for considering this request. I believe this would be a significant step in expanding the reach and adoption of the Jmix platform.

What are your thoughts on this possibility?

I think that the problem is that for IntelliJ IDEA, JetBrains Marketplace is in place with its features like built-in DRM that enables Jmix to sell commercial add-ons. For VS Code they would need to bring up their own Licensing server, and then allocate development resources to develop and maintain Jmix Studio for both IntelliJ and VS Code ecosystems. Since IntelliJ IDEA has a free tier that Jmix Studio can work on, there would need to be some compelling reason to diversify from JetBrains…

There is also talk about IntelliJ being an IDE, while VS Code is an editor with plugins that is made to act like IDE.

1 Like

VS Code became widespread largely because many mature IDEs such as IntelliJ IDEA Ultimate, WebStorm, GoLand, PHPStorm, and others are commercial products, while VS Code is free. At the same time, calling VS Code a fully-featured IDE is difficult. The editor itself provides almost no native language intelligence: VS Code is essentially just a client for external LSP servers, and all real language functionality must be implemented by the language developers.

This architecture makes it simple to plug in basic language support, but brings severe limitations when deeper framework-level integration is required. There is no unified API for working with ASTs, and building advanced features on top of LSP quickly becomes impossible. To support something like Jmix, one would effectively need to modify or fork the Java LSP server. This is similar to how advanced Angular or Vue extensions end up embedding large parts of the TypeScript LSP. VS Code extensions are simply not designed to be extensible at that level.

Another issue is UI. VS Code has almost no built-in UI toolkit for extension authors. Beyond a minimal set of controls, developers must build their own UI in arbitrary web technologies. This offers flexibility, but provides no real foundation for building complex IDE tooling, which frameworks like Jmix rely on.

Considering these architectural constraints, providing meaningful, deep Jmix support inside VS Code would require enormous effort: maintaining a specialized Java LSP fork and building custom UI infrastructure from scratch. From a technical standpoint, it’s not a practical direction.

Finally, speaking personally: VS Code is, in my view, a very poor environment if you are developing in Java or Kotlin. It works well for lightweight scripting and web technologies, but for JVM languages its architecture is fundamentally the wrong fit.

7 Likes

Thanks Alexander,
will keep this in my Notion for future answers :slight_smile:

1 Like