Anyone using ES6 yet?

[alex_h]

I've been thinking about starting to work in ES6, but then I saw this article:

 

http://www.incaseofstairs.com/2015/06/es6-feature-performance/

 

so now I'm having second thoughts. By the sound of it the transpiled code may often run more slowly than writing equivalent code directly in non-ES6 javascript. Is there anyone using Babel or Traceur or equivalent to write their games that could comment on their experience of this?

[d13]

I've been using ES6 every day for the past 18 months (first using Traceur, now using Babel).

Don't let that article scare you.

I haven't done any benchmarks but subjectively I haven't noticed any performance hit at all.

(But over that same period I've noticed many performance problems due Chrome and Firefox rendering hiccups through different browser versions.)

 

I would just go with the flow and enjoy ES6.

Unless you writing a game in Assmebly, you're always going to have a big performance overhead anyway because your high level code that has to work it's way down through dozens of software and architectural layers.

And each layer takes its bit of performance tax.

So I would just let the browsers and transpilers work on optimization under the hood for you - they'll sort it all out over time.

[alex_h]

Ok cool, thanks for the reply. But I'm not sure I'm convinced by the argument 'you may as well use ES6 since you already have a big performance overhead'. Surely the opposite is true? I already have a big performance overhead therefore I should try to improve performance wherever possible, for example don't use a transpiler if I don't need to. But I guess it will depend on the game you are making, and which are the baseline devices you have to support. I'm currently working on a game that is much more processor intensive than the work I normally do for example, so in this case I would definitely not want to make any decisions that would make the performance even worse. But maybe in most cases the impact of using ES6 is small enough that you can get away with it.

[d13]

 for example don't use a transpiler if I don't need to. 

The transpiler just converts the ES6 to ES5, so you're just running optimized ES5 in the browser anyway.

It doesn't add overhead in the sense of more code to process at runtime

If you need to do micro-optimizations, just tweak your code by avoiding certain structures as you would normally do with ES5/ES3 (for example, avoid forEach and use a good old for-loop for things like particle effects instead).

[alex_h]

It doesn't add overhead in the sense of more code to process at runtime

 

What I took the article I linked to to suggest is that say for example I write some ES6 code that uses a feature like Template Strings, when the transpiled code is run it can sometimes be slower than if I had just used normal strings in the first place. But then this kind of stuff always boils down to being dependent on specifics like how you are trying to use the ES6 feature and so on. In any case it's good to know that you have been using ES6 for a while without any sign of ill effects. 

[d13]

 a feature like Template Strings, when the transpiled code is run it can sometimes be slower than if I had just used normal strings in the first place. 

 

Here's an ES6 template string:

console.log(`Tiger world x: ${tiger.getGlobalPosition().x}`);

When I run this through Babel, it turns it into this ES3/5 code:

console.log("Tiger world x: " + tiger.getGlobalPosition().x);

This is the code that actually runs in the browser

So, it shouldn't be any slower than a normal string... because it is a normal string 

[alex_h]

Ha ha, maybe I chose a poor example there  But thinking about it maybe most of the ES6 features I'm likely to want to use are also ones that would just transpile in a very straightforward way, stuff like classes, modules, let, const, etc. I guess its the more complex stuff like generators and so on where things could get a bit weird.

[jkohler]

I used ES6 for prototype projects only. I hope it matures!

[webcaetano]

I am using.
And i freak enjoy it

BabelJS + GulpJS

 

The best diference in my opinion is

JS standard

function a(x){  x = x || "default value"  return x;}

JS ES6
 

function a(x="default value"){  return x;}

and

 

 

JS Standard 

var a = "s"+"t"+"r"+"i"+"n"+"g";

JS ES6

 

var a = `string`;

Look at full features here https://github.com/lukehoban/es6features

[jfhs]

No, I actually don't use ES6 yet. Why? Because I don't need most of the features it adds.

 

Classes? It's just another syntax for what you can already do.

Promises? I already use those with a shim.

Tail-call optimization? I won't get this from a transpiler...

 

And the few other things I'd like to use from ES6 (default arguments, arrow functions etc.) are not important enough for my taste to justify the added complexity of using a transpiler.

[alex_h]

Just saw a twitter poll of 2295 js devs, 36% using ES6, 64% not using it yet

 

https://twitter.com/JavaScriptDaily/status/660074434821246976

[rhmoller]

I used ES6 for my entry for the JS13K competition. The only problem I ran into was that for..of loops are transpiled to ES5 code that uses Symbol. Safari does not support Symbol and the babel-polyfill was too big for the 13kb size limit, so I had to rewrite some of the code to use the forEach() methods on Array and Set instead of for..of loops

 

http://js13kgames.com/entries/galactic-backfire

 

I did not experience any practical performance issues on the devices I tested on.

[mattstyles]

Ha ha, maybe I chose a poor example there  But thinking about it maybe most of the ES6 features I'm likely to want to use are also ones that would just transpile in a very straightforward way, stuff like classes, modules, let, const, etc. I guess its the more complex stuff like generators and so on where things could get a bit weird.

 

Nope, not at all, babel and traceur both compile to es5, I think you missed how important that is. Also, bare in mind it doesnt just compile down to 'something that works', the compiled code is benchmarked, tested, gone through the wringer, it is code that is compiled in a specific way to be performant (yes, it is generalising so theoretically there are some edges where hard-writing it yourself would be marginally better, but, you'd get the proper gains from restructuring your code and that is well outside the scope of any transpiler so for any practical applications the transpilation is more likely to speed up your code than slow it down).

 

The problem that you're actually hitting on is this: you'd never write es5 in the way that generators (for example) get transpiled, you'd use a different design pattern. This may be true but if thats the case then you simply instrument your code and write those hot paths in whatever way you want, the transpiler will only touch specific bits of your code, namely the unsupported constructs. Mingling es5 and es6 code in the the same code base does not require any special build beyond the regular transpile you'd be doing anyway.

 

Infact, babel have just gone v6 which allows a number of ways to easily select which features you want to transpile, if, for example you were only targetting chromium and node v4 (which you would in an Electron app, for example) then there are only a few things you'd need to transpile as es6 is fairly widely supported, however, in this case you'd have to consider that V8 is not optimised for any es2015 code so you might well find that transpilation provides more performant code with an acceptable bloat.

[WombatTurkey]

Closest thing I'll ever use is arrow functions and template strings. Other than that, my mind cannot take in everything.

 

 

8:24

 

ES6 in a nutshell

 

Edit: Although, there is some cool stuff just not for me 

[mattstyles]

Sorry, just realised I didnt actually answer your question:

 

Yep, use a solid amount of ES2015 features, infact, I use some experimental features fairly heavily too. These things I use regularly:

 

Classes - yep, its currently just sugar but I find it a nicer syntax.

 

Class properties - This is ES2016/experimental spec, but when used in conjunction with arrow functions give you lexical scope (arrow functions and their actual scope is tricky, its probably not what you think, but, practically, it gives me what I need).

 

Class statics - Again, sugar, but I use them all over the place.

 

Module syntax - not supported anywhere but its very similar to commonJS. I like the destructuring sugar for named exports. Not so useful for library code but fine for application code. Requires transpilation as no native support, and likely will not be for a while.

 

Default functions and Spread - proper nice sugar for arguments.

 

Maps, weak-maps and sets - invaluable. 

 

Computed dynamic object property names - I think this I love the most.

 

Async/await - Again, this is experimental and not supported anywhere so you need a transpile and a polyfill, but, this is wonderful. Tidies up callback or promise-laden code and allows try..catch to be used for asynchronous code. Tentatively suspected to be implemented maybe Q2 2016.

 

I like arrow functions but a stack trace with named functions is so much nicer. Similarly, template strings are good, but I find myself only rarely using them. Symbols I use for privacy, but, this tends to just complicate things so I often wont bother. Proxies I've used once and it worked perfectly but I'll normally use other patterns.

 

Stuff that has been around longer (or polyfilled for ages) like `Object.assign` and Promises I'll lean heavily (although I'm more async rather than promise, but the perf isnt great).

[alex_h]

@mattstyles thanks for the detailed info! I need the right project to come along where I can get started with this stuff

[mattstyles]

Yeah, there are lots of nice stuff. It's really aimed at building stuff that is approaching a 'proper' app. But, yeah, as far as I know, the optimisation of those features in browsers hasnt really happened so, while Chrome/FF/Edge support most of the features, they arent optimised, so its always that trade-off between performance and developer ergonomics.

 

Of course, if you're targetting older browsers you have to transpile because serving up the correct versions to each browser is tricky tricky tricky i.e. serve ES6 code to Chrome but transpiled to IE9 is a mega hard thing to do. Part of the module and transport spec is actually dealing with this with the end-goal of transpilation and serving being fast enough to transpile on the fly based on browser specifications. This sort of stuff is likely a long way off being practical.

[Pengeszikra]

ES6 is another dimension ( compared to ES5 ) thanks by yield and generator, 

[mattstyles]

ES6 is another dimension ( compared to ES5 ) thanks by yield and generator, 

 

If you love that, you're going to love async/await

[lukaMis]

I use it mainly for let in for loops over var and fat arrow anonymous functions as they now what value of this should be so there is no need for shenanigans of type var self = this before set function. 

[mattstyles]

11 hours ago, lukaMis said:

I use it mainly for let in for loops over var and fat arrow anonymous functions as they now what value of this should be so there is no need for shenanigans of type var self = this before set function. 

Arrow functions actually have no scope, or, no context. They steal it from their parent closure. Usually this means `this` is what you would expect, but not always.