Hacker News Reader

Comment by Klathmon | Hacker News Reader

I know that it's possible, but what's the purpose?

Is anyone's quality of life really impacted by the size of babel vs buble?

Does the size of a compiler really change anything for the average developer (obviously within reason)?

I personally don't care but I've had super long install times when using slow internet—which in many parts of the world is the standard speed. I'll keep using Babel, but I like that there are alternatives that install faster if need be.

I agree. Also there are multiple ways that you can install these things.

The "recommended" way is to install babel for each project independently. Space is cheap, internet speeds are fast for many, and avoiding version issues outweighs the savings.

But you can install globally, so you'd install babel once and can use it in all projects that way.

Then throw in the possibility of different package managers and you get a crazy amount of freedom and choice. People get overwhelmed with "javascript fatigue" and I just don't get it. You don't need to do everything, but having the option to is amazing.

I believe NPM also caches your file locally. So the second install of babel would 304 from GitHub and get pulled from your local cache, saving time and bandwidth.

Buble's purpose is that it is supposed to be significantly faster to compile from ES6 to ES5 with minimal configuration, since it actually does things out of the box.

But that has nothing to do with it's size. If Buble was 10% larger than Babel it would still solve it's purpose.

That's right, Buble's secret sauce to being fast is that is skips the code generation step, not because of the number of dependencies.

Although there definitely is a performance cost to Babel's large dep tree as each of these modules have to be found by Node (which is inefficient). If you use Babel with npm2 it is super slow, because npm2's folder structure causes more lookups.

We ship Babel built in with the AVA[1] test runner and I can confirm `babel-require` is our bottleneck.

[1] https://github.com/avajs/ava

Yeah, I think that was a bit of a mistake by you guys. AVA's entire point is to be fast but it has the perception of being slow because you've made transpiling a core feature. I would drop that and let people do their own transpiling.

Aside from the concurrent testing, Babel with async functions built-ins is our second biggest "bullet point", so even if you were right it's too late. AVA is opinionated and I think the benefits (from what people have told us) gained from using the latest syntax with no Babel config are worth the Babel bottleneck—which isn't that bad.

Reply on news.ycombinator.com