
Deploying ECMAScript 6 - of
http://www.2ality.com/2015/04/deploying-es6.html
======
joshstrange
I know I'm far from the only one but I just wanted to throw out there that my
company is now using babel to transpile our ES6 to ES5. The conversion (which
only touched the code we've written in the last year or so b/c the old code is
just spaghetti so we only converted what was already JS "classes") took less
than a week of 1 dev's time and has been flawless so far (been using it
production for a little over a month now). We are using gulp to facilitate
this process. Just wanted to add a data point to those considering using it.

I've found the JS to be much cleaner and easier to read and I've heard similar
statements from the rest of the dev team. I highly recommend it. The best part
is you can convert your code 1 file (or "class") at a time and your old JS
will still continue to work perfectly.

Feel free to ask me any questions about the process and any potential issues
and I can respond with how we dealt with it (if we did).

~~~
AdamCraven
How did you do one file at a time? Enabling it with a different extension e.g.
script.es6 or similar?

Did it live side by side with existing code?

Were your watchers efficient or did it slow down over time the more you added?

Looking to do this on a large JS code base soon. Thanks for your input, Josh

~~~
joshstrange
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](https://www.npmjs.com/package/gulp-cached)

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

~~~
ksherlock
I'm always amazed at what people go through to use gulp/grunt/etc instead of
make.

~~~
joshstrange
_sigh_ I'm really not sure how to reply to you, I want to say don't feed the
trolls but.... make does not suit our needs and so we don't use it. Period.

Also good luck getting source maps + babel + bower + etc to work under make, I
honestly don't believe it's possible or if it is it would be so convoluted
that it would be impossible to extend or understand.

Gulp may not be a perfect tool (I don't believe such a tool exists) but it's
leaps and bounds above make and a better choice than grunt IMHO.

------
Someone1234
Wow Spartan (IE replacement) is really kicking some major ass with its
ECMAScript 6 support:

[https://kangax.github.io/compat-table/es6/](https://kangax.github.io/compat-
table/es6/)

~~~
exprL
Not really. Compared to, say, Firefox' future versions, it's barely ahead,
with Firefox putting some features counted multiple times behind a flag (let's
remember that `let' has been available in Firefox for ages, regardless of user
settings, assuming the script tag has suitable type attribute).

Further than that, it's silly to compare browsers that aren't stable yet.

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

~~~
tonyedgecombe
I was under the impression we are going to see regular updates to Spartan
similar to what we get from Chrome now.

------
thejameskyle
Babel contributor here. It's great to hear how many people are already
deploying projects using Babel, and even better to see how fast ES6 is getting
adopted. Many people are still stuck in an ES3 world... ( _shakes head_ )

If anyone has any questions, feel free to ping me or stop by our support
chat[1].

[1] [https://gitter.im/babel/babel](https://gitter.im/babel/babel)

~~~
striking
Is there anything wrong with being "stuck in an ES3 world"?

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

~~~
frik
JS5 adoption was really strong. It was hyped with "JavaScript - the Good
parts", and it was lean. Typescript inspired ES6 with syntactic sugar "class"
keyword in a language that has prototype based inheritance ...hmm we will see.
I dislike the recent forced influence of Microsoft to JavaScript.

~~~
zerocrates
JavaScript: The Good Parts predated ES5, and certainly predated actual
adoption.

IE didn't support basically any of ES5 until 2011 with IE 9, and, for example,
Safari didn't support bind() until 2012. Strict mode didn't appear until IE
10, Firefox 4, and Chrome 13. Those dates aren't so great even if you ignore
that you'd often have to support the earlier versions for a significant amount
of time anyway.

------
apaprocki
This states TypeScript is layered on top of ES6. I did not believe that to be
true. Is there some meta-bug or other location tracking the TypeScript move to
ES6? I was under the impression there were still a number of bugs that prevent
fully using TS with ES6. (Maybe I'm wrong and someone can fill me in :))

~~~
tinganho
I'm using TypeScript everyday, so I might can give a good answer to your
question. They have just finished support for ES6 modules, template string,
let/const etc. ES6 classes have been supported for a long time and most of the
syntax sugar of ES6 I can think of is supported. On top of that, they are
about to release v1.5 the big thing there is support for decorators.

What is not so good with TypeScript is that they have a rule of not
polyfilling things. So if you want any new ES6 methods for array/string etc.
You would need to polyfill them yourself.

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

~~~
egeozcan
Doesn't it error-out with the unsupported syntax, for example, generators?

~~~
katabatic
Yes, however some features in TypeScript are only supported when targeting ES6
(such as "const"), so there's still some value in double-transpiling from
TypeScript -> ES6 -> ES5 (I'm doing that on a couple of projects).

That may have changed somewhat in the TS 1.5 alpha - they're supporting more
features on the ES5 target than they did in 1.4.

But yes, you still can't use ES6 features that TS doesn't know about.

------
jsprogrammer
If you're looking for a ready-made template project to try out ECMAScript
6/7/2015, I created, and have been successfully using my base-node [0] and
base-angular [1] projects for a while now.

You can use babel or traceur (just comment/uncomment one line), although the
default is traceur. Gulp is used for building, packaging, and lint/transpile
on save. base-node contains everything to package your application into a
minimal Docker container (<10MB compressed + your minified, transpiled code)
with io.js. base-angular will give you a module system, LESS transpiling,
live-reload (LESS/CSS changes are injected without reload), and a minified,
cache-busted output that you can drop into any web server (minimal nginix
containerization in the works).

I'm sure the documentation could be better, but the Readme.md has enough to
get you started and the code should be very straight-forward.

Since I'm using git, I can set these master repos as the 'upstream' and
whenever I make changes to the base project (like, adding containerization
support) I can easily push that change out to all my projects and everything
gets tracked nicely in the revision graph. The `create.sh` script in base-node
will actually do that rewiring for you.

[0] [https://github.com/blakelapierre/base-
node](https://github.com/blakelapierre/base-node)

[1] [https://github.com/blakelapierre/base-
angular](https://github.com/blakelapierre/base-angular)

------
BinaryIdiot
Not a fan of transpiling; you go from having one language to having to
understand two (ish; ES6 isn't entirely different) while only being able to
debug in one. It's nice people can write in and actually use ES6 today but I
really don't think transpiling is worth it. I've been bitten by weird bugs in
transpilers before that wasted far too much of my time.

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

No, please no. Why would I ever want to deliver a library in both modes just
for some better / different syntax? Yes ES6 is nicer than ES5 but doubling the
modules isn't worth it at all.

~~~
cnp
I may be wrong, but I feel the anti-transpile crowd hasn't done their
research. Comments in this vein have been popping up for years and have been
resolved for years. Check out the transpiled Babel code -- it's what you would
expect, and sourcemaps take you the rest of the way.

~~~
BinaryIdiot
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".

~~~
tracker1
It's already been tried several times... and unless the big 3 browser makers
(google, mozilla and ms) all support a given approach it just won't happen. JS
is for better or worse what we get in the browser, and the subset
optimizations for asmjs is probably as good as what we will get broader
support for.

Transpilation is really the only option... And even using a common bytecode,
there will still be a compile step which is separate from the source, and
requires mapping to be able to associate the bytecode to the source with the
same potential for bugs you are complaining about.

~~~
BinaryIdiot
> It's already been tried several times... and unless the big 3 browser makers
> (google, mozilla and ms) all support a given approach it just won't happen.

Has it really been tried though? I've never seen more than a few half assed
attempts without all parties involved. I've love to see them come together to
work something like this out; the web as it exists today isn't nearly as
snappy or nice as native apps so I feel like something will eventually change
here. Whether that's the help of a bytecode implementation or something else
I'm not sure.

> And even using a common bytecode, there will still be a compile step which
> is separate from the source, and requires mapping to be able to associate
> the bytecode to the source with the same potential for bugs you are
> complaining about.

Yes there is always potential for compilation to introduce bugs but compiling
into a bytecode is vasty different from compiling into JavaScript. JavaScript
is a functional language with a lot of quirks; Java bytecode and .Net's MSIL,
for comparison, are very raw and fast with as few features as possible. It's
significantly better to compile into some form of bytecode for later execution
than compiling into another human-readable language.

------
z3t4
Switching from writing classes in other languages to using the JS prototype
made writing object oriented code more fun and much faster! The prototype way
was a step forward. I think it's very weird that JavaScript is now planning to
introduce classes, and that you guys are so exited about it.

~~~
d13
The new `class` syntax is just sugar on the ordinary prototypal way in which
JS developers have created "classes" for ages (functions which return
themselves as objects.) It just makes the code you have to write a little
prettier to look at.

------
kmfrk
If I just want to clean up some basic code in a .html file with a terminal
script - preferably with a "\--watch" flag, what's the simplest way of
accomplishing that?

Also seems like the best way to ease into it.

~~~
mrspeaker
My favourite way is via JSPM and live-server. I got into that after watching
this amazing dev video:
[https://www.youtube.com/watch?v=iukBMY4apvI](https://www.youtube.com/watch?v=iukBMY4apvI)

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

------
liviu
It's a pleasure for me to use webpack with Babel for my projects.

------
fibo
to transpile is not an happy idea

