> 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.
show comments
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.
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
hackersnooze1
tldr: interpreted languages are still slower than compiled languages, surprising no one
sublinear
> Rust, Go and Zig are taking over increasingly large parts of the JavaScript toolchain...
> 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.
> 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-...
i enjoyed learning go. not that far from js
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
tldr: interpreted languages are still slower than compiled languages, surprising no one
> Rust, Go and Zig are taking over increasingly large parts of the JavaScript toolchain...
Found it.