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 :))
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.
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.
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.
It's true that there's not too many ES6 features implemented yet, but the 1.5 release will bring a lot of new ES6 features, and it's right around the corner.
TypeScript devs pushed their idioms to get it into ES6. Introducing optional typing to ES6/7 would be a good idea, but other C#/Java inspired syntax like "class" are a bit off-putting, if one loves the lean JS5 syntax. After all, JavaScript has prototype-based inheritance, so the new "class" keyword is weird (even if it's just syntactic sugar): http://en.wikipedia.org/wiki/Prototype-based_programming
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.
A little nick pick about TypeScript and I hope that other dislike its influence to ES6/7 too: Microsoft's mastermind behind C# and TypeScript: Anders Hejlsberg was the original author of Turbo Pascal and the chief architect of Delphi. In 1996, Hejlsberg left Borland and joined Microsoft. One of his first achievements was the J++ programming language. Since 2000, he has been the lead architect of the team developing the language C#. In 2012 Hejlsberg announced his new project TypeScript—a superset of JavaScript. I sincerely hope he stays away from ES7 - I don't like his syntax preferences. (ES4/AS3 syntax was already weird as hell, and good that it failed.) ES5/JavaScript 5 was so great and lean - so refreshing coming from C++/Java/C#. TypeScript feels a bit like a Trojan horse that emerges as ES7. As the linked article says "TypeScript: Is basically ECMAScript 6 plus optional type annotations." Or the other way around, they turned the beloved ES5 to Hejlsberg's TypeScript. So don't destroy ES7.
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).
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!
If you break up your application into separate npm modules, each module's transpile time can be reduced quite a bit to where you're unlikely to even notice.
I have no doubt of that, this is for all front-end code ATM (we don't used node except for gulp). It was hard enough to move us to what we are doing now it will be some time before we get nice npm modules :(. I am looking into the options for front-end modules (CommonJS and friends) because I would like to break our stuff up a little better. It's leaps and bounds over what we started with (separation of interests-wise) but I have to be careful not to push the envelope too far and have the other devs throw up their hands and give up. Gulp was a HUGE step and it hasn't even been a full year on that yet. Bower was pretty hard as well but the team seems to have gotten over that now.
It's probably easiest to start with any 3rd party modules already in npm.. jquery & plugins etc... from there it gets easier... assuming you're requiring in your classes and exporting already.
Oooo, I haven't seem that, that's pretty neat. If our current method doesn't end up working out (been doing well for over a month now) and/or I get the time to address the initial 30 sec build then I will look into this. My only concern is our sourcemaps which have been.... finicky... at best. They work fine now that I've got them working but I had a hard time getting them to correctly spit everything out. Adding YAML to the files the yanking it out may have adverse effects on our sourcemaps but the only way to know is to try it out! Thanks for the suggestion, I've got it bookmarked now!
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.
Makefiles are great. But if you follow the principle "using the right tool for the right job", you'll most certainly in the end choose the building system of your infrastructure.
It would be the same if you suggest Java codebase to switch from maven to make. Yes ... it would be far difficult to do that.
I'd shy away from this personally due to SVN issues with renames/moves (yes, yes git is better, I'm working on convincing the people who control that decision) along with the fact that you will have to do it all over again in a year or two unless you plan on always naming your JS that way. My biggest reason for even trying not to run them all through the transpiler was speed.
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.
It's probably better to think of a given file as a "module" which is what it effectively is. I only say this because I'm not very fond of class based programming in JS, and usually prefer a functional approach. For me, objects are generic constructs and my modules export functions that can be composed/used against said generic/plain objects.
By using a more functional approach, you can chain promises or streams very effectively[1].
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?
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.
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.
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.
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.
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.
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".
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.
> 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.
I've been moving towards having my ES6-style code under `./src`, and having the transpile (and module configured) to `./dist` ... when I want to access the es6 version (say from babel-node, I can simply require `mymodule/src`, which is more direct.
Also, if you are creating more discrete modules, the transpile time for a given module isn't bad at all. From a given project, I'm just bringing in `mymodule` and don't have to think about it beyond that... using jsparta, I can test against the es6 version for coverage, etc... and with mappings, the merged/minified JS the client sees can still reference the real starting point.
for the most part it's much friendlier when you embrace npm/node workflows with browserify (or webpack). With this in place, you always write/work against your es6-style. I use commonjs module syntax instead of imports, but may change my approach in the future.
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.
Another neat trick I've learned recently is that when you are debugging in a modern browser that does not require certain features to be transpiled, you can simply blacklist them in Babel and debug them natively. Then when you are deploying you can turn transpiling back on for everything and support every browser. (Note: be careful that you don't blacklist features with buggy implementations)
Transpiling is quite nice, and it's very likely that you already do it with something like Uglify or Closure compiler.
> 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.
ES6 isn't just some nicer syntax/features, it's the future of JavaScript and transpilers are the way we are going to get there.
> 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.
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.
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.
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].
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.
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.
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.
57 comments
[ 2.8 ms ] story [ 154 ms ] threadWhat 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.
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.
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.
It's true that there's not too many ES6 features implemented yet, but the 1.5 release will bring a lot of new ES6 features, and it's right around the corner.
A little nick pick about TypeScript and I hope that other dislike its influence to ES6/7 too: Microsoft's mastermind behind C# and TypeScript: Anders Hejlsberg was the original author of Turbo Pascal and the chief architect of Delphi. In 1996, Hejlsberg left Borland and joined Microsoft. One of his first achievements was the J++ programming language. Since 2000, he has been the lead architect of the team developing the language C#. In 2012 Hejlsberg announced his new project TypeScript—a superset of JavaScript. I sincerely hope he stays away from ES7 - I don't like his syntax preferences. (ES4/AS3 syntax was already weird as hell, and good that it failed.) ES5/JavaScript 5 was so great and lean - so refreshing coming from C++/Java/C#. TypeScript feels a bit like a Trojan horse that emerges as ES7. As the linked article says "TypeScript: Is basically ECMAScript 6 plus optional type annotations." Or the other way around, they turned the beloved ES5 to Hejlsberg's TypeScript. So don't destroy ES7.
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).
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
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:
(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
You can combine it with gulp-if, to isolate those files that need compilation.
1: https://www.npmjs.com/package/gulp-front-matter
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.
It would be the same if you suggest Java codebase to switch from maven to make. Yes ... it would be far difficult to do that.
But as the other commenter said, all es5 JS is valid es6 JS...
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.
By using a more functional approach, you can chain promises or streams very effectively[1].
[1] https://twitter.com/tracker1/status/558390877563801601
Also seems like the best way to ease into it.
https://kangax.github.io/compat-table/es6/
Further than that, it's silly to compare browsers that aren't stable yet.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=950547 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1023609
> 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.
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".
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.
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.
Also, if you are creating more discrete modules, the transpile time for a given module isn't bad at all. From a given project, I'm just bringing in `mymodule` and don't have to think about it beyond that... using jsparta, I can test against the es6 version for coverage, etc... and with mappings, the merged/minified JS the client sees can still reference the real starting point.
for the most part it's much friendlier when you embrace npm/node workflows with browserify (or webpack). With this in place, you always write/work against your es6-style. 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.
Another neat trick I've learned recently is that when you are debugging in a modern browser that does not require certain features to be transpiled, you can simply blacklist them in Babel and debug them natively. Then when you are deploying you can turn transpiling back on for everything and support every browser. (Note: be careful that you don't blacklist features with buggy implementations)
Transpiling is quite nice, and it's very likely that you already do it with something like Uglify or Closure compiler.
> 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.
ES6 isn't just some nicer syntax/features, it's the future of JavaScript and transpilers are the way we are going to get there.
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.
If anyone has any questions, feel free to ping me or stop by our support chat[1].
[1] https://gitter.im/babel/babel
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.
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
[1] https://github.com/blakelapierre/base-angular