Hacker News new | ask | show | jobs
by Klathmon 3486 days ago
Now I apologise if you've explained this elsewhere, but nowhere in your comment did you point out specific problems that you had with Babel 6.

You called it "unintuitive", "terrible", "frustrating", and said that it "broke the web", but you never explain how or why.

And I think that's part of the problem. It's one thing to suggest improvements, explain why something hurt, or how it caused an issue. It's another entirely to say again and again how much you personally dislike the project without offering anything of substance.

Personally, I think that you can suggest improvements, changes, fixes, or say how you would have prefered a change happen without the extra parts about how much you disliked or even hated the project.

Again, you could have explained this elsewhere, but without a link, a reference, or just reiterating the bullet points, it's going to come across as just more "bitching" which helps nobody.

As for another point of view, for me Babel 6 was a breath of fresh air. I waited a good couple months before updating, and found that it was easier to configure, easier to remove the parts I didn't need, quicker to setup, and overall just nicer to work with. To me it was a welcome change that I saw as Babel giving you an "out", paving the way for a day when you can incrementally remove babel from your pipeline and not have to deal with it again (opposed to the Babel 5 setup which was "all or nothing" unless you dove deep into the configuration hell). It had some fuckups (documentation was difficult at the beginning which is why I held off, and I still believe it has some holes with regards to exactly what some of the plugins do and what each one requires in terms of "polyfills" or other plugins), but nothing is free of problems, and despite all of the complaining about how it "broke the web" everything seems to have moved on fine. Even you yourself admitted it took you 3 days. While everyone involved thinks that's too long, and you are just one of many who had a similar story, in the long run is not that big of a deal.

I think there were things that everyone could have done better, and talking about those things specifically is going to be infinitely more helpful than any venting or rage will ever be.

1 comments

But why anybody even need a modular build tool? It's not like it is packed into final build, we don't need to shave off bytes. One size fits all works perfectly here. What is the killer use case for modularity?
You don't want to compile everything every time.

We target a platform that has arrow functions, we don't need to compile them in any more. Not a big deal for arrow functions, but a HUGE deal for async/await, or for-of statements (both of which will compile to a LOT of code which includes a pretty large amount of runtime-checking to work).

But there's also the fact that you do pack some of it into the final build. Many transformations include a lot of boilerplate, "helper" code, and in some cases big polyfills. Getting rid of those when possible is a huge bonus. And Babel 6 paved the way to allow you to incrementally remove those plugins one at a time as your target platform supported the feature natively (and at a speed that you are comfortable with). We currently only transpile async/await in one of our codebases, once that lands in node.js and is stable, babel will no longer be part of our pipeline. That's not something that we could have done easily with the Babel-5 system.

But it also takes babel from a "ES6 -> ES5" tool and makes it a general compiler. Babel now has plugins that will minify the code, plugins that will drop dead code, plugins that can perform "GCC style" optimizations in terms of IIFE removal, constant inlining, loop-unrolling, and more. Before the Babel-6 change, all of that would either need to package it's own AST parsing, or it's own bastardized version of babel. Now it's as easy to write plugins that do things like remove the prop-type code from a React project [0], or eliminate unnecessary closures [1].

There's also the ability to save space and install time on the developer machine. Not that big of a deal to me, but I hear others complain about it from time to time.

But those are just the reasons why I like that it's modular.

[0]https://github.com/oliviertassinari/babel-plugin-transform-r...

[1]https://github.com/codemix/babel-plugin-closure-elimination

Thank you, this is actually a great explanation.