However, these tools arenโt necessarily faster because theyโre using a faster language. They could just be faster because 1) theyโre being written with performance in mind, and 2) the API surface is already settled, so the authors donโt have to spend development time tinkering with the overall design. Heck, you donโt even need to write tests! Just use the existing test suite from the previous tool.
In my career, Iโve often seen a rewrite from A to B resulting in a speed boost, followed by the triumphant claim that B is faster than A. However, as Ryan Carniato points out, a rewrite is often faster just because itโs a rewrite โ you know more the second time around, youโre paying more attention to perf, etc.
In the world of Node.js scripts, we donโt get the benefits of the bytecode cache at all. Every time you run a Node script, the entire script has to be parsed and compiled from scratch. This is a big reason for the reported perf wins between JavaScript and non-JavaScript tooling.
Most developers ignore the fact that they have the skills to debug/fix/modify their dependencies. They are not maintained by unknown demigods but by fellow developers.
This breaks down if JavaScript library authors are using languages that are different (and more difficult!) than JavaScript. They may as well be demigods!
For another thing: itโs straightforward to modify JavaScript dependencies locally. Iโve often tweaked something in my local node_modules folder when Iโm trying to track down a bug or work on a feature in a library I depend on. Whereas if itโs written in a native language, Iโd need to check out the source code and compile it myself โ a big barrier to entry.
That said, I donโt think that JavaScript is inherently slow, or that weโve exhausted all the possibilities for improving it. Sometimes I look at truly perf-focused JavaScript, such as the recent improvements to the Chromium DevTools using mind-blowing techniques like using Uint8Arrays as bit vectors, and I feel that weโve barely scratched the surface.
I also think that, as a community, we have not really grappled with what the world would look like if we relegate JavaScript tooling to an elite priesthood of Rust and Zig developers. I can imagine the average JavaScript developer feeling completely hopeless every time thereโs a bug in one of their build tools. Rather than empowering the next generation of web developers to achieve more, we might be training them for a career of learned helplessness. Imagine what it will feel like for the average junior developer to face a segfault rather than a familiar JavaScript Error.
From Why Iโm skeptical of rewriting JavaScript tools in โfasterโ languages | Read the Tea Leaves