Gopherjs: Stance on ECMAScript 6?

[dmitshur]

(I'm not an expert on this topic, so please correct me if I'm wrong.)

The README does not mention anything about ECMAScript 6 and as far as I know, either no, or very few of its features are being used in the generated code.

As far as I can tell, ECMAScript 6 has been officially released for over 3 months now, and latest stable versions of most browsers are supporting it by now (to various degree). See https://kangax.github.io/compat-table/es6/.

What is GopherJS's official stance on ECMAScript 6 features? If I make a PR, can I use some ECMAScript 6 features?

In my opinion, GopherJS is a relatively bleeding edge technology and assuming modern browser is expected; legacy support for extremely outdated browsers is a lesser concern.

Proposal

I think the best attitude to have here is the following. If some ECMAScript 6 feature that is commonly available on today's current stable channels of various browsers makes it possible to do something more efficiently and easily, it should be considered and possibly used.

I don't think it's in the interest of GopherJS project to hold itself significantly back by attempting to support legacy browsers older than current stable channels, is it? (But if the improvements are very minor, then it may not be worth using new features.)

Current status

Is there a policy on this? How does my proposal above sound? Are there things that ECMAScript 6 could enable significant improvement in?

Right now, I'm learning about the internalization/externalization of strings (in order to fix bug #319), and looking at ECMAScript 6: Unicode code point escapes. I don't yet know for sure, but there's a chance being able to use them can lead to better generated output.

[neelance]

Usually when you use ES6 features you have a compiler like Babel + polyfills to make it compatible with older browsers. Obviously that's not an option for GopherJS. I don't want to sacrifice compatibility just for some nicer syntax in generated files. If you find some major performance gain, then we can talk about it. Otherwise I'd like to stick with widely supported features.

[dmitshur]

Thanks for the answer. I agree.

I'll close since the question is answered. Hopefully others can search and find this if they have the same question.

[dmitshur]

Hopefully others can search and find this if they have the same question.

331 proposes having a Developers' Guidelines document, and this information can be moved there for easy access.

[shelby3]

If you find some major performance gain, then we can talk about it.

Here.

Allow JavaScript engines and transpilers to optimize yield instead of hard-coding it one way which works with older browsers. Newer engines might have some tricks up their sleeve.