Comment by Klonoar
8 hours ago
> 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.
> 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.
I was with you until this paragraph, which is straight up incorrect. Language choice absolutely matters if your goal is performance.
The most obvious counterexample is that the TypeScript team pretty much did a direct port from TS to Golang, without significantly rewriting their core algorithms or changing their data structures, and it sped up the TS compiler by 10X, which is an enormous performance improvement that would be silly to dismiss as just a "constant." This is because JS is a bad choice of language for implementing a fast compiler, primarily due to its poor support for multithreading.
When did the love of learning disappear from this field? I remember when everyone i talked to was learning something new just to better themselves?
> When did the love of learning disappear from this field?
Like 10 years ago? When you could get a 400k/yr job after a 3 month JS boot camp. The market got flooded with people who don’t care about making good stuff. Now it’s the “AI has commodified intelligence so why learn anything” crowd
> When you could get a 400k/yr job after a 3 month JS boot camp.
I get the point but these numbers are hyperbole and do not happen in real life.
Or just write faster JS using it's lower-level language features. Nothing about whatever collection of build tools the JS ecosystem uses "requires" rust/zig/c++/go for performance. It's a closed text transform problem.
The native languages are easier to get decent performance for sure but, braking the entire ecosystem and a generation of future contributors, for what should realistically be single or low double digit percent gains is not worth it.
I think there's a huge spectrum between "pokes around in source code occasionally" and "maintains critical infrastructure." Learning to read and understand the open source software that powers a lot of the toolchain is a big part of the development of a lot of engineers, and said toolchain mostly not being written in a language you're familiar with is a barrier to that (not an insurmountable barrier, but still a barrier, to be clear).
I agree with you that the juice is worth the squeeze here, but I don't think it's right to pretend that there's absolutely zero cost in terms of the learning pathway for the next generation of open source contributors and maintainers.