Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

ECMAScript version policy

Nevkontakte edited this page Aug 17, 2022 · 1 revision

This document defines guiding principles for GopherJS's generated code conformance to ECMAScript standard revisions.

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.

Prior discussions:

Clone this wiki locally
Morty Proxy This is a proxified and sanitized view of the page, visit original site.