Hacker News new | ask | show | jobs
by sunflowerdeath 1863 days ago
Obviously, it's great that we get tools that provides such improvements, but somehow I feel that JS should not be that slow. I expect it to be about 3 to 5 times slower than lower-level languages, but when the difference exceeds 10 times, it means that the Babel's code is not written very efficiently. Another thing, is that usually you only need to optimize a few critical places, and that will give the biggest improvement. So I wonder if it is possible to optimize or rewrite some parts of Babel into a faster language, but keep all of its extensibility and ecosystem. Maybe projects like esbuild or swc will provide insights for Babels' team.
2 comments
devongovett 1863 days ago
Yep, this is true. In fact, we already improved performance by over 25x by optimizing algorithms in JavaScript. As covered in the blog post, this rewrite was motivated by more than just performance and does include algorithmic improvements as well. We figured that while we were rewriting we might as well also use a language with more predictable performance traits. But, your points about extensibility does still stand, and that's something we hope to look into more in the future.
link
hajile 1863 days ago
Sucrase is what you're looking for. When converting to ES6+, it's actually almost 2x as fast as esbuild on a single thread (though slower in aggregate).

As they point out, there's a JIT warmup time. Testing against small projects that don't allow this makes JS transpilers look much worse than they actually are in real-world projects.

https://github.com/alangpierce/sucrase

https://github.com/alangpierce/sucrase/blob/main/benchmark/b...

link
jiofih 1863 days ago
Sucrase is quite fast indeed, but some of the trade-offs make it a very difficult choice. It will silently compile invalid JS, and is not easily extensible, so you’ll end up bringing in more tooling on top of it to support things like css modules or a framework like svelte. I don’t think it will survive for long.

It’s for good reason that the docs end on this note:

> You should think carefully before using Sucrase in production. Sucrase is mostly beneficial in development, and in many cases, Babel or tsc will be more suitable for production builds.

link