@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