Why are people writing "critical" infrastructure in JS anyway, it is the wrong tool for the job.
In reality, the tools this article is referring to were written in javascript because they could be and it was the best tool for the job (according to the people who matter: the people who did the work).
If someone wants to rewrite them for speed and/or to chase the next shiny language, that's fine with me, but let's not kid ourselves that there was something wrong with using javascript in the first place.
Using the right abstractions (including the right number of abstractions) and the right data structures and algorithms is always going to trump the constants language choice can optimize.
I was with you until this paragraph, which is straight up incorrect. Language choice absolutely matters if your goal is performance.
The most obvious counterexample is that the TypeScript team pretty much did a direct port from TS to Golang, without significantly rewriting their core algorithms or changing their data structures, and it sped up the TS compiler by 10X, which is an enormous performance improvement that would be silly to dismiss as just a "constant." This is because JS is a bad choice of language for implementing a fast compiler, primarily due to its poor support for multithreading.
Given that we've now got a three way language schism, the story for sharing data between processes isn't really solved. Data can move nicely within Go, but not between Go and Rust or JS. Tools like ts-morph also got left behind with no replacement.
I think that in retrospect the power of the JS ecosystem was all about plugins. It's plugins that make ESLint such a powerful platform that it still can't be replaced.
From the perspective of making a efficient platform for running plugins, JS actually is the most theoretically efficient implementation language! That's why, for example, VSCode put a bunch of work into moving its core state from C++ to JS, a change which brought them big perf wins and helped them beat out Atom: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...
The thing is if you need to do big expensive copies on the input or output it forces you towards a batch processing model, which is the opposite of incremental computation.