3 ms·

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 coworke

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 11y ago
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 11y ago
  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.
  - tracker1 11y ago
    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.
  - eyko 11y ago
    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.
joshstrange 11y ago
> 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.

iyn 11y ago

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 11y ago
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.
- tracker1 11y ago
  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.
- eyko 11y ago
  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.

joshstrange 11y ago

> 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.