4 ms·

> Meanwhile, JetBrains seems to be staying afloat mostly thanks to hard work and sheer luck. I don't think they keep ahead simply by hard work and sheer luck.

> Meanwhile, JetBrains seems to be staying afloat mostly thanks to hard work and sheer luck. I don't think they keep ahead simply by hard work and sheer luck. Once you look under the hood at Intellij it's clear that they have significant architectural advantages. While VS Code is a text editor that uses LSPs to provide refactoring and navigation, Intellij is a refactoring engine with a good text editor on the front. Under the hood Intellij is a structured editor operating on abstract syntax trees. ("psi nodes" in Jetbrain's parlance.) The hard part of creating an LSP is providing things like refactoring and navigation support, and these are exactly the things that IntelliJ provides for its language plugins. To achieve a given level of refactoring and navigation support an LSP developer needs to expend significantly more effort than a jetbrains plugin developer. From my vantage point Jetbains doesn't seem to be staying ahead by hard work and luck as much as by an intelligent architecture and design that allows them to produce high-level, high-value features with less effort. [ It's worth looking at IntelliJ's plugin SDK. https://plugins.jetbrains.com/docs/intellij/psi.html https://plugins.jetbrains.com/docs/intellij/psi.html ]

aasasd 6y ago
Thanks for this comment. This analysis of the internals is much more informative than vague divination that the post author pulls from their gut.
- thu2111 6y ago
  We can expand on this analysis a bit. IntelliJ runs its language plugins in-process, using object oriented APIs. VS Code runs language plugins out-of-process with an RPC protocol to the backend. The latter has some advantages if you want to re-use the language's "native" compiler, assuming there is one. However, this isn't quite as useful as it sounds. Compilers parse text into ASTs and do transformations on them, yes, but, they are not IDEs and the needs of an interactive "presentation compiler" are very different to the needs of a batch-oriented normal compiler. The OP's article overlooks this: it just blithely assumes that building an IDE on top of the regular compiler is always better than writing a dedicated IDE support from scratch. The truth is more nuanced. Meanwhile, the costs of going out-of-process with RPC are enormous. Beyond the obvious performance, bandwidth, memory overhead and latency problems, the Language Server Protocol spec is 100 pages long and still growing. Despite being a protocol and thus theoretically language neutral, in reality it's a JS/TypeScript API. In fact the protocol is so much a JavaScript API that there's no direct way to represent it in a conventionally typed language: for example the Response.result field is totally dynamically typed and can be anything at all. Worse, because LSP is just a protocol, there's no platform to help you implement it. IntelliJ platform is full of classes you can compose, subclass or use to simplify the task of writing plugins. VSCode is not like that.

aasasd 6y ago

Thanks for this comment. This analysis of the internals is much more informative than vague divination that the post author pulls from their gut.

thu2111 6y ago
We can expand on this analysis a bit. IntelliJ runs its language plugins in-process, using object oriented APIs. VS Code runs language plugins out-of-process with an RPC protocol to the backend. The latter has some advantages if you want to re-use the language's "native" compiler, assuming there is one. However, this isn't quite as useful as it sounds. Compilers parse text into ASTs and do transformations on them, yes, but, they are not IDEs and the needs of an interactive "presentation compiler" are very different to the needs of a batch-oriented normal compiler. The OP's article overlooks this: it just blithely assumes that building an IDE on top of the regular compiler is always better than writing a dedicated IDE support from scratch. The truth is more nuanced. Meanwhile, the costs of going out-of-process with RPC are enormous. Beyond the obvious performance, bandwidth, memory overhead and latency problems, the Language Server Protocol spec is 100 pages long and still growing. Despite being a protocol and thus theoretically language neutral, in reality it's a JS/TypeScript API. In fact the protocol is so much a JavaScript API that there's no direct way to represent it in a conventionally typed language: for example the Response.result field is totally dynamically typed and can be anything at all. Worse, because LSP is just a protocol, there's no platform to help you implement it. IntelliJ platform is full of classes you can compose, subclass or use to simplify the task of writing plugins. VSCode is not like that.