
Nearing the Babel 7.0 Release - edmorley
https://babeljs.io/blog/2017/12/27/nearing-the-7.0-release
======
git-pull
All the stuff babel includes is really impressive.

Checkout the pipeline operator:
[https://github.com/babel/proposals/issues/29](https://github.com/babel/proposals/issues/29)
([https://github.com/tc39/proposal-pipeline-
operator](https://github.com/tc39/proposal-pipeline-operator))

That's some cutting-edge stuff. I wouldn't want to use it until it was
official, but it's cool to have the opportunity to try TC39
([https://github.com/tc39](https://github.com/tc39)) proposals via babel. In
addition to the normal compiler usage for the latest standards.

> We received a $1k/month donation from Facebook Open Source!

> This the highest monthly donation we have gotten since the start (next
> highest is $100/month).

When I read this, I kind of mumbled to myself, "that's all?"

It goes to show how poorly funded open source projects are. We rely on these
tools, file issues, and want them to work, yet there isn't enough to even pay
someone to work on it full time.

[https://twitter.com/ShiyaLuo/status/931230821976907776](https://twitter.com/ShiyaLuo/status/931230821976907776)

> Engineer: There's a thing we need in babel, can I spent 2 days with a PR for
> it

> Company: lol no it's their job

Yep, the problem is cultural. The whole system of reciprocity is out of whack.
The system would work more smoothly if more people took on responsibilities,
QA'd, contributed patches. Give engineers a % of time to contribute back to
the libraries they use.

And yea, contributing back upstream to libraries isn't always glorious as
releasing your own stuff, but it's part of what open source is. These big
companies (not naming names) would rather make totally new projects than pitch
in maintaining current ones. I admit it, it's not fun to do, but it's
necessary.

> TL;DR: use babel-preset-env

This is convenient.

~~~
mstade
> Yep, the problem is cultural. The whole system of reciprocity is out of
> whack. The system would work more smoothly if more people took on
> responsibilities, QA'd, contributed patches. Give engineers a % of time to
> contribute back to the libraries they use.

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.

~~~
hzoo
> 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 agree it's a two way street and not all maintainers want to be "purely" what
people consider a maintainer role unlike me - but it's a lot of responsibility
on their part to have to look at every PR in a certain amount of time. I think
contributors could also do more to ask and get involved although it will take
more energy on both sides parts: like doing a hangout/video call etc even
though it feels like people either maintainer or contributor just think making
a PR suffices to get something merged when a lot of times it is so much more.

I think what I'm saying is that if you do get the time to make a PR and if
employers allowed it, they should also allow for the time it takes to get
through the noise and traffic by helping out with maintenance, not just the
bug fixes, or that we need a priority kind of thing so that
maintainers/contributors see effort from one another to make it better. Yeah
it's definetely not that simple but I think we need more people/companies
trying it out to really see what the problems are then just talk about it.

~~~
mstade
I agree, but as a contributor there’s only so much you can do if the receiving
end isn’t, well, receiving.

Plenty of people try to contribute but either the receiving end is
unreasonably difficult to work with – or, as is perhaps more often the case –
simply aren’t responding at all. It’s hard to get on a call where the other
end isn’t picking up, as it were.

I’ve seen this first hand several times. Despite numerous attempts to make
things as easy as possible to merge, providing ample documentation for the
changes, making yourself available etc., the receiving end simply isn’t
picking up. At some point you just give up and let it be. Sometimes, I’ve seen
my PRs get picked up months or even over a year after initially submitted, at
which point even I as the author don’t know what the PR is all about
anymore...

------
hzoo
Oh cool, didn't realize someone posted to HN (I haven't been on HN in a while
=D)! Open to questions and clarifications (on the actual content of the
upcoming release, process, how to help, future, whatever)!

There are a few things we need to do like a upgrade tool and some other things
that haven't been addressed like how library/module authors should publish to
npm (do you include/exclude polyfills, do you compile down to ES5 or start
introducing ES6+ code under a different folder or package.json string like
"module" or "es2015" which will be out of date, etc)

Also didn't write much about the Typescript support yet but we want to help
people use that too if that helps with their development

~~~
renchap
I am very interested about publishing ES6+ code.
[https://philipwalton.com/articles/deploying-es2015-code-
in-p...](https://philipwalton.com/articles/deploying-es2015-code-in-
production-today/) was very inspirational on this topic, but the fact that 99%
of the libraries I use are publishing transpiled code (+ polyfill) is a big
disappointment.

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?

~~~
hzoo
> 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?

Yeah it's mostly a conventional then we have to figure out.

Some people have different "dist" folders like say with redux_-
[https://unpkg.com/redux@3.7.2/](https://unpkg.com/redux@3.7.2/) there is
`src`, `lib`, `es`, `dist`.

In package.json, you can specify

    
    
      "main": "lib/index.js",
      "module": "es/index.js",
      "jsnext:main": "es/index.js",
      "typings": "./index.d.ts",
    

which a bundler like webpack will look at. The problem now mostly is that
"module" assumes es modules but not a specific level of ES/polyfills and we
want a way to do that instead. Making a yearly "es2015", "es2016" field seems
weird and we want one that is up to date like preset-env?

------
dexwiz
Babel is one the few pieces of the modern JS stack that "just works." Most
projects work by just including `babel-preset-env`. It gets lumped in with
Grunt/Webpack as being a pain, but I rarely fight with it. Compare that to
Webpack where a minor config change can suck up a days worth of time wading
through mountains of semi-complete documentation.

~~~
Jeaye
In my experience, babel is the single most unreliable and unusable piece of
the build machine.

The issue to blame is [https://github.com/facebook/react-
native/issues/12590](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.

~~~
hzoo
Hmm, sorry it feels that way! I don't use react-native and don't think anyone
on the team was informed of that issue - but is it really an issue from Babel
itself?

I guess in that case I would suggest not transforming files like ".json" which
if it's a wrapper around Babel could do for you automatically? It's not
intended to transform JSON since it would just have the same output, not sure
how it's related to compiling JS specifically.

~~~
Jeaye
This is strictly for transforming JS. It has existed for over a year, here
[https://github.com/facebook/react-
native/issues/8475](https://github.com/facebook/react-native/issues/8475) as
well.

It's certainly possible that the babel team was never aware of it, but I'd
imagine this has to do with the seemingly exponential growth of transformation
time per source KB.

------
Klathmon
I love the move to scoped packages.

I encourage everyone to switch to scoped packages if possible, it gives you
much more freedom over your name, reduces the chances of typosquatting causing
your users problems, and can even help get your name out there a bit more!

It's a no brainer, and I'm surprised more people don't use them.

~~~
hzoo
Yeah I was hesitant due to not that much support in the community, etc but
after hitting the typo-squatting issue over like 5 times (you'd think once
would be enough) it just had to be done. There are other issues for our plugin
ecosystem since people fail to know which ones are from us and which are just
another plugin.

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?

------
JeremyBanks
Why would anyone use Babel instead of TypeScript's compiler these days?

~~~
alangpierce
I think the main conceptual difference is that Babel is a plugin ecosystem
while TypeScript has a fixed set of features. But I think it's common for
people to not consider the TypeScript compiler because they're not using the
TypeScript language.

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.

~~~
hzoo
> * 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.

Hmm, I would of thought it would be the opposite but I guess it depends on the
setup?

> * TypeScript is probably easier to set up and configure.

Yeah given it's more of a "language" TS can decide on those defaults although
you can just make your own preset for your company/project as well. I think we
can fix that too with a default/separate thing but not sure yet.

~~~
alangpierce
I haven't looked too much into the TypeScript compiler implementation, but my
theory is they've just had more bandwidth to do little optimizations or maybe
got lucky on some design decisions rather than it being something fundamental.
To be clear, this doesn't include any typechecking, so Babel and TypeScript
are pretty much solving the same problem here.

I've actually been hacking on a faster alternative to babel/tsc for simple use
cases:
[https://github.com/alangpierce/sucrase](https://github.com/alangpierce/sucrase)
. It has a built-in benchmark (`yarn run benchmark`) with at least one example
of where typescript is about 3x faster. So you could look at that config if
you want one example to compare the two.

