ES6 transpilation via babel

[trusktr]

@gadicc

this._doSomething();  // easy syntax for super's method

Does that rely on the underscore meaning super?

[trusktr]

@gadicc

Here’s a jsperf I did for the use of super() in ES6 transpiled classes:

That’ be great to post onto the Babel GitHub issue tracker. If it’s transpiling to ES5, it should only be marginally slower, one would think. EDIT: https://github.com/babel/babel/issues/2399

[trusktr]

@gadicc

You might say “ok so don’t use super()”

Yeah, right! That’s not happening. x}

[trusktr]

After seeing your findings, I’m totally down to go the pure ES5 route.

The loss of the satisfaction of how writing ES6 classes feels will be tiny compared to the gains in satisfaction from making the our library performant.

[talves]

@trusktr

After seeing your findings, I’m totally down to go the pure ES5 route.

The loss of the satisfaction of how writing ES6 classes feels will be tiny compared to the gains in satisfaction from making the our library performant.

I never realized how under performing ES6 transpiling is today! I am kinda embarrassed that I never really thought about it until now. In truth, there has never been a need to look at it before now. Interesting to me is I even asked "why did WillyBoat not use ES6" to the willyboat team and not one answer from them.

We really need to think about how we are going to set this up to eventually go to the the faster code base between ES5 and ES6.

• Is it safe to use ES6 modules?
• should we still maintain an ES6 code base. Let the transpiler ignore the ES5 code and change when supported browser versions support native ES6?
• would it be too much work to create the ES5 code from the transpile by stripping the wrappers? Always having the ES6 version ready?

I probably know the answers to most of these, but just want to throw them out in the case someone has a better idea than we come up with.

Edit: I have to take back some of my concern, because I was basing it on the tests above. Please see my test below. There should be no unexpected slow down of an extended class if written properly.

[trusktr]

@talves

to the willyboat team and not one answer from them

I asked Michael Obrien in person one time, and he said he loves ES6, but that performance would be out of their control.

[talves]

@trusktr

I asked Michael Obrien in person one time, and he said he loves ES6, but that performance would be out of their control.

Good to know that was the reason. Makes me feel better they came up with the same conclusion. Another example of documenting and being VERY clear about decisions, so we can just link to the explanation and not have to explain it

[trusktr]

@talves

Is it safe to use ES6 modules?

I think so, because that only affects the code wrappers prior to any code running, so even if it takes a looooong time to load those modules, it won’t actually affect the runtime performance of the app.

@talves

should we still maintain an ES6 code base. Let the transpiler ignore the ES5 code and change when supported browser versions support native ES6?

Yeah, I don’t see why not. Certain things should be just fine (ES6 modules for example). We can write classes in a forward-compatible manner by using ES5 classes and never calling the super contructor after the use of this.

@talves

would it be too much work to create the ES5 code from the transpile by stripping the wrappers? Always having the ES6 version ready?

Which wrappers? The module wrappers? I don’t that really matters because they are all evaluated at the beginning (unless we’re using HTTP/2 with JSPM, but when that becomes an official way to load modules ES6 modules may already be native, that’s my guess).

In general, I think we can continue using ES6 for certain things, just not for class definitions. Some things compile to really simple ES5 with no function wrappers. We’ve gotta experiment/research to find out what exactly.

[talves]

@trusktr

Which wrappers? The module wrappers?

No. I meant the class wrappers in this case.

[talves]

@trusktr

In general, I think we can continue using ES6 for certain things, just not for class definitions. Some things compile to really simple ES5 with no function wrappers. We’ve gotta experiment/research to find out what exactly.

Yeah, I agree with supporting as much as possible and doing the rest as it goes native. Could even have both versions, to show the benchmark for why we are still there. That way we know when to make the change also.

I personally would first write my code in ES6, create my benchmark tests, then convert to the performance enhanced equivalent.

[trusktr]

I don’t think the wrappers can be removed easily, but it’s possible. Someone would have to maintain that against Babel. That’d be cool to write ES6 classes and have it transpile to pure ES5 with no wrappers. It’s totally doable.

I don’t see why

class Foo extends Bar {
  someMethod() {...}
}

can’t simply become

function Foo() {
    Bar.apply(this, arguments)
}
Foo.prototype = Object.create(Bar.prototype)
Foo.prototype.constructor = Foo
Foo.prototype.someMethod = function someMethod() {...}

(in the simple case)

[trusktr]

@talves

I personally would first write my code in ES6, create my benchmark tests, then convert to the performance enhanced equivalent.

That’s a lot of extra work, unless we have a conversion script that converts to pure ES5 classes.

[talves]

@gadicc This was really bugging me. So I was trying to figure out why your tests would be so far off. 17x on a call to an extended function just made no sense to me. Transpiling should not have affected it like it did.

I see now that the first test over complicated the use of super to create a false positive test. I kept telling myself these two instances should be returning exactly the same code values and getting the exact same reference values in the parent class. The only slow down would have been in the instantiating of the classes, IF we were testing that case.

new test returning exact same values:
http://jsperf.com/es6-classes-super-es5-vs-transpiled/8

ES6 code

    class Base {
      constructor(data) {
        this.data = data;
      }
      getData() {
        return this.data;
      }
    }

    class Sub extends Base {
       constructor(data) {
         super(data);
      }
    }

ES6 Transpiled

function _inherits(subClass, superClass) { if (typeof superClass !== "function" && superClass !== null) { throw new TypeError("Super expression must either be null or a function, not " + typeof superClass); } subClass.prototype = Object.create(superClass && superClass.prototype, { constructor: { value: subClass, enumerable: false, writable: true, configurable: true } }); if (superClass) Object.setPrototypeOf ? Object.setPrototypeOf(subClass, superClass) : subClass.__proto__ = superClass; }

function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function"); } }

var Base = (function () {
  function Base(data) {
    _classCallCheck(this, Base);

    this.data = data;
  }

  Base.prototype.getData = function getData() {
    return this.data;
  };

  return Base;
})();

var Sub = (function (_Base) {
  _inherits(Sub, _Base);

  function Sub(data) {
    _classCallCheck(this, Sub);

    _Base.call(this, data);
  }

  return Sub;
})(Base);

ES5 code

    function ES5_Base(data) {
      this.data = data;
    }

    ES5_Base.prototype.getData = function() {
      return this.data;
    }

    function ES5_Sub(data) {
      ES5_Base.call(this, data);
    }

    ES5_Sub.prototype = Object.create(ES5_Base.prototype);
    ES5_Sub.prototype.constructor = ES5_Sub;

###Instances

this.es6t = new Sub(5);
this.es5 = new ES5_Sub(5);

###Test Cases

this.es6t.getData();
this.es5.getData();

You will be glad to know, I also increased the performance of the ES5 code at the same time as the ES6 code and they should be performing about twice as fast as the first example test.

I am going back to writing ES6 in most cases

[Steveblue]

Had anyone tested traceur compiler vs Babel? Traceur-runtime may not have some of these perf problems.

[trusktr]

@Steveblue

Had anyone tested traceur compiler vs Babel?

I haven’t tested, but check out how Traceur transpiles a simple ES6 class. It seems like a lot of overhead.

@gadicc

Yeah, I just rolled my own for now :> It looks like this:

var subComponent = Component.extend({

I went ahead and rolled my own class lib too: http://npmjs.com/lowclass. I tried to make it as performant as possible, generating pure ES5 classes.

[gadicc]

@talves, sorry, my test wasn’t 100% clear… the important super was the one inside the overriden getData, since that’s what we’re testing :> The one inside the constructor was actually superfluous and was left over from something else I was trying, but wasn’t counted in the test time anyway, since we weren’t timing instantiation.

In any case, I really feel I have to stress again, I am only talking about using ES5 for components and other high traffic functions. We can benefit from beautiful ES6 classes everywhere except for things that are running 10,000 times a second. Even though it’s quite a big difference, I don’t think it’s something you’ll feel anywhere else.

Super also was obviously one of the worst performing examples. I did link it before, but here’s the time comparison matrix including babel vs babel-loose vs traceur. http://kpdecker.github.io/six-speed/. (I added it to the resource section too).

One of the reasons why some things in babel are so slow is because of strict ES6 compliance. If you run it in “loose” mode, it will be much faster, but then when the day comes for native ES6, (potentially) some of the code you wrote before that did work, won’t work anymore. So I don’t think that’s the best route. ES5 will always work.

I’m going to see how easy it is to move the browser version/adoption conversation into a new thread, I think it’s an important topic: Browser support, share, usage, adoption, upgrades, etc

[gadicc]

Edit: sorry this is an older post that I moved accidentally and now is here out of order since I moved it back

@trusktr

Did you separate the Babel runtime?

No, I was only looking at the running time of the method of an already instanced class.

@trusktr

How old are we targetting? (re browsers)

We’d need to do some proper research into browser usage (including native webviews on mobile) to make a final call, but my main point was just that, if some optimization will solve some problem for us and is expected to land in “the next chrome-beta”, we should not assume that this fix is acceptable for all our users (i.e. our users’ users) most of whom probably won’t be keeping their browsers constantly up-to-date.

e.g. according to https://kangax.github.io/compat-table/es6/, no current browser (including google chrome beta and canary) has native ES6 class support… some do if you enable flags for experimental javascript (which is unrealistic to expect all users to do), and some implementations aren’t final. So I think we’ll still be relying on transpiled code for some time to come (there’s also the issue of intelligently detecting the browser environemt and serving raw ES6 if it’s fully supported).

@trusktr

(re ES6 class restrictions)

Yeah, I said both things made sense, it was just annoying come from the more permissive ES5 That said, great news about the ES6 Java-like properties; that’s exactly what I was looking for… inheritable properties that could be overriden per subclass or instance. Shot!

@trusktr

How fast will ES6 classes be when they are native, compared to ES5 classes?

I think we can assume it will be at least as fast or possibly even faster since it’s more restrictive. On the performance grid, native ES6 is marked as “identical” for all browsers for classes. But as per above, I think it will be a while before we can bank on all our users (and their users) having native ES6 browsers.

@trusktr

Here are some prototype class libraries… We could of course roll our own in like 20 min.

Yeah, I just rolled my own for now :> It looks like this:

var subComponent = Component.extend({

   doSomething() {
     this._doSomething();  // easy syntax for super's method
   }  

});

It was quite handy because it let me do a bunch of other tweaks and per component code that would be an extra few lines per class otherwise.

@Steveblue

I think these performance concerns are only really concerning in the interim until browsers update for ES6. We can target a release for when ES6 is in most browsers but until then take the perf hit, I think that is acceptable.

I don’t know so much. Most end users won’t know things about “oh I need to upgrade my browser for ES6 speed improvements”. The whole idea of transpilation is the assumption that it will take users much longer to upgrade than developers. People are going to look at an infamous demo, or a product using infamous, and say “wow, this feels like crap… it doesn’t deliver”, not “oh, wait, let me upgrade my browser first”.

Again, I’m not saying don’t use ES6… my main point is for high traffic code (e.g. components) As per:

@talves

Since truly performance critical code tends to be isolated in relatively few hot spots, you always have the option of rewriting just those few bits of code in whatever style performs best, and otherwise reaping the benefits of the new language features throughout the overwhelming majority of your code. - Ben Newman (from original React team, now at Meteor)

So let’s look at components again… Say 100 nodes with 5 components each, that’s potentially 500 updates a frame, and at 60fps, 30,000 updates/second. Even a 33% difference can make a huge different with these numbers. To be clear though, I’m not talking about load time, class definition time, or instantiation time (which as @talves correctly said, is addressed by proper pooling). I’m only talking about function calls.

Here’s a jsperf I did for the use of super() in ES6 transpiled classes:

http://jsperf.com/es6-classes-super-es5-vs-transpiled/2

To be clear, after definitions, the only thing I’m testing/timing is:

someInstance.getData();

which calls it’s super’s getData to return the result (actual test code available in the link).

In Chrome, native ES5 was 27.5x faster, and in Firefox, 56.4x faster. That is a pretty huge deal, and was very noticeable when I was profiling components. Apparently it has to do with ES6 strictness… there’s a more permissive option which is only 1.7x slower (Chrome) and 5x slower (Firefox) , which is still way too much in my mind for components, but also:

1. It means you’ll be able to write code that will work transpiled but break in native.
2. It means we’ll have to explain to our users to use a non-ES6 version of our code or to enable this option which affects all their code too (assuming they have a babel setup).

Obviously also affects anything components use, such as utility classes, and probably Node methods.

You might say “ok so don’t use super()”, but well, is our approach then “use ES6 classes but don’t use their features?”. Yes, although instead of super, we could do the prototype call ourself, this is still just similar to the babel-loose example where there’s still a lot of overhead from all the wrapped code (we’re still calling the prototype of an ES6 transpiled class).

And then we have to do this kind of research for everything we use. I just think it’s much safer to do components (and probably anything they use) in ES5. We’re going to be judged on performance, and I think we should assume most of our users won’t be using ES6 browsers by the time we have something out and for quite some time after.

[talves]

@gadicc

sorry, my test wasn’t 100% clear… the important super was the one inside the overriden getData, since that’s what we’re testing

@gadicc Don’t be sorry, it is a valiant point you are making. Although I disagreed with how you ran the test, I am starting to see ES6 “transpiled” classes as an unnecessary and maybe evil code sugar.

Here are two articles I will point to for my decision, until they are fixed either by going native or a better prototypical design in ES7. I have been going down the rabbit hole based on my belief that classes will solve other problems when in reality they are just creating new ones.

The Two Pillars of JavaScript
How to Fix the ES6 ‘class’ keyword

I agree with the following quote 100%. We know we can add performance to the statement when transpiled.

P.S. Don’t use super unless you enjoy stepping through the debugger into multiple layers of inheritance abstraction. 1

[trusktr]

@gadicc

(there’s also the issue of intelligently detecting the browser environemt and serving raw ES6 if it’s fully supported).

Even when ES6 classes are native, I don’t think that can be done, at least not yet (not without evaling everything really slooooooooowly). But, if a way to make it happen become reality in browsers, then we could stick with a single syntax if we do like in the following examples.

Use ES5 for components.

// --------------- Component.js - an ES5 class?

export default
Class ('Component', {
    // No constructor here, so it'll have a default one, the same as in ES6.
    someMethod() {
        let something = 'something'
    }
}, 'es5')

// --------------- SomeComponent.js
import Component from './Component'

export default
Class('SomeComponent') .extends ('Component', {
    SomeComponent() { // constructor
        this.super.call(this)
    },

    aMethod() {},
})

Nodes to ES6?

// --------------- Node.js - an ES6 class?

export default
Class ('Node', {
    someMethod() {
        let something = 'something'
    }
}, 'es6')

// --------------- SomeComponent.js
import Component from './Component'

export default
Class('SomeWorldlyThing') .extends ('Node', {
    SomeWorldlyThing() { // constructor
        this.super.call(this)
    },

    aMethod() {},
})