I don't see that as actually being true. There are thousands of native npm modules which work just fine with Electron. There's really no problem exposing native APIs to JS.
What VSCode has pioneered, and this is something which Atom got wrong, is a multi-process model, where the various IDE components communicate via IPC. This improves stability and allows isolation of 3rd party plugins, and provides mostly foolproof parallelism. When plugins are such a big part of the experience, this is a very good thing. It's a deliberate design decision, not some attempt to overcome the failings of JavaScript.
Couple this with the fact that limiting "API" to mean "C ABI" forces every compiler author to start exposing complex C structures, unsafe pointers and the like - which if their compiler is written in, say Haskell, or LISP is going to be particularly painful, v.s. implementing text-based RPC over a socket in whatever way is best for them.
If Language Server had been a C API then I seriously doubt it would have got much traction, as it's just too awkward for many compiler authors to implement. Unsafe C APIs are, frankly, last century's technology.
That's true for every combination of language / platform where the languages differ. Rewriting AST parsers for every language would be nuts. Overall this vastly increases accessibility / choice when it comes to languages. That's purely a good thing. People are still free to make hyper-optimized versions for whatever case they would like to.
jahewson|8 years ago
What VSCode has pioneered, and this is something which Atom got wrong, is a multi-process model, where the various IDE components communicate via IPC. This improves stability and allows isolation of 3rd party plugins, and provides mostly foolproof parallelism. When plugins are such a big part of the experience, this is a very good thing. It's a deliberate design decision, not some attempt to overcome the failings of JavaScript.
Couple this with the fact that limiting "API" to mean "C ABI" forces every compiler author to start exposing complex C structures, unsafe pointers and the like - which if their compiler is written in, say Haskell, or LISP is going to be particularly painful, v.s. implementing text-based RPC over a socket in whatever way is best for them.
If Language Server had been a C API then I seriously doubt it would have got much traction, as it's just too awkward for many compiler authors to implement. Unsafe C APIs are, frankly, last century's technology.
pjmlp|8 years ago
Which is why I see as positive the UWP, iOS and Android models regarding application extensions.
They might be more complex to implement than a straight unsafe C API, but that is exactly the goal, to be a safer alternative.
bpicolo|8 years ago