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.
- cisc
> I start wondering what we're supposed to do with all those precious milliseconds it just handed us back
Speed matters. WebAssembly is taking jobs from JavaScript precisely because it's faster.
The calculation engine for Google Sheets became twice as fast with the switch to WebAssembly: https://web.dev/case-studies/google-sheets-wasmgc
The Amazon Prime Video app became twice as fast with less variability in performance when they switched to WebAssembly: https://www.amazon.science/blog/how-prime-video-updates-its-...
Compiling to WebAssembly enables every language to run in the browser. Google used Java and Amazon used Rust.
- 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.
- nzoschke
> Rust, Go and Zig are taking over increasingly large parts of the JavaScript toolchain...
Large parts of the JavaScript application space too.
Language consistency, ergonomics, standard library and performance matters, and JS has major warts here. I bet when these languages are 30+ years old like JS is, the software landscape isn't dominated nearly as much by JS.
These days I intentionally start all projects with as little JS as possible, opting for Go and HTMX instead. Removing the layers of JS inconsistency and build tools makes my and my agents lives better.
More thoughts on my JS-less stack here: https://housecat.com/blog/the-hugs-stack-hypermedia-unix-go-...
- hn_submit
JavaScript is an abomination that never should've been left alive.
And yes, I ask myself the question: "Who in his right mind would run JavaScript on the server and even write business logic in it?" Lots of idiots in this world it seems. JavaScript is the reason our text editors need 16GB of RAM to run these days and a simple weather app 1GB.
In the ol' days assembly programmers probably could've written the weather app in a couple of KB (that's a MILLION times less memory people).