-2
\$\begingroup\$

We are 3/4 the way through 2015, as of last Thursday. 2015 was supposed to be the year of adoption for ES6, so today I prepose the full adoption of ES6 in Programming Puzzles and Code Golf. This means that all JavaScript answers are assumed to be ES6, not needing to be implied by the Submitter. ES7 answers, however must still be specified, as it has limited support.

TL;DR: Assume ES6 in all JavaScript answers.

| |
\$\endgroup\$
  • \$\begingroup\$ Does this just mean writing JavaScript on the headline instead of JavaScript (ES6)? Or are there any other changes to be made? \$\endgroup\$ – jrich Oct 5 '15 at 1:51
  • 10
    \$\begingroup\$ AFAIK many browsers do not yet support ES6. \$\endgroup\$ – Alex A. Oct 5 '15 at 2:03
  • \$\begingroup\$ @UndefinedFunction yes. That would be the only change. \$\endgroup\$ – MayorMonty Oct 5 '15 at 2:10
  • \$\begingroup\$ @AlexA. Take a look at the support table. Most (modern) desktop browsers support at least 50%, with FF 42 with 70% support. Common Code Golf Features such as arrow functions, the spread operator, and template strings are supported a big section of browser percentage. 48% of users have support for arrow functions There is more support than you think. \$\endgroup\$ – MayorMonty Oct 5 '15 at 2:18
  • 9
    \$\begingroup\$ Personally, I don't see a problem with specifying ES6 in an answer. To draw a parallel, Python has moved onto Python 3, but most Python answers still make the distinction between 2 and 3. \$\endgroup\$ – Sp3000 Oct 5 '15 at 2:19
  • \$\begingroup\$ @SP3000 Python 3 is a special case in that it breaks backwards compatibility with Python 2 (Links to expanded comment below, which in turn links to more info on Python 2/3). \$\endgroup\$ – Mwr247 Nov 6 '15 at 17:48
18
\$\begingroup\$

Not all browsers completely support ES6 yet.

As such, answers should continue to state the ECMAScript version they use to avoid confusion, at least until ES6 is widely available. This avoids confusion when someone with browser that doesn't support ES6 tests out a submission that assumes ES6 features without mentioning so.

Besides, it's only 5 extra bytes to add in the submission header.

| |
\$\endgroup\$
  • \$\begingroup\$ Table of ES6 Browser Compatibility. This table is helpful. Also note that ES6 is at most 80% supported. \$\endgroup\$ – mbomb007 Oct 8 '15 at 20:45
  • \$\begingroup\$ There was recently a challenge wherein the solution involved outputting it's own header (#title, score), and cutting out the ES6 saved me a not-insignificant amount. While I'd agree in general it doesn't matter that much, what about in such meta-cases? And at what percentage of ES6 coverage will we consider it "widely available"? \$\endgroup\$ – Mwr247 Oct 22 '15 at 20:27
  • \$\begingroup\$ @Mwr247 DId Python 3 had to output the "3" as well? If yes, then a version is anyways required... \$\endgroup\$ – Optimizer Oct 22 '15 at 22:59
  • \$\begingroup\$ @Optimizer Python 3 is a special case in that it breaks backwards compatibility with Python 2. Hence the need to specify version. Many languages can also get away with this because you can always choose a version to stick to, and they are generally backwards compatible anyways. \$\endgroup\$ – Mwr247 Oct 23 '15 at 1:22
  • \$\begingroup\$ JavaScript has always been very different in this regard because implementations vary more than any other language (some ES5 features are technically missing even in major browsers), and the way in which changes are made almost makes it a rolling standard. With that being the case, I'd argue that the official spec is really the best definition of what can be done in the language. If confusion of browser support is what matters, then we should be noting "FireFox"/"Chrome"/etc rather than "ES6"/"ES7"/etc. \$\endgroup\$ – Mwr247 Oct 23 '15 at 1:24
  • \$\begingroup\$ @mbomb007 I get 97%. \$\endgroup\$ – programmer5000 May 17 '17 at 12:01
  • \$\begingroup\$ @programmer5000 That comment was from 2 years ago... \$\endgroup\$ – mbomb007 May 17 '17 at 13:51
10
\$\begingroup\$

No real benefit

I don't see any real benefit from this. Just think of it like other language where people explicitly mention version (Python/C++/Perl etc). Not everyone has the compiler for the latest version, so mentioning the version helps them get the right compiler (which in this case is a browser)

| |
\$\endgroup\$
4
\$\begingroup\$

"JavaScript" should reflect the current specification

As of June 17th, 2015, version 6 of ECMAScript, which is considered by everyone (as far as I know) to be the "JavaScript" specification, is now the official stable release of the language. Regardless of any specific implementation, this is the closest thing we had to any real definition, and I'd argue, what we should base this decision on. As such, the only times that I can think of that adding a version should matter anywhere is when:

  1. There is an major loss of backwards compatibility between versions (Python 2/3).
  2. Features are not yet solidified and are subject to change or removal (ES7, and formerly ES6).
  3. A feature being used is no longer part of the specification (Object.eval()).

I argue that adding a version should be otherwise optional, and use of the language name "JavaScript" should apply to the current version as of the question post date (to abide by general Code Golf rules in that regard).

JavaScript is a bit of a special case compared to other languages simply because we can't really "choose" a version to use. It's at best really more of a rolling standard with how implementations gradually roll out features (most major browsers still don't support all ES5 features). If "browser support" is really what matters, then we should be labeling as "FireFox 42"/"Chrome 46"/etc instead of "ES6"/"ES7"/etc anyways.

| |
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .