9 ms·

Deploying ECMAScript 6

80 points by of 11y ago

apaprocki 11y ago
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 :))
- flyingmutant 11y ago
  There is an ES6 label for tracking these issues: https://github.com/Microsoft/TypeScript/labels/ES6 https://github.com/Microsoft/TypeScript/labels/ES6
- tinganho 11y ago
  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.
  - nothrabannosir 11y ago
    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/ 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.
  - nawitus 11y ago
    You can compile .ts to ES6 .js and then use babel to compile it to ES5 .js.
    - egeozcan 11y ago
      Doesn't it error-out with the unsupported syntax, for example, generators?
      - katabatic 11y ago
        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.
- nawitus 11y ago
  Check the roadmap: https://github.com/Microsoft/TypeScript/wiki/Roadmap https://github.com/Microsoft/TypeScript/wiki/Roadmap 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.
- frik 11y ago
  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 http://en.wikipedia.org/wiki/Prototype-based_programming
  - tracker1 11y ago
    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.
    - frik 11y ago
      Your are right. 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.
joshstrange 11y ago
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 11y ago
  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
  - woah 11y ago
    Js updates are backwards compatible
  - joshstrange 11y ago
    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
kmfrk 11y ago
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 11y ago
  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 11y ago
    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.
Someone1234 11y ago
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 11y ago
  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 11y ago
    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.
    - amyjess 11y ago
      s/IE/Mobile Safari/
    - tonyedgecombe 11y ago
      I was under the impression we are going to see regular updates to Spartan similar to what we get from Chrome now.
  - thejameskyle 11y ago
    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 https://bugzilla.mozilla.org/show_bug.cgi?id=950547 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1023609 https://bugzilla.mozilla.org/show_bug.cgi?id=1023609
- deleted 11y ago
BinaryIdiot 11y ago
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.
- AdamCraven 11y ago
  You can debug in both ES5 and ES6 using source maps. The support is very good. You're working in ES6 land most of the time.
- cnp 11y ago
  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 11y ago
    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 11y ago
      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.
z3t4 11y ago
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 11y ago
  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.
thejameskyle 11y ago
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 11y ago
  Is there anything wrong with being "stuck in an ES3 world"?
  - thejameskyle 11y ago
    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 11y ago
      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 11y ago
        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.
liviu 11y ago
It's a pleasure for me to use webpack with Babel for my projects.
jsprogrammer 11y ago
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
fibo 11y ago
to transpile is not an happy idea

80 points by of 11y ago

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 :))

flyingmutant 11y ago
There is an ES6 label for tracking these issues: https://github.com/Microsoft/TypeScript/labels/ES6 https://github.com/Microsoft/TypeScript/labels/ES6
tinganho 11y ago
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.
- nothrabannosir 11y ago
  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/ 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.
- nawitus 11y ago
  You can compile .ts to ES6 .js and then use babel to compile it to ES5 .js.
  - egeozcan 11y ago
    Doesn't it error-out with the unsupported syntax, for example, generators?
    - katabatic 11y ago
      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.
nawitus 11y ago
Check the roadmap: https://github.com/Microsoft/TypeScript/wiki/Roadmap https://github.com/Microsoft/TypeScript/wiki/Roadmap 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.
frik 11y ago
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 http://en.wikipedia.org/wiki/Prototype-based_programming
- tracker1 11y ago
  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.
  - frik 11y ago
    Your are right. 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.

joshstrange 11y ago

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 11y ago
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
- woah 11y ago
  Js updates are backwards compatible
- joshstrange 11y ago
  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

kmfrk 11y ago

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

Someone1234 11y ago

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 11y ago
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 11y ago
  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.
  - amyjess 11y ago
    s/IE/Mobile Safari/
  - tonyedgecombe 11y ago
    I was under the impression we are going to see regular updates to Spartan similar to what we get from Chrome now.
- thejameskyle 11y ago
  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 https://bugzilla.mozilla.org/show_bug.cgi?id=950547 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1023609 https://bugzilla.mozilla.org/show_bug.cgi?id=1023609
deleted 11y ago

BinaryIdiot 11y ago

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.

AdamCraven 11y ago
You can debug in both ES5 and ES6 using source maps. The support is very good. You're working in ES6 land most of the time.
cnp 11y ago
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 11y ago
  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 11y ago
    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.

z3t4 11y ago

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

thejameskyle 11y ago

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 11y ago
Is there anything wrong with being "stuck in an ES3 world"?
- thejameskyle 11y ago
  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 11y ago
    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 11y ago
      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.

liviu 11y ago

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

jsprogrammer 11y ago

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

fibo 11y ago

to transpile is not an happy idea