8000 DO NOT MERGE Simulation: What if we dropped support for ES 5.1. by sjrd · Pull Request #5129 · scala-js/scala-js · GitHub
[go: up one dir, main page]

Skip to content

DO NOT MERGE Simulation: What if we dropped support for ES 5.1. #5129

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.

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

Closed
wants to merge 8 commits into from

Conversation

sjrd
Copy link
Member
@sjrd sjrd commented Feb 8, 2025

This is a simulation of all the things we could remove if we dropped support for ES 5.1 (in the future). This is meant as "supporting evidence" for #5128.

sjrd added 4 commits February 8, 2025 11:12
That support is the biggest source of alternative code paths and
polyfills in our codebase.

The polyfills and other alternative implementations we need to
support ES 5.1 include:

* `Math.fround` to support `Float` operations (in `CoreJSLib`).
* Other bit manipulation magic for floating-point numbers
  (in `FloatingPointBits`).
* Using dynamic JS `Array`s instead of typed arrays for Scala
  `Array`s of primitive types.
* Using custom Java `Map`s instead of `js.Map`.
* Various implementations of math methods in `jl.Math` (although
  these may come back for a Wasm-only target, along with more of
  them).
* Using run-time generated random property names instead of
  `Symbol`s.
* Very complex code to handle surrogate pairs in `ju.regex.*`.
* (Imperfect) desugaring of `...rest` parameters and `...spread`
  operators.

Moreover, the ES 5.1 output does not even have exactly the same
semantics as later versions:

* JS classes are not true `class`es. Notably, that means they
  cannot extend native ES classes, and they do not inherit static
  members.
* Top-level exports are declared as `var`s instead of `let`s.

10 years after the instruction of ECMAScript 2015, I believe it
is time to deprecate the support for Es 5.1, so that we can
eventually remove it.
In this commit, we do the minimum changes to remove
`ESVersion.ES5_1`. All the supporting code is still present
elsewhere. We will add separate commits for the various areas
that can be removed.
And remove support for `!useECMAScript2015Semantics` in the linker.
Remove all the `assumeTrue(esVersion >= ES2015)` tests, as it is
now always true by construction.
@sjrd sjrd force-pushed the simulation-drop-es5.1-support branch from e5110e8 to 37f21cd Compare February 8, 2025 10:14
@sjrd sjrd force-pushed the simulation-drop-es5.1-support branch from 37f21cd to aabf827 Compare February 8, 2025 14:31
@sjrd
Copy link
Member Author
sjrd commented Mar 7, 2025

#5128 was merged. This PR did its job. I guess we'll see these commits again in a few years. 😅

@sjrd sjrd closed this Mar 7, 2025
@sjrd sjrd deleted the simulation-drop-es5.1-support branch March 7, 2025 06:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant
0