
The State of Babel - BenjaminCoe
https://babeljs.io/blog/2016/12/07/the-state-of-babel
======
ggregoire
Good occasion to thanks all the people who have been working on Babel.

Among other things, Babel allows me to use ES6/ES7/ES8 (e.g. async/await), to
write my components in JSX and to type my code with Flow.

It would be so painful to work without Babel.

Thanks guys!

~~~
andreasklinger
+1

babel completely changed my pov on javascript

~~~
karmajunkie
Ditto... still not my favorite but now I use es6 and friends preferentially to
a few other options that would have won out before.

------
brentm
I just want to say these people do amazing work. It's truly been a pleasure to
work with JS in 2016. Thank you to everyone working on Babel and the countless
other great OSS projects. One of my goals for 2017 is to find a way to get
involved.

------
hzoo
Author here, if anyone had questions or wanted to know more about how to help
out!

Personally, I'm most excited about babel-preset-env, and fixing how we work
with the TC39 process via experimental plugins, and working with the community
more.

For anyone wanting to get started in OSS or Babel I just started a year ago
from knowing nothing about it!

------
bradleyprice
I second (third?) the fact that I'm so thankful for these packages and
contributors. Reading this article puts into perspective the amount of
alignment within the community that it takes to be able to depend on external
libraries to make our day-to-day easier.

It's very humbling. I'm just here standing on the shoulders of giants.

------
Ajedi32
Codemods support with Recast looks really impressive. I wonder how hard it'd
be to use that to write a `gofmt` for JavaScript.

~~~
hzoo
I know jlongster started
[https://github.com/jlongster/jscodefmt](https://github.com/jlongster/jscodefmt)

[https://twitter.com/jlongster/status/804888882408026113](https://twitter.com/jlongster/status/804888882408026113)
which uses recast/babylon

------
rattray
Not only is Babel great as a tool for transpiling JavaScript, I've found the
plugin system to be splendid for building a compile-to-JS language as well.
The tools are terrific to work with.

------
maaaats
Interesting points. Good ideas for features I would like, and laid out in a
way that makes me want to contribute.

~~~
hzoo
Awesome! What's one of them? Hope to see you around then!

------
atomical
Is this where CoffeeScript left off? How would you compare it to CoffeeScript?

~~~
hyperdunc
There are many differences. One is that CoffeeScript will always need to be
compiled. Code written in, e.g. ES7, will not have to be compiled down with
Babel anymore once browsers in the wild all support ES7.

Also, AFAIK CoffeeScript restricts you to using JS features found in ES5.

~~~
6t6t6t6
I have the intuition that the plans of the developers of the future version of
JS are that you will always have to transpille the code.

[https://youtu.be/3pKNRgResq0](https://youtu.be/3pKNRgResq0)

On the other hand, I think that the time of CoffeeScript has passed. It made
some sense before Babel but now, IMHO, it is only for Ruby developers who
don't like the syntax of JavaScript.

~~~
douche
At this point, JavaScript is inching closer and closer to just being assembly
language for the web.

I think things will get very interesting indeed once WebAssembly really starts
to be a real thing.

~~~
6t6t6t6
And this day maybe we will not need JavaScript anymore... ;)

~~~
seanparsons
Literally can't wait for this.

~~~
mrspeaker
What a way to go.

------
SimonSelg
Thanks to everyone working on these tools! They improve the DX sooo much!

------
xwowsersx
As an outsider to FE development, when I see posts like this, I just shudder
at the complexity of the ecosystem.

~~~
ng12
It's no worse than any other ecosystem. Modern Java development is just as
prickly -- the only difference is the complexity is more established. JS is
still very "wild-west" because the community is still making rapid progress
towards an ideal environment.

~~~
flukus
> JS is still very "wild-west" because the community is still making rapid
> progress towards an ideal environment.

Most of the churn seems to come from people reinventing the wheel over and
over again.

~~~
ng12
Could you elaborate? I hear that a lot but I suspect it only comes from people
who don't do a lot of web development.

~~~
flukus
Look at the number of binding/UI frameworks, look at the package managers,
look at the number of unit test libraries, look at the number of build tools.
Many get reinvented in a bubble when there are plenty of options already.

Now half (maybe more) of the libraries are being written in languages that
aren't javascript so now there are multiple competing ecosystems on top of
javascript.

And then you have things like angular creating churn within the framework.

~~~
ng12
So the argument is essentially "there's a lot of stuff I don't really
understand, a lot of it must be redundant"?

React isn't just Angular with a different name -- they have fundamentally
different views on how web development should be done. They also fit different
use cases (Angular is a one-stop-shop, React is minimalist by design). Same
thing with the build systems. Add in the fact that a lot of this wasn't
possible until recently (i.e. Webpack is fundamentally enabled by ES6-style
imports) and of course things are going to change rapidly.

> Now half (maybe more) of the libraries are being written in languages that
> aren't javascript so now there are multiple competing ecosystems on top of
> javascript.

I'm not sure what you mean by this. Elm-html is the only example I can think
of that is non-Javascript. If you're referring to Angular2 being Typescript
you can still use it just fine with regular JS.

~~~
flukus
Sure react and angular are different, what about the dozens of others? I
posted elsewhere the number of crappy make clones alone:

[https://www.npmjs.com/search?q=make+build](https://www.npmjs.com/search?q=make+build)

~~~
Klathmon
For starters, why is that a problem? You aren't forced to use them all, you
aren't forced to use any of them.

But secondly, what makes them crappy? I've used make, and IMO it's pretty
crappy itself. Have you had to maintain a recursive makefile? It's a complete
nightmare to say the least. And i'm far from the only one to think make is
worthy of a "remake". In fact even in just the C/C++ world there is cmake,
qmake, autotools, scons, ninja, bazel, premake, waf, shake, tup, etc...

If you run your same search in pip, or ruby gems, or composer, or cargo, or
cpan, or any other package manager for any other language and i'm sure you'll
see it's fair share of build tools, frameworks, libraries, and unmaintained
stuff.

It's not a problem, and it never will be.

~~~
flukus
> For starters, why is that a problem? You aren't forced to use them all, you
> aren't forced to use any of them.

It's a problem because every time I need $tool I might have to evaluate dozens
of choices, check for compatibility, investigate the ones that suit, hope to
god the rest of the community is familiar with it, hope it is supported in
future, etc. And then with the rate of churn you might have to do the same in
a year. Make has been supported for 30 years, I know it's not going anywhere.

> In fact even in just the C/C++ world there is cmake, qmake, autotools,
> scons, ninja, bazel, premake, waf, shake, tup, etc...

So there's already dozens of tools, why reinvent them in javascript? Every
ecosystem does this but it least most seem to settle on one or two tools, this
doesn't seem to be happening in the javascript world.

~~~
Klathmon
Well you don't need to evaluate dozens of choices, a few at most. Hell if you
just wanted to go by your search above 2 of the top 3 are the 2 biggest build
systems in JavaScript (grunt and gulp), and the other isn't a build system.

Maybe it's me, but I've never looked at a list of tools and thought "this is
too many!". The more the merrier IMO, and if they are good then they will rise
to the top over time. If you don't want to choose, just pick the most popular
and deal with it, it'll feel the same as another platform where there's only
one to choose from.

But you could also just use make, it's all about your needs. Do you want your
project to still build in a few decades with very little change? Then choose
the tools for that. You just making a pet project that just needs to live
until the domain expires? Try out something new! Afraid of change? Stick with
make!

>Every ecosystem does this but it least most seem to settle on one or two
tools, this doesn't seem to be happening in the javascript world.

For the most part JS has settled. When it comes to "stuff like make" it's
basically gulp or grunt (or make and friends). Yeah there are other smaller
players, but there's also a few dozen Java build tools that you've probably
never heard of.

~~~
vacri
> _Maybe it 's me, but I've never looked at a list of tools and thought "this
> is too many!"._

There is the problem of diffraction of efforts, and spreading knowledge too
thin. You see some of the problems in the way linux distros do packaging -
every major distro family has its own packaging system, born from NIH
syndrome. The result is less portability of both packages and skills.

Some competition is good, but there is a point beyond which lots of choice
becomes counter-productive. Troubleshooting also becomes harder when the
various tool communities are smaller on average.

~~~
Klathmon
I disagree with that premise though. Just because I made a package that's in
the same realm as make doesn't mean that I could have or would have
contributed to make instead.

And there's something to be said about smaller single-purpose tools. Adding a
ton of features to something like make to support every possible option isn't
a good idea IMO. Sometimes a small opinionated package with a "correct" way to
use it is best for some circumstances.

Regardless, I really think that the market will sort itself out. If it's
oversaturated then some big players will rise to the top and the rest
forgotten. Unlike a Linux distro package manager, anyone can add anything to
NPM with zero oversight. It makes the "floor" of quality much lower, but
fragmentation isn't that big of a deal as the effort to publish is so low.

------
wmichelin
> 6to5 did exactly that: easily turn ES6 code into ES5 codee

~~~
hzoo
Haha fixed - or it can be a joke on the output being larger.

