You can't deny that ECMAScript 6 has given some much needed CPR to the Javascript language, but I think we have yet to see the true potential of Javascript discovered. I love the addition of modules, classes and all of the other new additions to the spec including my favourite => arrow functions. Small steps towards being a half-decent language.<p>I am already thinking ahead, ES7 is definitely going to be the pinnacle of the language I think. The implementation of a native Object.observe() means we will not have to worry about poor implementations in SPA frameworks like Angular that currently use dirty checking and other hacks to make up for the lack of native object observing. Lets hope the yearly release cycle proposed for Javascript specifications means ES7 happens sooner rather than later.<p>We have classes in ES6 (which is great), but they are currently nothing more than syntactic sugar over the old tried and tested prototypical inheritance. There are plans to add statics, private/public variables and classes to further extend them beyond just eye candy which they currently are. Plus Async/Await, Typed Objects, etc. There are also plans to better supported multithreading without the need to use WebWorkers which are pretty limited in their use.<p>Get excited. ES6 is only the beginning of a great suite of changes coming to Javascript. We'll eventually weed out the hacks and non-pretty parts of Javascript one specification at a time.
I'd just like to point out this is like the fourth post in the last 24 hours in the front page to mention the babeljs transpiler.<p>While transpilation was possible with Traceur before - babel has made it really easy and the fact issues are addressed within a day and the author is an overall great guy really helps.<p>I've never been able to fully switch to Traceur - but ever since babel (used to be 6to5) came along I've made the switch and never looked back.
Can anyone explain the forwards compatibility plan for es6? I get we can transpile, but that's not a gradual strategy for converting code. Since you can't polyfill syntax, are we just supposed to all transpile until some far flung day when browsers without es6 support finally reach some tiny percentage?<p>Is the assumption now that browsers largely auto-update that it won't be so long before that happens? Why are breaking syntax changes not a big deal, whereas "use strict" was done as a string so older browsers would ignore it?<p>Edit: backwards compatibility -> forwards
I really like destructuring, but I worry about arrays becoming popular for multiple returns. If I'm using some other module, I <i>really</i> don't want to have to remember the order in which the parameters come, or be forced to check documentation or implementation to know for sure.<p>With an object, I can use a console log or a debug break point and immediately see the key value pairs (hopefully well-named) without having to check the function implementation or docs to see in which order the authors decided to return (or yield, etc.) values.<p>Can we just agree now not to use array destructuring as an excuse for returning multiple disparate values in an array? Or at least in only some idiomatic form? [error, value] would actually make sense to me, as it follows popular Node conventions.
For those of you who want some longer read on ES6 there's a work-in-progress (but already quite informative) book from Nicholas C. Zakas, available for free on github:<p><a href="https://github.com/nzakas/understandinges6" rel="nofollow">https://github.com/nzakas/understandinges6</a>
I think that it's outlandish and silly that ES6 doesn't have a safer, more sound philosophy about type systems, e.g. like the elegant and rational one in TypeScript today.<p>The web needs increased consistency and cohesion in the HTML/CSS/JS triumvirate.<p>ES6 seems like a grab-bag of neat and fun new features that end up doing a whole lot of nothing for large projects that have to care about more tangible concerns than nicer ways to create anonymous objects.<p>Some of the new features of ES6 - Symbols, proxies, Object.observe, et cetera - seem to make it downright easier to write even more confusing code. Instead of increased rigor and tools for building better software, we get stuff like this:<p><pre><code> let obj = {
["h"+"ello"]() {
return "hi";
}
};
obj.hello();
</code></pre>
While I think it makes sense to stick with TypeScript for the foreseeable future, I do look forward to The Next JavaScript.<p>However, I can't help but wonder if that's due to a mild case of Stockholm Syndrome setting in.
I've been writing most of my Javascript in ES6 recently and I agree that it's simply fantastic and still has a lot of potential to be explored when it comes to creating modern apps and frameworks. My main problem is that we're going to be stuck using transpilers for quite a while as by the time all of the browsers finally[1] catch up to ES6, ES7 will be released. Unfortunately, there's not much we can do about slow vendors.<p>1 - <a href="http://kangax.github.io/compat-table/es6/" rel="nofollow">http://kangax.github.io/compat-table/es6/</a> (Note: Opera, Safari, and iOS8)
If you want a more extended summary of ES6 features, Axel Rauschmayer's “Using ECMAScript 6 today” is pretty good: <a href="https://speakerdeck.com/rauschma/using-ecmascript-6-today" rel="nofollow">https://speakerdeck.com/rauschma/using-ecmascript-6-today</a>