I love JavaScript and TypeScript, but like all interpreted languages, they really do have a hard time fitting into certain environments where you can't get an enormously complicated VM or can't get by with a much slower version of the language.
You can argue that high-throughput / low-latency dev tools are one of these environments. I'm not so sure. I think a lot of JS tooling is written in slow JS and gets fast with a rewrite to another language largely because of better structure.
Some environments really are tougher though. I started using WebAssembly a lot a year ago and the story for JavaScript and Python is just pretty terrible. And for JS, the things that make it hard to run in Wasm aren't universally good things to have in the language in the first place. The extreme dynamism of JS is something that so much JS tooling tries to limit.
But I think a lot of the language is quite good, and that there are possible variants of JS that are great even. I started one I hope will fit that one day (https://zena-lang.dev) and the first use cases for me are all tooling to try to make sure it's at least good for that: self-hosted compiler, formatter, regex engine, JSON parser, etc. It's quite a bit like JS/TS, but fixes a lot of things and runs forward with features that will take JS many years to get to, if it ever does (ie, pipelines, pattern matching).
I'm hoping that WebAssembly can slowly continue to gain a place on the web so JS can give up its near monopoly there. We'll see!
> 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.
Absolutely agree. If a JS developer doesn't know Rust, Go, Zig, or something, then they probably aren't going to do a good job at maintaining critical infrastructure, even if it were written in JS.
Why are people writing "critical" infrastructure in JS anyway, it is the wrong tool for the job.
Why are people writing critical infrastructure in [any language]?
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.
> 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.
when i first started learning programming i thought it was super important to pick one language to be really good at and that could do everything but you dont have to pick just one.
i honestly think learning it opened my mind to thinking about programming differently and is probably better in the end
You can argue that high-throughput / low-latency dev tools are one of these environments. I'm not so sure. I think a lot of JS tooling is written in slow JS and gets fast with a rewrite to another language largely because of better structure.
Some environments really are tougher though. I started using WebAssembly a lot a year ago and the story for JavaScript and Python is just pretty terrible. And for JS, the things that make it hard to run in Wasm aren't universally good things to have in the language in the first place. The extreme dynamism of JS is something that so much JS tooling tries to limit.
But I think a lot of the language is quite good, and that there are possible variants of JS that are great even. I started one I hope will fit that one day (https://zena-lang.dev) and the first use cases for me are all tooling to try to make sure it's at least good for that: self-hosted compiler, formatter, regex engine, JSON parser, etc. It's quite a bit like JS/TS, but fixes a lot of things and runs forward with features that will take JS many years to get to, if it ever does (ie, pipelines, pattern matching).
I'm hoping that WebAssembly can slowly continue to gain a place on the web so JS can give up its near monopoly there. We'll see!
reply