es6 => beyond_es5

[stevemao]

Also tweak some of the wording to best fit the name change.

Edit:
After discussion, Here is the task list:

• The tab name needs to be generic (beyond_es5?).
• We need a redirect from docs/es6 to docs/beyond_es5.
• On that single page, we need something like es6 => beyond_es5 #434 (comment)

[lpinca]

👍

[fhemberger]

Important: If this gets merged, we need a redirect from docs/es6 to docs/es2015.

[phillipj]

To prevent having to synchronise landing this PR, with a PR in the build repo for the redirect just mentioned, it would be best to copy locale/en/docs/es6.md → locale/en/docs/es2015.md instead of moving. That would leave time for the redirect to be put in place sometime later, before actually deleting locale/en/docs/es6.md in this repo.

A small follow-up about the redirect, it should be as easy as adding a line in the nginx conf: https://github.com/nodejs/build/blob/master/setup/www/resources/config/nodejs.org

[Knighton910]

👍

[rvagg]

Wait, is it clear what is strictly 2015 and what falls in to 2016 and 2017? are we also planning on adding es2016.html and es2017.html etc.? I like that "ES6" is still a generic enough catch-all for "stuff beyond ES5" but can accept that we're getting towards a point where that's not going to work any more. Can we opt for something more generic than "ES2016" though? Maybe "beyond_es5.html"? Is "esnext.html" acceptable or has that been tainted already?

[rvagg]

According to kangax, Array.prototype.includes() is part of "ES7" which I'm guessing means ES2017 (maybe) now and we mention it in the current es6.html, does that mean we immediately need an es2017.html? I'm not a fan and would rather see all moved to some kind of "ES compatibility" page where we list what works with what version of Node.

[stevemao]

I vote for esnext. ES6 is the old name of ES2015 and Array.prototype.includes() does not belong to it.

[ljharb]

Incorrect. ES2015 is the name of the 6th edition of the ECMAScript spec.

ES6 and ES2015 are both correct identifiers for that version of the spec, and ES7 and ES2016 will both be correct identifiers for the upcoming version (which contains Array#includes).

Post-ES6, it would probably be a good idea to have a single page that lists ES proposals and their stages, along with their levels of support, rather than coupling to future arbitrary year or edition number designations.

[fhemberger]

How about rephrasing the page as some kind of compatibility table? Where you can see support behind flags and unflagged support?

ES6	Version
Feature X	0.12 (--harmony), 4.0
Feature Y	4.2 (--es_staging), 5.0
Feature Z	5.0

ES7	Version
Feature A	4.2
Feature B	6.0

Working for clients with different node versions in production, it would be handy to see if a particular feature you want to use is available in that version or if it requires a flag.

[stevemao]

Thanks @ljharb, in such case I think it's better to keep "docs/es6" if we decide to add "docs/es7" (and put Array.prototype.includes() there).

[fhemberger]

@stevemao … and create a separate page for each year's new ES specs? Also, half of the page isn't strictly tied to ES6 at all but how to access those new features in general. So I think it should stay on one page.

[stevemao]

Cool. To sum up,

1. The tab name needs to be generic (beyond_es5?).
2. We need a redirect from docs/es6 to docs/beyond_es5.
3. On that single page, we need something like es6 => beyond_es5 #434 (comment)

[stevemao]

Sorry guys if anyone wants to take over this by all means.

[stevemao]

Closing because of #671