Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/gopherjs/gopherjs/issues/1121 below:

ECMAScript version policy for GopherJS · Issue #1121 · gopherjs/gopherjs · GitHub

For a long time GopherJS had a policy of maintaining generated code compatibility with the ECMAScript 5 standard. ES 5 was a good choice due to its broad browser support and ability to use GopherJS-generated scripts almost anywhere without additional post-processing.

However, in the time passed the web landscape has changed enough for us to reconsider this policy. In particular, 94.35% of clients fully support ES 2015 with 2.28% offering partial support according to caniuse. GopherJS already uses ES 2015 typed arrays (supported by 97.98% of clients), so ES 2015 adoption would impact 3.64% of web users (pessimistically assuming that partial support is insufficient). In practice we expect the impact to be further mitigated by the following factors:

• Tools like babel can be used to transpile ES 2015+ down to ES 5 syntax.
• There are third-party polyfill libraries like core.js that can be used to emulate ES 2015+ APIs on the older systems.
• According to caniuse, most non-compliant clients are either Internet Explorer 10/11 or old mobile Android browsers released before 2015. In all likelihood they represent low-end systems using GopherJS on which was already problematic due to performance and large output size.
• According to the GopherJS user survey, only 2.9% of responders support 5-8 years old browsers, and nobody supports browsers older than 8 years.

As the JavaScript ecosystem evolves, benefits of adopting newer ECMAScript standards become more and more significant for GopherJS. Here is an incomplete list of improvements that become possible with ECMAScript 2015:

• Generate more idiomatic code for user-defined types using ES 2015 classes: Turn struct and methods in es6 class / extends #813
• Compile Go packages into ES 2015 modules: Proposal: add option to build browserify / es6 modules #524
• Implement goroutines using async/await or generators, reducing generated code size.
• More efficient map implementation using the built-in Map type.

We declare ECMAScript 2015 a baseline targeted version. Any syntax or an API that is a part of the baseline targeted version can be used in the GopherJS generated code, unless explicitly stated in this policy. It is up to the users to transpile or polyfill it for older runtimes.

The baseline targeted version can be updated to newer ECMAScript standards if the following guidelines are met:

• Chrome (on Android and desktop), Firefox, Safari (on Mac and iOS) and Edge have had complete support of the standard for at least two years. Compatibility with other browsers will be taken into account, but won't be necessarily blocking.
• The oldest supported Node.js LTS version has complete support for the standard.
• At least 95% of web users have complete or partial support of the standard as reported by caniuse.com.
• Upgrading to the newer standard offers tangible benefits to GopherJS and its users in performance, features, or maintenance cost.

We recognize that in many ways the value judgement in this question is subjective, but the final decision is made by consensus among the currently active GopherJS maintainers. If the decision to upgrade the baseline targeted verision is made, it should only take effect when the next minor version is released (i.e. 1.x).

For the ECMAScript features from standard versions newer than the baseline, the following rules apply:

• Using new syntax features is not allowed.
• Using new APIs may be allowed if the following conditions are met:
  • It doesn't harm the GopherJS performance or stability in the runtimes missing the feature. Significant bundle size increases are considered a negative effect in this context.
  • GopherJS runtime handles missing APIs gracefully and transparently. GopherJS users don't have to manually polyfill or change build configuration.
  • There is a consensus among the active GopherJS maintainers that this change would be beneficial to GopherJS and its users overall.

Common sense applies: The rules above are meant to provide general guidelines, but we acknowledge that making exceptions may be necessary from time to time. Our ultimate goal is to make GopherJS as useful to our users as possible and avoid inflicting unnecessary toil on them or the maintainers.

• Stance on ECMAScript 6? #320
• ES6 time #891

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4