Why Babel Matters(codemix.com)
codemix.com
Why Babel Matters
http://codemix.com/blog/why-babel-matters
4 comments
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
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
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)
Personal favorite quote: https://www.youtube.com/watch?v=DspYurD75Ns&t=39m07s
How do you envision the future ? Everything expressed as a js descendant ? no more syntactic distinctions ?
How do you envision the future ? Everything expressed as a js descendant ? no more syntactic distinctions ?
Same here with LiveScript.
I just feel like it's half the work coding, than with JavaScript.
If they get the ES6 import/export done, I got all I need.
I just feel like it's half the work coding, than with JavaScript.
If they get the ES6 import/export done, I got all I need.
I suppose if CoffeeScript were reimplemented from scratch today, it would make sense to compile to an ES6 AST that could be passed on to Babel for further processing and code generation.
Can't you do optional semicolons in JavaScript?
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.
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.
> They will have trouble with the ES6 code and they might have trouble with the ES5 JS produced as output.
Source maps made this practically a non-issue. If you can add gulp (or grunt) into your workflow (along with node/npm) then you can slowly add in things like babel without most people having to care. The nice thing about babel is you can run ES5 code through it without issue so you can ease into ES6 very easily. We just made the transition at the place I work and it took about 8 months to go from just JS/CSS to node/npm, gulp (sourcemaps, concat, minify, css/js processors, previous manual build steps, etc), SCSS, and bower. The majority of our JS is still ES5 (and needs cleanup) but we are are making good progress moving over to ES6 and taking advantage of our new build process. I won't say it has been a painless transition, the new tools rather than code were a sticking point and we started by running gulp on the prod server (from an svn checkout) but now have it build on a build server and then (using gulp) package itself up in a tar.gz and put in a place that our deploy scripts pull from. I got quite a few "Why is none of the css/js loading?" (needing to run "gulp build") and I don't blame them, most of them don't need to write JS much so having to run "npm install/gulp build" on each checkout before doing development was annoying but hopefully now they see the benefits and we've done our best to make the process as simple as possible as well as using gulp to reduce a number of other pain points.
Source maps made this practically a non-issue. If you can add gulp (or grunt) into your workflow (along with node/npm) then you can slowly add in things like babel without most people having to care. The nice thing about babel is you can run ES5 code through it without issue so you can ease into ES6 very easily. We just made the transition at the place I work and it took about 8 months to go from just JS/CSS to node/npm, gulp (sourcemaps, concat, minify, css/js processors, previous manual build steps, etc), SCSS, and bower. The majority of our JS is still ES5 (and needs cleanup) but we are are making good progress moving over to ES6 and taking advantage of our new build process. I won't say it has been a painless transition, the new tools rather than code were a sticking point and we started by running gulp on the prod server (from an svn checkout) but now have it build on a build server and then (using gulp) package itself up in a tar.gz and put in a place that our deploy scripts pull from. I got quite a few "Why is none of the css/js loading?" (needing to run "gulp build") and I don't blame them, most of them don't need to write JS much so having to run "npm install/gulp build" on each checkout before doing development was annoying but hopefully now they see the benefits and we've done our best to make the process as simple as possible as well as using gulp to reduce a number of other pain points.
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
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/) simplifies using Babel, this is a good intro: https://github.com/petehunt/webpack-howto
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/) simplifies using Babel, this is a good intro: https://github.com/petehunt/webpack-howto
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.
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.
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.
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.
Once you get to the point you can abstract your promises with async/await in a lot of places, utility methods/workers become so much simpler... I can't imagine how complicated some of my code would be without the ES7 stuff.
Promises, coroutines, async/await, lambda expressions, spread operators, destructuring... once you get used to it, you don't want to go back.
About the only abnormal thing I'm doing is overriding the global promise implementation with bluebird (even in current iojs), and using some of the extended methods... I've also been using ramda and fetch a lot.
Promises, coroutines, async/await, lambda expressions, spread operators, destructuring... once you get used to it, you don't want to go back.
About the only abnormal thing I'm doing is overriding the global promise implementation with bluebird (even in current iojs), and using some of the extended methods... I've also been using ramda and fetch a lot.
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.).
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.).
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.
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.
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.
In the real world - where teams of people work on codebases of significant size - TypeScript will absolutely dominate the typeless transpiled Javascript languages.
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
[1] http://flowtype.org/
[0] https://github.com/codemix/babel-plugin-typecheck
[1] http://flowtype.org/
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.
In the meantime, TypeScript works rather well and is looking to add JSX support.
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!
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!
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.
There are some packages that provide support for flow in atom editor, like: 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)
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)
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.
For sure, tooling is an area that will get better over time. I am quite happy with the very simple vim-flow, but TypeScript's tooling and overall ecosystem (tsd/definitelytyped) is a lot more mature.
I will. By the way, I always use TS with --noImplicitAny, and the number of type annotations I've had to add is rather small and very reasonable (mostly just on function arguments of methods and non-lambda functions).
Seems like the flow docs may need an update to reflect the newest additions.
Seems like the flow docs may need an update to reflect the newest additions.
Thanks for contributing to Flow!
I'm also keen for Flow to improve, but for now it's possible to turn off the `flow` transformer in Babel and pass the compiled output to flow - this preserves type annotations in the output
Using ES6 (or CommonJS) module syntax, you can create minimal, testable modules that are very easy to reason about, and minimize the need for specific type safety concerns. I do think that TypeScript will gain a lot of a following, especially with Angular2... just the same, I've now worked on some pretty big node/web projects and haven't needed the type safety.
I've been using babel --stage 0 (for ES7 adds) for my current projects, and async/await are absolutely invaluable[1].
[1] https://twitter.com/tracker1/status/598912227920334848
I've been using babel --stage 0 (for ES7 adds) for my current projects, and async/await are absolutely invaluable[1].
[1] https://twitter.com/tracker1/status/598912227920334848
Flummox or Alt (both are flux implementations) with async actions: my favourite part of JavaScript at the moment. The fact that the regenerator runtime means async/await wrap regular promise based libraries with zero hassle is just brilliant!
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.