sjrd
February 10, 2025, 9:16am
1
RFC: We intend to deprecate support for ECMAScript 5.1 in the next version of #Scala .js. If you are still relying on it, please weigh in on the PR and tell us why. The default has been ECMAScript 2015 since Scala.js v1.0.0.
scala-js:main ← sjrd:deprecate-es5.1-support
opened 09:45AM - 08 Feb 25 UTC
That support is the biggest source of alternative code paths and polyfills in ou… r 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.
---
I did a simulation of all the things we could drop if we indeed removed support for ES 5.1 in the future. It is visible in #5129.
3 Likes