Why? This was previously discussed in #320, with the conclusion at the time:

If you find some major performance gain, then we can talk about it. Otherwise I'd like to stick with widely supported features.

Is there performance, or any other benefit, to be gained by switching to ES6?

Here is my analysis:

Gopher.js can be used theoretically for roughly 4 types of projects:

1. Desktop applications using Election/lorca/webview, where you program the "GUI" in html/javascript.

• Chromium (Electron) supports ES6 and has for many years now.
• lorca and webview uses the installed browser (whether it's chrome/chromium/safari/explorer). Not sure what end-users browser compatibility is but I suspect the majority support ES6. If the developer of the desktop application definitely wants to be conservative, then they can use babel or babel+uglify to convert code to ES5.

2. Actual websites over the internet using a browser

• All modern browsers now support ES6 directly. See here. This has been the case for sometime.
• I can't find hard figures, but I suspect the majority of users in key markets use browsers that support ES6.
• I can verify that this is the case in the mobile space. I am primarily a iOS developer and this is the standard chart everyone looks at and this. It is a similar scenario for Android. The vast majority of mobile users have ES6 compatibility. (NB: No-one uses official Apple figures because they are biased towards later versions to make it look like everyone is using a higher version than they are)
• ES6 code is faster and smaller. Right now, gopher.js filesizes are already a "show-stopper" for many people attempting to to use it for production websites. Converting to ES6 is a "easy win" (albeit minor)

3. Javascript libraries for sharing over npm

• I am unfamiliar with this type of project due to having never made a library using gopher.js
• Basic research suggests that latent complexities exist making it infeasible in practice due to *js.Object when calling functions or returning objects and interfacing with non-gopher code.

4. Node.js projects (excluding "main process" of electron projects)

• Node.js is a competitor of Go for creating webservers. In practice, I don't think you would program in Go --> convert to JS --> Use with Node.

Nice analysis. I think the key comes down to one point, though:

ES6 code is faster and smaller.

What is your source for this claim? Yes, ES6 offers some syntax optimizations that make human-written code shorter, but I don't expect most of this will affect the type of generated code produces by GopherJS (although I may be wrong, and would be happy to be proven wrong).

As for the speed of ES6, I don't think it's true that, on average, ES6 is faster. This resource shows that some specific operations are faster, others are slower. Most have no change at all.

Is there any reason to think that it would actually benefit GopherJS for performance?

Why? This was previously discussed in #320, with the conclusion at the time:

Please note: #320 is 3 years old. The browser adoption landscape has now changed substantially.

I haven't got benchmarks but I can only assume the syntax optimisations for human-writability must translate to at least equal to an approach where a human wrote an equivalent code in ES5 and at best faster due to the JS engine able to make optimisations in a lower-level language such as assembly.

It's just a guess. I also assume that if a gap does exist (on aggregate), this gap will intuitively only get wider in favour of ES6.

ES6 code is faster and smaller.

They are definitely slightly smaller. In my own projects, I have seen that in every case. Here is one of my examples: https://github.com/thehonestscoop/gutter See the ES5 and ES6 non-minified distribution files.

@flimzy The benchmarks link you provided above says: Run on 1/4/2017 using babel 6.21.0, babel-runtime 6.20.0, and traceur 0.0.111.

ES6 has generators. It can be used to implement goroutines in a much less verbose way.

This link shows the difference (in verbosity) between ES6 and ES5 implementing generators.

@jaracil : This possibility was discussed in #107, and the conclusion at the time was that it wouldn't be feasible.

GopherJS has more pressing issues for now (like #989 and friends), but a here are a few thoughts for future:

• ES6 does offer some nice features we could use. I suspect that async/await could simplify goroutine implementation, and classes could also simplify type system implementation. Both claims, however, need to be proven with a prototype.
• GopherJS math package implementation already depends of types arrays, which is a part of ES6 spec.
• If we wanted to, we could still support ES5 seamlessly by vendoring babel and using https://github.com/robertkrimen/otto or https://github.com/dop251/goja to run it. This way nodejs will not become a mandatory build-time dependency.

For another point in favour of ES6, see this comment in the related issue:

#524 (comment)

We cannot make code splitting work, and webpack also spits out warnings such as

Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

Our dev team has been wrestling with this for days already (with no result yet). If the output would be ES6, it would work much easier with webpack.

@benma if you could file this as a separate issue with a minimal reproduction example for this warning along with the expected/observed behavior, it would be a lot easier for us to investigate possible solutions that require less than grand architectural redesigns :)

FWIW, according to our survey results, only ~9% of users are targeting ES5 specifically, so perhaps embracing ES2015 features is becoming a sensible step.

@nevkontakte It turned out that this warning did not impact code splitting - that now works but the warning still remains.

The warning goes away is I replace $global.require with require in the generated output. I will try to post an example soon. Skimming the generated code, it seems using require directly should work.

I think it's a good time to have another go at this discussion. To that end, I created a new proposal, which declares that ES 2015 features can be used in GopherJS-generated code and formalizes the principles for using newer APIs in future: #1121. If anyone has opinions in favor or against, I would appreciate you taking time to share them in the new issue.