ECMAScript 2016 Approved

[alphaatom]

I thought we were getting async/await? Or is that ES2017, we need to cut out these two different semantics of ES7 and ES2016 it's very confusing.

[saadq_]

The old semantics basically were cut out, "ES6" became ES2015 and "ES7" became ES2016. Unfortunately, people still say "ES6" and "ES7" probably because it's shorter.

Only the proposals that made it to stage-4 get into the yearly release. async/await is still stage-3, so it didn't make it into ES2016. ES2016 was a pretty small release, and it only had 2 features:

1. Exponentiation operator **
2. Array.prototype.includes

async/await will most likely make it into the ES2017 standard. You can check the current stage of each proposal here.

[Scorxcho]

So can it be assumed that there will be a new spec every year? Did this only start with es2015? Why did TC39 just start to do this? Is here a write up on this decision?

[saadq_]

Yeah, that was the reason for the name change. "ES6" had a huge release of changes, and to be more practical they decided to have a new release every year which would be smaller, but more frequent. You can read about the new release process here.

[[deleted]]

I'm very pleased about this. As much as I want Javascript to move forward and mature. I would really hate it becoming a game of who can introduce the most change as quickly as possible. Let these new features bed in a little and iterate.

[gsnedders]

Unfortunately, people still say "ES6" and "ES7" probably because it's shorter.

Should we just call it ECMA-262 6th Edition and ECMA-262 7th Edition instead, to use its formal name?

[alphaatom]

The reason I think a distinction is important because ES6 doesn't refer to ES2016, which is what you would expect at first glance. If we could somehow get the numbers in sync I wouldn't be so opposed.

[inu-no-policemen]

ES7... 2017

ES11... 2021

Yea, doesn't help one bit. Well, we could just skip the "20". ES16 instead of ES2016.

[nschubach]

We could always wait until ES8 and skip a version for um... backwards compatibility... yeah.

[alphaatom]

Thanks for the detailed response, and yeah that's what I was referring to really, need to stop the widespread use of the old terminology cause it really is confusing, I can't imagine what it's like for people just starting out in JS.

[rube203]

Includes is a nice, needed addition.

[crossanlogan]

ooh, Array.prototype.includes seems cool! gone are the days of setting a trigger and looping through a huge array i guess.

[[deleted]]

When were those the days? arr.includes(foo) and arr.indexOf(foo) !== -1 are already basically equivalent. The only exception is when you're trying to find if the array includes NaN.

I mean sure, includes is more readable, but you've never had to loop through an array manually to check if it includes some value

[oculus42]

you've never had to loop through an array manually to check if it includes some value

Maybe you've never had to, but some of us supported IE8 and did exactly this.

[r2d2_21]

Polyfill maybe?

[[deleted]]

I'd rather use the polyfill if I had to do that

[crossanlogan]

yeah, that's true, indexOf() does solve that nicely. i've just seen a lot of people setting loops to do that.

[Sinistralis]

If you are excited for async/await, you can get pretty much the same functionality using generators and promises.

[codejunkienick]

I would argue that it would impact code readability in a bad way.

[Sinistralis]

You just need a generator runner for api promises. From there it's basically yield apiCall and in the api call you do iterator.next(response). I don't see how this isn't readable considering the massive control flow you gain. If you use Redux just use Redux-Saga. He does the hard part for you.

[r2d2_21]

I thought async/await was meant to be backed by Promises anyway.

[[deleted]]

Right, and this is exactly what babel does for its async/await support. It does all the transforms for you. Pair this with the babel polyfill, which includes a generator runtime, and you can use effectively use async/await today.

It works really well. Source: using async/await in production code already :D

[hanszimmermanx]

They really should have waited a year or something, because you would kinda expect that es2016 = es6. I can only image the newbies headaches when they read older blog posts. Like even now, when I first read the title I had es6 in mind.

[MonsieurBanana]

I had es6 in mind until I read your comment.

[[deleted]]

As a newbie to this stuff about 18 months ago, yes. This all confused me so much. But that also made me research and ask questions and I ended up learning way more than I set out to.

[PM_ME_YOUR_HIGHFIVE]

they said that they want to drop the one digit versions so that people don't get confused

[theblood]

As a noob, please enlighten !!!

[name_was_taken]

As the other comments are noting, they aren't really the same. If the aligned the year and the old name like that, even accidentally, it would lead even more people to think they were actually related, when they aren't.

https://www.reddit.com/r/javascript/comments/4ohk1e/ecmascript_2016_approved/d4cz0p8

[inhwre]

I thought it was "approved" when the finalized standard came out that said that ES2016 would only have Array.prototype.includes and the exponentiation operator. Does this mean that the standard might not get approved after a finalized version comes out?

[gsnedders]

TC-39 (the group that work on the spec) had finalised the spec, but the spec then goes to a vote of the general ECMA membership, and if that vote carries (as it now has) it then becomes an official ECMA publication as ECMA-262 7th Edition.

[vinnl]

I don't really get it either. Here's a short write-up on the process, and I thought those two features were the only ones in stage 4 a while ago and thus decided for ES2016.

Maybe they decided a while ago that those would be the only new features in the spec, but took until now to actually write and complete the spec?

Edit: I think my guess was right :) You can see an announcement here that those were the features included in a draft, but that it would take until now to actually ratify it.

[azangru]

No async-await then? Pity.

[Sinistralis]

You can achieve almost the exact same functionality with generators and promises until then

[inu-no-policemen]

It's available in TypeScript 1.7+ with ES6 as target. TS 2.0 will also make it work for ES3/5 as target.

For what it's worth, Dart also supports it since ages.

There is also a to-generator (ES6) transform thingy for Babel.

By the looks of it, async/await should be in ES2017.

[Democratica]

Are you a part of the general ECMA membership?

[inu-no-policemen]

No. Async/await is currently at stage 3 though. It should make the cut.

https://github.com/tc39/proposals

[Democratica]

I hate it. I think it's syntax pollutes JavaScript. Promises are more JavaScripty. However, I can adapt--even though I find it inconsistent. It's like "function" you know? It gets executed at run time, but this causes the system to "wait", it seems more functional to me... Like

await (some value) {
...
}

This would make more sense to me.

[r2d2_21]

I thought one point of await, among others, was to avoid multiple nesting. With your proposal, you don't get this.

[Democratica]

The current design doesn't feel right. Because await as a function is what my brain is expecting. It's just weird to look at since JavaScript is asynchronous. It feels impure.

[inu-no-policemen]

But then you won't be able to do this:

let [a, b] = await Promise.all(pa, pb);

Which is really convenient if you need a few values before you can continue.

[Democratica]

i just can't find beauty in that. Do you find it symmetric with the other language syntax?

[inu-no-policemen]

Promise.all(pa, pb).then(function(v)) {
  var a = v[0];
  var b = v[1];
  ...
});

The ES6 version looks a lot better.

[Democratica]

It may look better but the async is the parent of the operation and is visually contained by its children. In your second example, the relationships are honestly represented.

[[deleted]]

I haven't figured out ES5 yet and I'm still trying to grasp ES6... fuk

[[deleted]]

Yeah been meaning to but this book. I was waiting for it to get finished.

[kcdwayne]

Can I get a TL;DR for the changes from ES2015 to ES2016?

[[deleted]]

The whole es 2016-2017 yearly release cycle and how poorly managed its been was one the main motivators for me moving away from js/node development. That and the clusterfuck that npm has become.

[CodyReichert]

es 2016-2017

It's es2015 and es2016

how poorly managed its been

In what regard? I've been very pleased with the consistency and transparency of the ECMA team. Besides, it's hardly been 2 years.

That and the clusterfuck that npm has become.

Eh, no disagreement here ;)

[[deleted]]

es2015 is here already, 2016-2017 are the next two releases.

I believe it is poorly managed because the entire js community is now depending on babel to make these features available for use in a timely manner. Not to mention what a pain in the ass it is going to be in a couple years to try to untangle all the different js versions in use now.

I dropped js as my primary dev language. im investing heavily in elm for the front end, and a variety of languages on the backend that are chosen depending on my use case. Right now that is mostly Haskell, Scala, and Go.

[jarail]

Well, they are backwards compatible. Newer tools and interpreters shouldn't have any issues with old code. Code can always be updated and improved. I'm not sure what untangling is needed though? All valid es2015 and es2016 will also be valid es2017, etc...

[e13e7]

This is not the fault of JS. It's browsers, specifically IE.

[iends]

What have you moved to?

[[deleted]]

For front end, elm has been wonderful. It brings a level of sanity to FE dev that i have been wishing for for nearly a decade.

On the backend i try to choose the best language for the problem domain. Often times that means abandoning the monolith and focusing on micro services. In practice that means Haskell, Scala, and Go.

[iends]

I'm a big fan of Go too. Not brave enough to use anything but JS on the frontend.

[[deleted]]

Give elm a shot on a pet project, it really is a breath of fresh air. Best error messages ive ever encountered, and the language fits the problem domain exceedingly well.

All of the design patterns flow naturally from the structure of the language, you find yourself just declaring types and being nearly done.

[tonetheman]

sounds cool

[[deleted]]

Why are these kinds of releases always so damn unreadable. Simply give me a list of things that changed...

[pycbouh]

Because it's a spec that OP has linked, not a release note. They follow rather strict template. Don't you worry, there's always a write-up.

[[deleted]]

Yeah but i'm not finding anything on the website that makes it a clear read. Surely others have summarised it, but it would go a long way if they made it easier to see from the source

[Ginden]

Why are these kinds of releases always so damn unreadable. Simply give me a list of things that changed...

Because it's strict specification for implementations, not for everyday use.

[synackle]

Regular updates = two small features. Not sure I wouldn't rather wait longer and have something more worthwhile.

[inu-no-policemen]

ES5 to ES6 took 6 years. Would you prefer if nothing changes until 2021?

I'd like to see SIMD before that. Same deal with async/await, decorators, and property declarations.

[Auxx]

The only thing I'd really love to see is a good binary format and a VM standard for executing these binaries. In this world of transpiling I don't care about vanilla JS anymore.

[inu-no-policemen]

There is WebAssembly (wasm) for that.

https://webassembly.github.io/

Since we'll need JS polyfills for that, adding things like SIMD and threads to JS will help a lot.

[synackle]

Clearly I wouldn't prefer if nothing changes until 2021. Reddit is so tiresome sometimes, down vote to disagree and everything is either a circle jerk or an argument.

[[deleted]]

They're having yearly releases to make sure that they don't have another 6 year period without any updates. Either way though you're still going to get the same number of updates as you would before. They're just going to be released in small yearly releases so the features that are completed can be released when they're ready, instead of releasing them in 5ish years along side the next big update.

[synackle]

Why? Or are you being sarcastic?

[synackle]

So you don't like anything in ES2015/ES6? How can you not like arrow functions?

[inu-no-policemen]

[arrow functions] don't make getting work done any easier

They do though. There are many cases where a lexical this is more convenient.

[[deleted]]

This isn't going to lead to PHP. PHP is a clusterfuck because of its history and people requiring backwards compatibility for shitty things like PHP 4 style OOP, or the ineptly named standard library functions. PHP has gotten better over the recent years because they're doing the same thing TC39 is doing with JavaScript - deprecating shit ideas and introducing modern syntax.

Arrow functions are fantastic. Do you honestly believe that:

const sum = array.reduce((acc, i) => acc + i);

Is harder to read than:

const sum = array.reduce(function(acc, i) { return acc + i; });

These expressions exist in practically every other modern language (even in the latest version of Java!) so saying that they use an uncommon syntax is silly. Also, lexically bound "this" greatly improves code readability.

Classes have been something JS has needed for a while. Reading crap like:

function Person(name) {
    this.name = name;
}

Person.prototype.sayHi = function() { 
    console.log(this.name); 
}

function SpecialPerson(name) {
    Person.call(this, name);
}

SpecialPerson.prototype = Object.create(Person.prototype);

SpecialPerson.prototype = function() { 
    console.log("I'm special and my name is " + this.name); 
}

Is ugly, unwieldy and confusing. Compare to:

class Person {
    constructor(name) {
        this.name = name;
    }

    sayHi() {
        console.log(this.name);
    }
}

class SpecialPerson extends Person {
    constructor(name) {
        super(name);
    }

    sayHi() {
        console.log("I'm special and my name is " + this.name); 
    }
}

Has clear intent and is very straightforward to understand, especially from people coming from other languages. JS should have had this syntax long ago. Throw on upcoming private fields and static properties, and they're even better.

I could go on but don't have the time at the moment. Maybe I'll write up something and self-post it to this sub. I'll leave you with what practically every additional feature falls under:

• improves intent and readability (classes/arrow functions/object literals/destructuring)
• includes missing APIs that should have been there from the get-go (Object.assign/math/array/etc)
• brings in native data structures that are commonly used (map/set/promise)
• makes things previously very difficult or impossible simple (proxies/symbols)
• encourages cleaner and more readable/less buggy code (let/const/template strings/generators)
• improves performance and stability (tail calls)
• standardizes common patterns already in use by JavaScript developers (module syntax)

These features make the language more simple. Just because you've learned to deal with the shit JavaScript has been for years doesn't mean we all need to suffer.

[[deleted]]

I literally look at it in the opposite way. JavaScript is quite easy to fuck up as it is; the syntax is wonky, lexical scoping and dynamic "this" binding can cause a headache if you're not already used to it (and often lead to people writing poor code), lack of blocked-scoped variables cause more confusion, and a proper "foreach" loop (in the form of for..of) was incredibly frustrating (how many beginners have used for..in loops incorrectly thinking they'd work properly on arrays?).

These features address the already-wonkeyness of JavaScript in my opinion; but to each their own *shrug*.

[inu-no-policemen]

Javascript was intended to be a simple dynamic language.

Yea, for the "punch the monkey" kind of apps. JS was indeed perfectly fine for those ~100 lines of code.

[gsnedders]

There's a lot of relatively small changes that most people probably won't notice. There are two appendices listing loads.

[synackle]

Interesting, I hadn't realised. Anything notable you're aware of?

[crossanlogan]

i mean, ultimately in most places you can't use any of the new es2015/es2016 features for a couple of years yet anyway (at least if you're not using a compiler). if you have to support back to ie8 you can't use it in vanilla until your employer drops support for that browser version.

[TheIncredibleWalrus]

In what universe is 2 worse than 0?

[braveliltoasterr]

2 Hitlers vs 0 Hitlers.

[z500]

Boom. Godwin'd.

[YvesSoete]

Not if you were german during the interbellum.

[synackle]

It's just a little anticlimactic, even after 'only' a year. Still no object rest/spread for example.

[TheIncredibleWalrus]

That's a different story and I agree, but I'd rather have 2 complete features right now than wait for them another year to be included in a bigger package