Deploying ECMAScript 6

Js updates are backwards compatible

Running non-converted files through babel is not an issue, they will just come out looking the exact same. That said we have a high number of JS files (that I am slowly pruning down) so it was a worry (time-wise it takes ~30 sec to transpile all our JS) to run them all through babel. I considered trying to add a:

  "use babel";

at the top of files that should be transpiled but I couldn't find a good "gulp way" to check for that. I also considered using a "filename.es6.js" structure but following file renames in SVN is a bitch and a half (not my only reason) so I didn't want to have to change those all back when es6 was widespread enough to use directly. I settled on running them all though so our "gulp build" takes 30 seconds or so but for our "gulp watch" (which starts off by building everything) I implemented caching so that only changed files had to be re-transpiled before getting concated into our "app.js" file. With this change it takes <1sec to transpile changed JS. Since our JS dev's use "gulp watch" everything works out quite nice so that they can edit a file and reload their browser to see the change immediately (30 sec times would have killed babel in it's crib for us and I assume most other places).

For caching we used the gulp-cached [0] plugin. It's important to note that if you plan on concat-ing your files that you are caching then you will also need to use gulp-remember [1] which re-introduces cached files into your file stream after the intensive parts of are done so for example:

  var customJSStream = gulp.src('webroot/source/js/**/*.js'))
  	.pipe(cache('app-custom-js'))
  	.pipe(babel())
  	.pipe(remember('app-custom-js'))
  ...

(NOTE: I've left out stuff from our gulpfile and simplified it for display here)

We then combine that stream with 2 others and concat them all together but that's not important for this example. Let me know if you have any other questions!

[0] https://www.npmjs.com/package/gulp-cached

[1] https://www.npmjs.com/package/gulp-remember

It's a good start to switch the extension name so you now in which files you can use es6...

But as the other commenter said, all es5 JS is valid es6 JS...

> How did you do one file at a time?

I suspect they just flipped a switch causing all files to be run through the transpiler, regardless of filename extension or anything. However at the time the switch was flipped, none of those files actually contained any ES6-specific syntax, so the transpiler was mainly just passing code through unchanged, even though it technically is transpiling everything. Now they're simply going through the code and swapping in ES6 syntax here and there. It all works because 6 is a superset of 5.

Not to mention that IE is usually a bit ahead at launch, but with such a long tail (roughly two years) between releases gets pretty stale, and is in general the boat anchor that holds back being able to use said features without transpiling and/or shims for 4+ years.

I would warn against using `let` in Firefox today, their implementation has a lot of bugs[1][2] at this point.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=950547 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1023609

I mean if you never want to improve the language I guess not. The point was that ES5 adoption was really weak at best, and ES6 has been very strong.

Me too, and I can't help but feel this paints an overly rosy picture of the state of ES6 in TS. Truth is: it's coarse and minimal.

See the status here:

http://kangax.github.io/compat-table/es6/

The column below "babel" is what you would get when you program raw ES6 and transpile using Babel. The column below TypeScript is, unfortunately, what we are currently dealing with. Many lacking features.

So far, 1.5 doesn't look like it will bridge this gap substantially.

You can compile .ts to ES6 .js and then use babel to compile it to ES5 .js.

Even with prototype based inheritance I tend to avoid it all together in JS. Preferring to use generic object instances, with function based modules that can be composed (Ramda, ReactiveJS, etc) that works out being much better and easier to reason with in practice in my opinion. I agree that the class syntax seems a bit weird, but it isn't bad... It's a lot better than ES4/AS3 syntax in my mind, though ES7 (TypeScript/AtScript) seem to be moving in that direction.

I've used source maps before but they're not nearly as good or intuitive as simply debugging ES5. Too much of a pain in the ass in my opinion. I just don't see the value of adding an additional layer of possible bugs / issues just so I can use a little bit better syntax; I'd rather wait until more things get updated with the native implementation.

I still think a better solution is some sort of byte code so people can use whatever language they want instead of trying to force JavaScript to be the "byte code of the web".

> I use commonjs module syntax instead of imports, but may change my approach in the future.

You use commonjs with es6? Why?

> I can sympathize the initial fear of transpiling. However, it really is much better than you think. Source maps have made big strides in the past year and Babel has excellent support for them. Besides source maps, Babel does a lot to keep the generated code as similar as possible to the input. There are very few features that require complex transpiling.

I understand all that but after being bitten by the CoffeeScript transpiler on multiple occasions and Google's closure once, I try to avoid it at all costs. It adds an additional level of complexity to projects (needing to transpile before testing / debugging) and I just don't want to risk it for such little return, in my opinion.

I'm sympathetic to the cause of getting more people using ES6 and this is a way to do it today but personally I won't use it until ES6 is native in all of my browser and server targets.

> Transpiling is quite nice, and it's very likely that you already do it with something like Uglify or Closure compiler.

I've run into an issue with Closure at a point in the past (essentially the optimization to make everything into one statement breaking Opera; that was almost impossible to figure out but thankfully someone else did). But I do use Uglify; I try to limit it to compression only but it still changes things here and there (at least it appeared to; honestly it's been a while since I've dug into that code).

Minification, especially without all of the features enabled, should be safer than any other type of transpiler considering it has far less to do and many of the changes should be able to do so without consequence. Even still I do re-run all of my unit tests against minified versions of my code. It also makes me uneasy still but seems to be a necessary evil :)

>> npm may eventually support two versions of the same module, which would enable you to deliver libraries as both ES5 and ES6 for Node.js, io.js and client-side module systems that are based on npm. > This will actually be necessary in the node environment if we are ever to migrate to ES6+ features without causing breaking changes for module users.

I'm having a hard time believing this will happen. This adds complexity to every module as they now have to maintain an ES6 and an ES5 version should they actually want to use ES6. Yeah they can transpile but they still have two modules to maintain, track bugs in case there is a difference, etc. This is unrealistic in my opinion and I don't get why it's even necessary; simply make a certain version of node be required if you want to use ES6. If users can't do that they'll have to use an older version.

Moving to native ES6 on node should happen really quickly compared to the browser space. The browser space is going to be painful.

Webpack is a very good solution too. I really like jspm, and especially the dedication of its main developer, but I found much easier to integrate webpack in my build process than jspm. More features, a bit less bugs.