JavaScript's Midlife Crisis: Rust Is Eating Its Toolchain
The JavaScript Midlife Crisis
JavaScript is everywhere, yet its own build tools are being rewritten in Rust, Go, and Zig for speed. The author argues this trade-off shrinks the pool of developers who can maintain the ecosystem and turns tools into black boxes. He questions how far this optimization can go before rebuilding the web from scratch looks saner.
We're laying increasingly faster tracks for a steam train that likes to take its time.
- Klonoar
> Rewrite a bundler in Rust and you haven't only made it faster. You've also shrunk the pool of JavaScript developers who can maintain it. The new tool still looks like a duck and quacks like a duck, but it's a different beast altogether. Its internals retreat behind a black box that fewer people hold the keys to. The source may still be open, but the door to contributions is closing.
Alternatively, there's a pool of JS developers who shouldn't be maintaining critical infrastructure to begin with.
It's not a black box, those codebases are usually open and the only thing holding you or anyone back is learning anything outside of a small pond of JavaScript.
Write non-browser-things in fast languages. It is not a complicated concept - even less so in an era where stuff is getting written for you.
- hexasquid
I'm interested to know why tsc (pre-go) would give me near-instant LSP diagnostics on a large typescript project, and rust-analyzer takes ages to produce diagnostics in a small rust project.
- msteffen
Heterodox argument: a big part of the reason JavaScript has been so successful is that interpreted languages actually can be extremely fast—competitive with, and in many cases, faster than compiled languages, with V8 arguably the fastest interpreter in existence.
See this post by Mike Pall, author of LuaJIT (which is comparable to or faster than V8 performance-wise, despite being basically a single-developer project), which explains why: https://web.archive.org/web/20180603053407/http://article.gm.... Basically, it’s much easier to add high-quality runtime-trace-aware recompilation to a JIT interpreter, which a non-trace-aware compiled language will often not be able to beat.