←back to thread

Skeptical of rewriting JavaScript tools in "faster" languages

(nolanlawson.com)
160 points todsacerdoti | 2 comments | 20 Oct 24 21:25 UTC | HN request time: 0s | source
Show context
noname120 ◴[20 Oct 24 22:04 UTC] No.41898858[source]▶
> I just don’t think we’ve exhausted all the possibilities of making JavaScript tools faster

Rewriting in more performant languages spares you from the pain of optimization. These tools written in Rust are somehow 100× as fast despite not being optimized at all.

JavaScript is so slow that you have to optimize stuff, with Rust (and other performant languages) you don't even need to because performance just doesn't bubble up as a problem at all, letting you focus on building the actual tool.

replies(6): >>41898915 #>>41898923 #>>41898937 #>>41898975 #>>41901141 #>>41901628 #
1. strken ◴[21 Oct 24 06:11 UTC] No.41901141[source]▶
I really don't think the problem is JavaScript in all these cases. I've seen codebases using webpack where the JS was being run through babel twice in a row, because webpack is a complicated nuisance and nobody on the team had gotten around to fixing it. You can't blame that on V8 or node being slow.
replies(1): >>41906721 #
2. WorldMaker ◴[21 Oct 24 18:08 UTC] No.41906721[source]▶
It's also fascinating how many developers got so burnt on IE11- compatibility issues and feel a need to use Babel as a comfort blanket still. Babel does so very little now with reasonable, up-to-date Browserlist defaults (but still takes a lot of time to do so very little), but the number of developers unwilling to drop Babel from their build pipelines is still to me so surprisingly high. Babel was a great tool for what it did in the "IE11 is still an allowed browser" era, but you most probably don't really need it today.