

Why Babel Matters - phpnode
http://codemix.com/blog/why-babel-matters

======
vectorpush
I use CoffeeScript whenever requirements permit. Recently I've been working on
a small side project using ES6 (via iojs) and I have to admit that it's pretty
refreshing to see JavaScript take on some modern improvements and it's clear
that today's CoffeeScript loses out on critical functionality that ES6 brings
to the table.

With that stated, I still overwhelmingly prefer CoffeeScript's syntax to ES6.
I'm glad ES6 took some inspiration from CoffeeScript, and Babel is a great way
to bridge the future of JavaScript over to client's of the present, but I'll
always prefer the CoffeeScript syntax for white-space sensitivity, support for
optional semi-colons, optional parenthesis for function calls and optional
curly braces for object literals. I don't need those features but I _really_
like them. For me, the real future of JavaScript is a re-imagined CoffeeScript
that takes on some refined semantics in order to bring ES6 feature support
into the CoffeeScript compiler. Admittedly, that is not a simple undertaking
(though I'd imagine the code would be simpler as a whole since it would
necessarily trash obsolete features like pseudo-classes etc), but I know I'm
not the only person who would love something like this.

I don't know how jashkenas is feeling about ES6, but one day I'll have my
ES6Coffee, even if I have to brew it myself.

~~~
jashkenas
I can answer that ;)

ES6 is groovy. Many features are in the runtime and not the syntax, and just
work as-is. As other syntaxful features start to come into existence and then
universal implementation in most active browsers, CoffeeScript should begin
offering them -- at least the ones that align with the mission statement.

Some will be troublesome because of intentional syntax conflicts, like "for
of" and perhaps classes. It'll just take a bit of design work to make things
copacetic.

That said, in the long run, the future is going to be JavaScript (if it
continues to evolve) and languages that are much more radical than
CoffeeScript. For more thoughts on that, see:
[https://www.youtube.com/watch?v=DspYurD75Ns&t=36m57s](https://www.youtube.com/watch?v=DspYurD75Ns&t=36m57s)

~~~
rubiquity
Nice talk. Given how you end the talk, have you looked at Elm? If so, what are
your thoughts and do you think it satisfies unifying HTML, CSS and JS?
(Putting aside the uphill battle of gaining adoption as a static typed, FRP
language)

------
VeejayRampay
Looks absolutely awesome but I still feel like the biggest barrier to more
adoption of Babel and similar tools in the workplace just boils down to those
coworkers that know some JavaScript, but come from a different background or
are simply too junior/not schooled enough.

They can usually deal with basic jquery / angular and vanilla JS (i.e. without
too much 'this', 'bind' or 'prototype'). They will have trouble with the ES6
code and they might have trouble with the ES5 JS produced as output. It's a
shame really because a combination of Babel and maybe underscore/lodash for
added sugar and features makes JS look SO MUCH more solid and modern a
language. I hope this takes up and becomes enough of a powerhouse that the
powers and balances start to shift.

~~~
iyn
I'm referencing this all the time, but that's because it's great: you may want
to show coworkers this tutorial:
[https://github.com/lukehoban/es6features](https://github.com/lukehoban/es6features)

I was intimidated by ES6 in the beginning and knew just basic JS with jQuery
and Lodash, but honestly starting out with ES6 is pretty easy and I can say I
love writing ES6 now! Webpack
([https://webpack.github.io/](https://webpack.github.io/)) simplifies using
Babel, this is a good intro: [https://github.com/petehunt/webpack-
howto](https://github.com/petehunt/webpack-howto)

~~~
VeejayRampay
Thanks for the links, much appreciated. The point I was making though is that
ES6 definitely is another world in terms of complexity for newcomers. Things
like variadic functions, generators, async/await, destructuring assignment are
extremely nice additions that I'm psyched to see coming to the language, but
they do add a certain layer of "real language" gravitas to a language that a
lot of people in the workplace were merely using to create "directives" and
"controllers" or to "get DOM elements". Javascript is not a toy anymore
(hasn't been for years actually, but it's getting "real" now).

In the end though, you're right, everyone will take that step, the complexity
is nothing overwhelming and those tools you're sharing will help make way for
a great future on server and browser alike.

~~~
eyko
EcmaScript is backwards compatible so you don't need to adopt the entire list
of new shiny features at once. You can still continue to develop in your usual
ES5 syntax and add a few ES6/7 features as you learn them.

In my case, I started with let/const and arrow functions. Then I added classes
and hit a few walls, mainly because I hadn't read/understood much about arrow
functions and the context they get bound to. After you start to use those, I
think everything comes naturally (e.g. realising that the feature that allows
you to import {foo, bar} from 'baz' is the same one that allows you to do var
{foo, bar} = baz; Deconstruction is very handy, especially when you pass
around big config variables and you only need a few bits from it. Not needing
to use a promise library for async code is also great. Mixing up async/await
with it is something I hadn't thought of until I read this article.

You slowly begin to adopt language features as you find them useful. It's not
an all in or all out situation so I think the barrier to adoption is very,
very low.

------
Lazare
I have to agree. I used Coffeescript on my last few projects, but on this one
we're using babel/ES6 and honestly? It's pretty good.

And there's some real benefits to writing in actual Javascript, even if you're
still transpiling it for production.

Ultimately, I feel like language choice is something of a bet. And while I
_like_ Coffeescript, the future of web development is going to be ES6 and ES7,
not Coffeescript. That makes it a lot easier to justify spending time on
(writing, learning, etc.).

~~~
ffn
Coffeescript is a dialect for (mostly) people who don't like brackets (also
cool but controversial features like null swallowing with ?, implicit function
calls, etc.), while babel is a transpiler to take es6 down to es5. Saying one
is a substitute for the other is like saying ice-cream mud-cake is a
substitute for steak and lobster at a restaurant - if it's Saturday night and
or your cheat day, just eat both. That is, pipe the output of your
coffeescript into the input of your es6 babel in your build step.

I personally use a ton of emberjs with ember-cli, and ember-cli-coffeescript
actually just straight-up ships this build pipeline for you when you decide to
use coffee.

P.S.: Sorry if I sound like Marie Antoinette saying "let them eat cake", yes,
I realize I am lucky to not have tons of legacy code that prevents me from
altering my build step, and that there are thousands of other less-lucky
engineers who are stuck with build systems that are essentially unalterable
voodoo.

------
radicalbyte
Whilst I agree that writing ES6 and transpiling to ES5 is a great idea (purely
from a maintenance standpoint), I think the author is dismissing the benefits
of typed languages too quickly.

In the real world - where teams of people work on codebases of significant
size - TypeScript will absolutely dominate the typeless transpiled Javascript
languages.

~~~
phpnode
I guess I failed to make this point properly, but Babel already supports
static typing - you can use a plugin[0] and/or you can use it with Flow[1].

[0] [https://github.com/codemix/babel-plugin-
typecheck](https://github.com/codemix/babel-plugin-typecheck)

[1] [http://flowtype.org/](http://flowtype.org/)

~~~
spion
Unfortunately, both of those are still very much inferior to TypeScript. I'm
waiting for flow to improve enough to actually become usable (still missing
basic things like ES6 or really any kind of modules support for type exports,
afaik?).

In the meantime, TypeScript works rather well and is looking to add JSX
support.

~~~
samwgoldman
TypeScript is great, but you might look again at flow. ES6 features are being
added (I'm adding let/const support) and many already exist. Import/export
(incl. types) are in, fat arrow syntax, destructuring, shorthand syntax for
objects.

I get the most value of Flow through statically typed React component props,
which is usable today with both `React.createClass`-style and
`React.Component`-style components.

In my experience, Flow will infer much more about "plainly" written JavaScript
than TypeScript, which will fall back to `any` unless code is annotated.

A small example, function types are contravariant in the negative position in
Flow, but bivariant in TS—much weaker!

TLDR, if you haven't looked at Flow recently, look again!

~~~
hazza1
Really like the idea of Flow but doesn't look like IDE support is there yet?
This is the killer feature of types in Javascript for me - not sure I'd adopt
it until then.

~~~
iyn
There are some packages that provide support for flow in atom editor, like:
[https://atom.io/packages/ide-flow](https://atom.io/packages/ide-flow)

I've been testing atom for front-end development in the last few days and it's
pretty good, definitely worth checking out (I'm saying this as a vim-lover)

~~~
girvo
Atom with eslint, the react plugin and eslint-babel is just amazing for ES6/7
and React development. It's so much faster than it used to be, it's actually
amazing.

