
ECMAScript 6 - dshankar
http://rauchg.com/2015/ecmascript-6/
======
DigitalSea
You can't deny that ECMAScript 6 has given some much needed CPR to the
Javascript language, but I think we have yet to see the true potential of
Javascript discovered. I love the addition of modules, classes and all of the
other new additions to the spec including my favourite => arrow functions.
Small steps towards being a half-decent language.

I am already thinking ahead, ES7 is definitely going to be the pinnacle of the
language I think. The implementation of a native Object.observe() means we
will not have to worry about poor implementations in SPA frameworks like
Angular that currently use dirty checking and other hacks to make up for the
lack of native object observing. Lets hope the yearly release cycle proposed
for Javascript specifications means ES7 happens sooner rather than later.

We have classes in ES6 (which is great), but they are currently nothing more
than syntactic sugar over the old tried and tested prototypical inheritance.
There are plans to add statics, private/public variables and classes to
further extend them beyond just eye candy which they currently are. Plus
Async/Await, Typed Objects, etc. There are also plans to better supported
multithreading without the need to use WebWorkers which are pretty limited in
their use.

Get excited. ES6 is only the beginning of a great suite of changes coming to
Javascript. We'll eventually weed out the hacks and non-pretty parts of
Javascript one specification at a time.

~~~
habitue
The changes you're hoping for sound like turning js into a java/c# kind of
language

~~~
frik
JS5 was nice, but the ES6 direction is increasingly driven by people who come
from the C#/Typescript and Java compiler front. Was it really necessary to add
"class" syntactic sugar? Some of the new ES6 and new Rust1.0 syntax additions
seem to be driven by the Ruby/Python/Scala front and don't look like proper
C/C++/JS/PHP syntax. Hopefully ES7 doesn't get the verbose syntax of Java/C#.
If people want syntax XY they should use a transpiler to JS or emscripten &
asm.js.

A good example is Facebook's Hack language that improve PHP in a sensible way
and adds optional typing - something that would be great for ES6/7.

~~~
ahoge
> _Was it really necessary to add "class" syntactic sugar?_

Yes. Now your editor/IDE knows that that _thing_ is supposed to be a class.
The doc generator also knows that it's a class. Furthermore, this makes things
more compatible since framework A and library B use the same kind of classes.

Finally, it means that you won't have to waste time with evaluating a dozen
semi-popular options to handle classes/inheritance.

It does of course also make your code a lot easier to read and it makes it
easier for new developers who used some other language with classes before.

> _Hopefully ES7 doesn 't get the verbose syntax of Java/C#._

I recommend to take a look at TypeScript and Dart. Optional types aren't
verbose. You just add some types to the surface area, which, compared to
JSDoc, is _drastically_ less verbose. Inside functions, you can generally omit
the types.

~~~
frik
It's a pity that optional types are still missing in ES6. As I wrote:

 _A good example is Facebook 's Hack language that improve PHP in a sensible
way and adds optional typing - something that would be great for ES6/7._

In comparision the Java/C# type is static at compile time. Newer C# version
have like e.g. Visual Basic 6 a variant type that is a tradeoff (as wasteful
as a "union struct" in C).

The class syntax in ES6 is just syntactic sugar. JS IDEs like
WebStorm/PHPStorm/IDEA already can parse "classes" with JS5 syntax .

But what about the _arrow syntax_ :

    
    
      var odds = evens.map(v => v + 1);
    

Or the iterator syntax that ES6 got from TypeScript:

    
    
      interface Iterable {
        [Symbol.iterator](): Iterator
      }

------
pornel
ES6 is especially nice with D3.js:

    
    
        .attr('transform', function(d) { return "translate(" + (d.x + 1) + " 0)"; })
    

becomes:

    
    
        .attr('transform', d => `translate(${d.x + 1} 0)`)
    

And:

    
    
        .attr({x:x, y:y, width:width, height:height})
        
        .attr({x, y, width, height})

~~~
j10t
I've been writing TypeScript exclusively for so long, I forget most devs are
still using the old syntax.

~~~
brianshaler
Same here, except with CoffeeScript.

~~~
recursive
But coffeescript doesn't even look like JavaScript. How could you confuse
them?

~~~
brianshaler
Several ES6 features very much resemble the few ways coffeescript syntax
differs from older versions of ecmascript. Arrow functions, destructured
assignment, string templates.

In context, we were commenting on this:

    
    
        .attr('transform', d => `translate(${d.x + 1} 0)`)
    

which looks pretty similar to the coffeescript counterpart:

    
    
        .attr 'transform', (d) -> "translate(#{d.x + 1} 0)"
    

Five subtle differences, but it shows how the things that are new/different
about ES6 are more similar to typescript and coffeescript than ES5.

------
inglor
I'd just like to point out this is like the fourth post in the last 24 hours
in the front page to mention the babeljs transpiler.

While transpilation was possible with Traceur before - babel has made it
really easy and the fact issues are addressed within a day and the author is
an overall great guy really helps.

I've never been able to fully switch to Traceur - but ever since babel (used
to be 6to5) came along I've made the switch and never looked back.

~~~
Bahamut
I like Traceur (at least with tools like System.js & jspm), especially with
its support for optional typing and annotations, but for some apps, Babel
makes a lot more sense.

I came across the difficulty of using jspm on the server and client for an
isomorphic React app I am building for an online community I run, and I was
advised to just use npm (& naturally Babel). Integrating browserify with
babelify into the build process was a far easier task.

~~~
egeozcan
OT, but I have to ask, do you use the flux pattern and if yes, any helper
implementation?

~~~
Bahamut
A bit OT response here.

I do not use the Flux pattern currently, but I am only in the beginning stages
of building out this app & am inexperienced with React, and I have to
coordinate getting others in this community involved too (two beginner/junior
developers & a mid-level/senior developer, and 2-3 artists/designers, none
with web designing experience). I have not evaluated how I want to handle
state changes yet - I may just go with the Flux pattern for practicality for
the beginner/junior developers' benefit career-wise.

This app is being built on io.js with Sails.js, isomorphic React, and ES6
(server and client) - I went with React because of its ability to do client-
side and server-side rendering for SEO purposes. I have a working isomorphic
React foundation, and working testing solution for the React code, but I still
have to get a server-side testing solution up, integrating optional Steam
authentication via OpenID, and figuring out build & deploy tooling into
separate environments. This is on top of gathering requirements from the
community & organizing it into a nice functional spec for developers to
consume...it is almost like creating a startup except that it will never be
for money, only for the love of the community I created ~7 years ago as a part
of a larger one.

~~~
egeozcan
Thank you very much for the detailed explanation. I once tried Sails and
didn't find it easy (or was it even not possible at all) to configure
relations for my models found on a PostgreSQL db. Do you have any plans to
open-source the "foundation"? I'd be interested to see how you structured it.

~~~
Bahamut
Honestly, it wasn't all that bad - I had to do a little customization in the
app.js script that gets generated on creation of a new Sails.js scaffold
(added require('babel/register') before var sails = require('sails') ), and
then created a simple browserify grunt task & inserted it into the pipeline. I
hijacked the views folder for all of my React code, and exposed every React
component via a top level script, including the router, so I could make use of
all of them for custom code in both the server and client.

For the models with Sails, I haven't touched that yet - the plus side for me
is that there is no schema yet, so I am still free to set everything up in the
database as I wish. If you need to configure relations, there are details
listed here:
[http://sailsjs.org/#!/documentation/concepts/ORM/Association...](http://sailsjs.org/#!/documentation/concepts/ORM/Associations)
(check the types of associations listed in the sidebar on the left)

------
habitue
Can anyone explain the forwards compatibility plan for es6? I get we can
transpile, but that's not a gradual strategy for converting code. Since you
can't polyfill syntax, are we just supposed to all transpile until some far
flung day when browsers without es6 support finally reach some tiny
percentage?

Is the assumption now that browsers largely auto-update that it won't be so
long before that happens? Why are breaking syntax changes not a big deal,
whereas "use strict" was done as a string so older browsers would ignore it?

Edit: backwards compatibility -> forwards

~~~
VieElm
The only backwards compatibility breaking change I know of is that function
declarations are scoped block level in EcmaScript 6 (which I think has been
renamed to EcmaScript 2015), not function scope which is what they have been
since the beginning, but they're only block level if you use "use strict"; for
the foreseeable future and if this change breaks things for you you were
writing really terrible JavaScript to begin with.

~~~
habitue
Sorry, I meant forwards compatibility

------
andrewstuart2
I really like destructuring, but I worry about arrays becoming popular for
multiple returns. If I'm using some other module, I _really_ don't want to
have to remember the order in which the parameters come, or be forced to check
documentation or implementation to know for sure.

With an object, I can use a console log or a debug break point and immediately
see the key value pairs (hopefully well-named) without having to check the
function implementation or docs to see in which order the authors decided to
return (or yield, etc.) values.

Can we just agree now not to use array destructuring as an excuse for
returning multiple disparate values in an array? Or at least in only some
idiomatic form? [error, value] would actually make sense to me, as it follows
popular Node conventions.

~~~
pornel
It's not a problem if you use objects, and the syntax is essentially the same:

    
    
        const {error, value} = (function(){ 
            return {value, error};
        })();

~~~
jrochkind1
What, seriously, the names of your variables matter? And this is seen as a
good thing?

~~~
andrewstuart2
Absolutely they do. That's the major benefit of object orientation: named
properties and methods.

Otherwise, we fall into exactly the "boolean trap" that the author links away
to. [1]

[1] [http://ariya.ofilabs.com/2011/08/hall-of-api-shame-
boolean-t...](http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-
trap.html)

~~~
jrochkind1
properties and methods, yes. But I am not familiar with any other object-
oriented language (is JS one now?) where the names of local variables matter.
I mean, is 'local' even the right word, when the names chosen as references
have semantic impact outside the local scope?

~~~
bzbarsky
I'm not sure why you think local variable names are mattering here...

What's happening is that this expresion:

    
    
        const { error, value } = obj;
    

where obj is an object will assign obj.error to error and obj.value to value.

You could name your locals something else if you wanted, of course:

    
    
        const { error: myError, value: myValue } = obj;
    

will assign obj.error to myError and obj.value to myValue. There just happens
to be a shorter syntax for the common

    
    
       const { error: error, value: value } = obj;
    

case.

~~~
jrochkind1
Ah, it's a slice, I get it now, thanks.

------
jakub_g
For those of you who want some longer read on ES6 there's a work-in-progress
(but already quite informative) book from Nicholas C. Zakas, available for
free on github:

[https://github.com/nzakas/understandinges6](https://github.com/nzakas/understandinges6)

------
jschrf
I think that it's outlandish and silly that ES6 doesn't have a safer, more
sound philosophy about type systems, e.g. like the elegant and rational one in
TypeScript today.

The web needs increased consistency and cohesion in the HTML/CSS/JS
triumvirate.

ES6 seems like a grab-bag of neat and fun new features that end up doing a
whole lot of nothing for large projects that have to care about more tangible
concerns than nicer ways to create anonymous objects.

Some of the new features of ES6 - Symbols, proxies, Object.observe, et cetera
- seem to make it downright easier to write even more confusing code. Instead
of increased rigor and tools for building better software, we get stuff like
this:

    
    
      let obj = {
          ["h"+"ello"]() {
              return "hi";
          }
      };
      
      obj.hello();
    
    

While I think it makes sense to stick with TypeScript for the foreseeable
future, I do look forward to The Next JavaScript.

However, I can't help but wonder if that's due to a mild case of Stockholm
Syndrome setting in.

~~~
vertex-four
> Some of the new features of ES6 - Symbols, proxies, Object.observe, et
> cetera - seem to make it downright easier to write even more confusing code.

Actually, they're things that actual users of javascript have been asking for
(and implementing hacked-up solutions for) for a long time. There's a reason
Coffeescript is often referred to as "a better javascript" and Typescript is
considered its own thing.

Javascript is a dynamic language, and will never make the transition to a
static one. Its users don't want a static language - the people who want a
static language are using things like TypeScript.

~~~
colin_jack
I somewhat agree and consider moving to TypeScript a bit risky as it seems
like it'll end up a niche but I do think sensibly added typing code improve
JavaScript. I want better tooling support, refactoring support,
intellisense...and languages like Dart/TS seem to me to have shown its
possible to do this without throwing out the dynamic aspects.

------
error54
I've been writing most of my Javascript in ES6 recently and I agree that it's
simply fantastic and still has a lot of potential to be explored when it comes
to creating modern apps and frameworks. My main problem is that we're going to
be stuck using transpilers for quite a while as by the time all of the
browsers finally[1] catch up to ES6, ES7 will be released. Unfortunately,
there's not much we can do about slow vendors.

1 - [http://kangax.github.io/compat-
table/es6/](http://kangax.github.io/compat-table/es6/) (Note: Opera, Safari,
and iOS8)

~~~
thomasfoster96
I wouldn't be quite so pessimistic. ES6 isn't finished yet- and I'd say it
would be expected for some vendors to take another 6-12 months to add all new
features after a finished spec is published.

This is pretty much what happened with ES5, right?

~~~
aikah
> and I'd say it would be expected for some vendors to take another 6-12
> months to add all new features after a finished spec is published.

And what happens with browsers on older mobile phones that cant be upgraded ?
you let your scripts stop working ?

If you think you can switch to ES6 in 6 month without any kind of
transpilation, while keeping a good browser compatibility good luck ...

> This is pretty much what happened with ES5, right?

No,5 years after the launch of ES5 some browsers like Safari still didn't
support some ES5 features. And some browsers on handsets will never support
ES6.

~~~
thomasfoster96
6-12 months was a bit optimistic (I thought ES5 was released in 2011, in fact
ES5 was released in 2009 and ES5.1 in 2001) for vendor adoption I'll admit.
Still, I can't imagine waiting more than 2-2.5 years for perhaps 80-90% of
browsers supporting virtually all of ES6.

> And what happens with browsers on older mobile phones that cant be upgraded
> ? you let your scripts stop working ?

If I was absolutely worried about browser support on older mobile phones, I'd
be still writing vanilla JavaScript with no features that aren't in Ecmascript
3. You'll have to drop support eventually. Plus, it's very likely a good chunk
of the ES6 I'll be writing will only ever be intended for running in browsers
that support other cutting-edge features like WebGL, Web Workers and WebRTC,
or on a fairly up to date environment like iojs or node.js.

> No,5 years after the launch of ES5 some browsers like Safari still didn't
> support some ES5 features.

I'm not sure which features Safari is missing that you're referring to. Safari
on both iOS and OS X are missing a lot of Javascript APIs, but both have fully
supported ES5 since at least 2011 [0], and my old Macbook with Safari 5.1 has
no problems running modern websites.

> If you think you can switch to ES6 in 6 month without any kind of
> transpilation, while keeping a good browser compatibility good luck ...

A lot of ES6 features are already being polyfilled (Typed Arrays have been
polyfilled for years), plus you can use try/catch to support new syntax whilst
also supplying some sort of fallback.

[0] [http://kangax.github.io/compat-
table/es5/](http://kangax.github.io/compat-table/es5/)

------
choward
That view counter is too distracting.

~~~
aikah
noscript and it's gone.The most annoying thing however is the monospace and
serif font which makes the page painful to read.

~~~
lobster_johnson
I find monospace fonts easy to read. I write code all day using a monospace
font.

------
olifante
If you want a more extended summary of ES6 features, Axel Rauschmayer's “Using
ECMAScript 6 today” is pretty good: [https://speakerdeck.com/rauschma/using-
ecmascript-6-today](https://speakerdeck.com/rauschma/using-ecmascript-6-today)

------
CmonDev
_"...we must embrace the moving target..."_

...or use a better language.

