[throwaway284534]

I do appreciate your transparency, though I disagree with the sentiment that I’m arguing from a position of bad faith.

The Babel team has not shown a moment of interest in lowering their role in the JavaScript ecosystem to anything short of kingmakers. I think the facts are self-evident, but I can easily back up my claims by citing pretty much any document the team has ever produced. Have a gander at their GitHub README and what do we see?[1]

- “Babel is a compiler for writing next generation JavaScript.” I suppose they left out “indefinitely” to avoid the obvious. Don’t forget, you’re here forever.

- Over a dozen sponsor logos. An embarrassment of riches.

- A literal audio recording of a song in praise of the project. The call is coming from inside the house, people!

The Babel team has a well documented history of their priorities[2], emphasizing the need for a modular approach that has no exit strategy[3]. At best, we have a case of accidental entrenchment and long term dependence on Babel brewing as early as 2017![4] At worst, we have a group of aspiring Carmack-wannabes looking for their big break into the incestuous and lucrative class of technorati standards committees.

Don’t believe me? It doesn’t take an inner-join on the TC39 roster and the Babel maintainers to see our own version of regulatory capture forming right before our eyes.

Compare this infinite circus to the humble but popular Normalize.css, which has the express purpose to stop existing.[5]

If the Babel team wants to raise some money, they can start by putting a plan together that would codify an exit strategy. It’s certainly more noble than their current plan of barnacling onto every NPM package…

- [1] https://github.com/babel/babel

- [2] https://github.com/babel/notes

- [3] https://github.com/babel/notes/blob/master/2016/2016-07/july...

- [4] https://github.com/babel/notes/blob/master/2017/2017-04/apri...

- [5] https://nicolasgallagher.com/about-normalize-css/

[daveidol]

How would Babel stop existing though if JavaScript keeps evolving?

Is the goal that we all are using evergreen browsers and versions of Node and thus have no need to support older runtimes?

[throwaway284534]

That is a wonderful question and is exactly the sort of thing that should be on the Babel website. You’ll find no such explanation or even a summary of trade offs that come with adding Babel to your app.

It’s assumed that if you want to support older browsers, the next logical step is to add Babel…forever. An incredible trick happens here, where the developer thinks they added the magic package which only bears a “tax” on the poor sap who’s stuck on Internet Explorer, presumably running eye watering amounts of polyfills on 32 bit limits of RAM.

In my opinion, the Babel team should start looking for a strategy that aligns with a world of evergreen browsers, and untangle the web of feature polyfills from syntax transformations.

It’s also not too wild to think that Babel is a symptom of a larger problem. JavaScript lacks a versioning mechanism when new features are added. A more self-aware Babel could use their connections with the TC39 team do what all successful JavaScript libraries do: become part of the standard library a la jQuery and CoffeeScript.

Alternatively, reconsider the velocity that Babel introduces to the JavaScript ecosystem. These tools might actually be self perpetuating their existence by making new features so readily accessible.

[whstl]

Well, that is the ultimate goal for some people.

With evergreen browsers it's not only about features, but also about security. If you can't update your browser to have arrow functions, you might have security issues. So it is in everyone's best interest that old browsers have yet another reason to be updated.

Also it can be argued that Babel gave IE11 a huge afterlife. IE11 support should have been dropped by the javascript community much sooner, and IE11 should have been used only for legacy apps, as Microsoft tried to. But tools like Babel made it possible for managers to say "c'mon just use Babel".

Also, while it is convenient to have Javascript features before they're available in Browsers, in practice the wait time is not as long as it was. And having a tool removes pressure (including internal pressure) for browsers companies to be fast.

And also: normally, projects using Babel have to pull hundreds of babel-related packages. The biggest complaints you see here on Hacker News about the Javascript ecosystem center around the massive number of packages. Well, guess what: Babel by default on create-react-app needs 133 packages.