Nearing the Babel 7.0 Release

I think this need not even be framed just as "the moral thing to do" - in an environment where attracting quality engineers is a continuous challenge, small "sacrifices" like this can be far more effective than spending the same amount of money on raising the potential wage. If a job lists "contribute to Babel maintenance one <time unit> every <time unit>" as one of the responsibilities, that'd make me far more interested.

It's more nuanced than that I'm afraid. I work on tooling for a living, and have in fact tried to contribute back to babel but unfortunately there's so much noise and traffic that there's just as good a chance that your PR is stuck in limbo forever than being merged or even reviewed. I understand why, there's only so much the maintainers can do with the limited time they have, but my point is that you can't just say that the problem is that people aren't contributing. It's a two-way street, and maintainers need to figure out how to actually accept (or reject) contributions as well.

There are other ways to contribute than opening PRs and issues of course, like sending money. But even sending money isn't without complexity -- plenty of companies have the ability to contribute financially, but they can't because they need a VAT receipt or invoice to make it happen. Accounting is a hard requirement for companies, you can't just send money willy-nilly like you can as a private person. It's surprisingly difficult for companies to contribute financially to most projects, and that's not even considering the hard ship of getting those expenses signed off which is often a battle and a half on its own. Babel has a decent set up, but still requires a credit card -- this alone makes it much harder since you'd probably have to personally expense it and then try to get it past accounting.

It's a problem, for sure, but I don't think it's as black and white as you make it seem.

A database, for many many companies, is essentially the business. There's nothing more important. Babel, which again I love, at the end of the day lets you write more expressive code. Anyone who thinks fixing a bug that lets you write arrow functions instead of using `Function.prototype.bind` or whatever, is anywhere as important as a database... is just wrong.

Always remember your place. Your job is to make widgets for a company. Your productivity definitely has value, but don't overestimate how much value it has.

A better example would have been something like Resharper, which companies are willing to pay for, but they won't make its bugs an important part of their roadmap.

Understatement of the year. It's not just convenient, it's an absolute gamechanger.

JS gets a shit reputation for being mountains of config before you can do any work, but because of `babel-preset-env` I can start a new project, put `> 5%` in the babel config, and write in the latest and greatest version of JavaScript and have it just work.

It's also completely unsurprising.

Relying on people's good will doesn't work sufficiently. It turns into a tragedy of the commons situation with everyone hoping to get the benefit of the work of others.

From what I understood, there is currently nothing to allow both ES5 and ES6 code to be published and let the bundler choose which one to include. Any ideas on how to change this?

If yes, in retrospect, was the switch worth it? If no, it might be a way out of the configuration pains.

The issue to blame is https://github.com/facebook/react-native/issues/12590 which has been "iceboxed" and not fixed. In short, I have to patch metro each build, to increase the time it waits before killing babel, since the 5 minute timeout simply doesn't cut it.

Debug builds would take over 30m to transform with babel.

I think before they were part of the paid npm plain or just not enough information about them, and the questions on what being an npm org meant, etc. Maybe Babel switching to them will help move that forward even?

Reasons to use Babel:

* Babel supports bleeding-edge proposed language features like the pipeline operator, throw expressions, optional chaining, etc.

* Babel lets you run custom transforms like babel-plugin-idx and babel-plugin-rewire.

* Babel gives you more control over exactly which transforms you want to run. In one case, I wanted to disable most transforms, but still had to enable the class transform for interop with CoffeeScript classes. TypeScript would need a custom option for any use case like that.

* Babel supports both Flow and TypeScript.

* Babel is a community project rather than being primarily developed by one company. Microsoft theoretically could make a business decision to stop TypeScript development, but nobody could do that for Flow.

Reasons to use TypeScript:

* From my measurements, TypeScript is quite a bit faster than Babel at compiling ES2017 to ES5. From a quick test, TypeScript took 35 seconds and Babel took 140 seconds when run on my codebase at work.

* TypeScript is probably easier to set up and configure. No individual plugins or presets to install, you just set your compilation target in the config. The TypeScript team has already made the decision about which proposed features (e.g. object rest/spread) are safe to use right now, so there's less decision-making to do in that regard.

* TypeScript is maintained by a full-time team at Microsoft, and there's less risk of the maintainers getting burnt out.