Xto6 modernizes your JavaScript code
xto6.js.org
xto6.js.org
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].
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[2] https://jsperf.com/es6-classes-super-es5-vs-transpiled/2
https://babeljs.io/repl/#?experimental=true&evaluate=true&lo...
I didn't test the performance impact though. Also it's still a mystery to me how to enable Loose mode in Babel 6.
So far the only features that are actually fast are generators and the new data types (Map, Set, et al).
[1] https://jsperf.com/for-vs-for-of/2
[2] https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...
I guess your application: - doesn't intensely manipulate the DOM (otherwise your js performance shouldn't really be the bottleneck). - isn't easy to parallelize. - or you already make massive usage of web workers and you still had issues.
No sarcasm at all, I've recently refactored in ES6 the code-base I'm working on, without noticing any performance issues, and we really gained in readability and maintainability doing so. That's why I really wonder what could lead me to do the exact opposite.
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.
For instance, ES6 classes do not allow for inline computed methods:
const x = function () {};
x.prototype.a = wrapFunction(function(){});
--- this is impossible: --- class x {
a() wrapFunction(function(){}); // invalid :-(
}
So we're still required to use the explicit prototype way of declaring the class.Then you can't just rewrite all methods to arrow functions because they don't have prototypes, even when they're really tempting:
var x = function () {};
x.prototype.a = <foo>;
---> var x = () => {};
x.prototype.a = <foo>; // cannot set a of undefined
...$0.02
class x {
a = wrapFunction(function() {})
}
This kind of use case is pretty well covered by ES2016 decorators as well (they're a bit more general as they act on property descriptors, not just values): class x {
@functionWrapper
a() {}
}Even otherwise, I'm sure this was a fun and challenging project for the author.
So, more like this. And congrats on release.
The I'm unlikely to use a tool like this is because I find the exercise of updating the codebase manually an important. Really understanding how and why ES6 syntax can clean up your code and how to use it properly.
Also, how many times do you get such a good opportunity to re-factor everything? This is a great excuse. Make it better, not just ES6ify.
Finally, improve your regex by updating certain elements of your code. A good example is moving all var statements to let across whole codebase, and then finding cases where you can 100% use const, and replacing all of those.
I've done this update recently (as have a lot of people) and it was great. If you do it right, you should delete more code than you add, and avoid numerous bugs by using const.
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.
}
});The Better Parts by Douglas Crockford: https://youtu.be/Ji6NHEnNHcA
Now what I really wish to see in JavaScript are real Immutable Objects. Like, any variable declared with const makes that Object Immutable, not just preventing it from being reassigned. That, imo, would take JS to the next level. That and something like TypeScript/flow built in to native JS. It's do-able, and I see it happening way down the line, maybe es8/9 haha....
var Person = function (name) {
console.log('This is the constructor.');
var _name = name;
this.getName = function() {
return _name;
};
};
Since this is 1 of the 2 patterns for creating classes, and the only one which supports encapsulation, it seems like a strange omission.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.
edit: the original issue[5] specifically notes that the anonymous function shouldn't refer to `this` and the corresponding commit has a test case for that, though it doesn't talk about `arguments` so that might break.
The compiling seems very inconsistent and fragile:
* it won't convert at all if a function literal is returned or assigned to a variable (but it will if the function literal is passed to an other function or for IIFE)
* it will generate an incorrect conversion in case the `this` is deref'd for a method call or (directly or indirectly) passed to an other function: these are OK (will not convert)
(function () { this; })();
(function () { this.foo; })();
(function () { this.bar + 1; })();
but these are not ok (will convert to incorrect code): (function () { this.foo(); })();
(function () { foo(this); })();
(function () { foo(this.bar); })();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.
http://www.isaacchansky.me/days-since-last-new-js-framework/
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.
It's more like a reverse Babel. Babel does 6 to 5 , this does 5 to 6.
Also I think the similarity in color scheme is very intentional. As this seems like a wink towards babel, being an anti-babel.