I'm suggesting that JS is not good for every possible use. And that is ok.

I would not want a core internet router or a kernel to be implemented in JS. But I am happy it is used elsewhere.

So for context my beef with them is that they didn't try. I think you're being very "hand wavey" about why JS isn't a good host language, just as they were.

If the argument is that it's not fast enough, JS is actually quite fast: https://mrale.ph/blog/2018-02-03-maybe-you-dont-need-rust-to...

If the argument is "we need to show a 10x boost in raw throughput" then I think we first need to have an argument about why throughput is the right metric as a target for optimization. Throughput is the critical performance measure of a batch processing architecture. IDE's, like web UIs, "feel fast" when they're responsive, which is to say when they can start giving the user access to useful output (and interaction) at the soonest moment the program could possibly be ready to do so. In web perf we might measure this as INP or the time it takes from Interaction to Next Paint.

JS won't be winning prizes for throughput, no, but if we completed the move away from a batch processing mindset to an incremental recomputation mindset, and at the same time switched to measuring responsiveness metrics like INP, suddenly the perf characteristics of JS seem a lot more helpful. It's the closest language to the DOM, so when your IDE's interface is built on web technology you'll optimize INP by keeping the data layer in JS: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...

There's an even stronger reason than the DOM though to see JS as the "native" layer for perf: plugins. An IDE's selling point is integration, and users want to extend their IDEs by writing Javascript code. Like it or not, JS is the most natural and highly-performant native kernel language for a system of JS plugins.