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 w

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.