Why Babel Matters
codemix.com
codemix.com
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.
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
How do you envision the future ? Everything expressed as a js descendant ? no more syntactic distinctions ?
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.
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.
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
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.
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.
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.
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.
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.).
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.
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 meantime, TypeScript works rather well and is looking to add JSX support.
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'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)
Seems like the flow docs may need an update to reflect the newest additions.
I've been using babel --stage 0 (for ES7 adds) for my current projects, and async/await are absolutely invaluable[1].