Most ES6 features are either equal to or worse than their ES5 counterparts in terms of performance, some by orders of magnitude (!)<p>For example, `class` has particularly bad performance characteristics because under the hood it has to set an object's prototype on the fly (at least this is how Babel implements it) [1] and `super` is also slow due to prototype lookup [2].<p>[1] <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/setPrototypeOf" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...</a><p>[2] <a href="https://jsperf.com/es6-classes-super-es5-vs-transpiled/2" rel="nofollow">https://jsperf.com/es6-classes-super-es5-vs-transpiled/2</a>
Always getting 'app.js:22 Uncaught TypeError: Cannot set property 'kind' of undefined' :-(<p>However, I doubt that I would use it - most of the 'modernizations' are really dependent on the context of each change and require some tweaking.<p>For instance, ES6 classes do not allow for inline computed methods:<p><pre><code> const x = function () {};
x.prototype.a = wrapFunction(function(){});
</code></pre>
--- this is impossible: ---<p><pre><code> class x {
a() wrapFunction(function(){}); // invalid :-(
}
</code></pre>
So we're still required to use the explicit prototype way of declaring the class.<p>Then you can't just rewrite all methods to arrow functions because they don't have prototypes, even when they're really tempting:<p><pre><code> var x = function () {};
x.prototype.a = <foo>;
</code></pre>
---><p><pre><code> var x = () => {};
x.prototype.a = <foo>; // cannot set a of undefined
</code></pre>
...<p>$0.02
Wow, the example is atrocious,<p><pre><code> Person.prototype.getAge = function (birthYear) {
var age = 2015;
age -= birthYear;
return result;
// Do you mean return age?
};
Object.defineProperty(Person.prototype, 'age', {
get: function () {
return this.getAge();
// getAge function takes a required parameter.
}
});</code></pre>
Trying some simple this-based class/instance-construction in the constructor leads to the whole thing failing:<p><pre><code> var Person = function (name) {
console.log('This is the constructor.');
var _name = name;
this.getName = function() {
return _name;
};
};
</code></pre>
Since this is 1 of the 2 patterns for creating classes, and the only one which supports encapsulation, it seems like a strange omission.<p>Especially so if the goal is to migrate "old" javascript to get it "modern". Migrating bleeding edge JS to even more bleeding edge JS hardly seems like a very worthwhile endeavour.
It's not like your JS won't run on ES6 browsers. That's the whole point of backwards compatibility. Besides, older features will probably have better performance as they have been tuned for years, compared to newer features.<p>People in the JS world should seriously drop the NIH syndrome and contribute to existing tools instead. The last thing we'd ever need is yet another framework/library/tool that's just a bit more than what's already existing.<p><a href="http://www.isaacchansky.me/days-since-last-new-js-framework/" rel="nofollow">http://www.isaacchansky.me/days-since-last-new-js-framework/</a>
I would also recommend: <a href="https://github.com/alcuadrado/hieroglyphy" rel="nofollow">https://github.com/alcuadrado/hieroglyphy</a>
I don't see this as a real benefit to update your code, but maybe as a learning tool to see how your code would be implemented using es6.<p>I like to take a wait-and-see on these language updates to see which parts get widespread adoption. I find the most important part at this point isn't the features, but having code that the majority of developers can understand.
Demo box felt claustrophobic. I pasted in code and nothing appeared on the other side. An error message would have been nice. Ah well, I'll probably check this out again after a while.
i would like a es6 to es3 compiler.
When working with legacy devices it's a real mess, especially when you are used to sometimes use console.log..