Skip to content

Stance on ECMAScript 6? #320

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
dmitshur opened this issue Oct 8, 2015 · 5 comments
Closed

Stance on ECMAScript 6? #320

dmitshur opened this issue Oct 8, 2015 · 5 comments
Labels
Proposal question

Comments

@dmitshur
Copy link
Member

dmitshur commented Oct 8, 2015

(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.
@dmitshur dmitshur mentioned this issue Oct 8, 2015
Closed
@neelance
Copy link
Member

neelance commented Oct 8, 2015

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
Copy link
Member Author

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.

@flimzy flimzy mentioned this issue Oct 18, 2015
Closed
@dmitshur
Copy link
Member Author

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.

@paralin paralin mentioned this issue Sep 21, 2016
Open
@didrocks didrocks mentioned this issue May 4, 2018
Open
@shelby3
Copy link

shelby3 commented May 20, 2018

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.

@theclapp theclapp mentioned this issue May 23, 2018
Open
@flimzy flimzy mentioned this issue Jan 11, 2019
Closed
@nevkontakte nevkontakte mentioned this issue Jun 7, 2022
Closed
@nevkontakte
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Proposal question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@neelance @shelby3 @nevkontakte @dmitshur