Proposal-temporal: Drop support for environments that don't support Symbols
According to https://caniuse.com/#feat=mdn-javascript_builtins_symbol, ~93% of the web have access to symbols. I wonder if the polyfill should just drop the shim that supports the remainder to perhaps move to using a 3rd party shim. It's currently uncovered by tests and sticks out like a sore thumb.
ryzokuken
All 3 comments
That's fine for this polyfill, but IE 11 is still heavily used on many sites, and supporting non-Symbol environments is still critical for most businesses.
(The real story is told by a company's own analytics, not by attempts at computing aggregate values for the entire internet)
ljharb
on 19 Mar 2020
Using a 3rd party shim seems fine to me (we already do the same for BigInt), though we would still not be testing non-Symbol environments.
ptomato
on 19 Mar 2020
Here's what we discussed in the March 26 meeting: It comes down to what the purpose is of the polyfill. It's for experimentation, not production. So not shimming Symbols in this polyfill should be fine. The idea would be to add back a more robust 3rd party shim later when it's appropriate for the polyfill to be used in production environments (or even better, work with well-known projects such as core-js or es-shims to provide a production-quality polyfill rather than us maintaining it in perpetuity.)
We also discussed removing the big-integer library and using native BigInt in the polyfill (although not using BigInt literals so that it could be polyfilled if someone so chose) but on reflection I don't think that's feasible since we do have to use BigInt arithmetic extensively, which also can't be polyfilled. We could switch from big-integer to JSBI, which is supposed to have better compliance with BigInt, but I think the benefit would be marginal.
ptomato
on 27 Mar 2020
Related issues
thefliik
路
3Comments
Ms2ger
路
6Comments
thefliik
路
6Comments
sffc
路
3Comments
littledan
路
4Comments
Most helpful comment
Here's what we discussed in the March 26 meeting: It comes down to what the purpose is of the polyfill. It's for experimentation, not production. So not shimming Symbols in this polyfill should be fine. The idea would be to add back a more robust 3rd party shim later when it's appropriate for the polyfill to be used in production environments (or even better, work with well-known projects such as core-js or es-shims to provide a production-quality polyfill rather than us maintaining it in perpetuity.)
We also discussed removing the big-integer library and using native BigInt in the polyfill (although not using BigInt literals so that it could be polyfilled if someone so chose) but on reflection I don't think that's feasible since we do have to use BigInt arithmetic extensively, which also can't be polyfilled. We could switch from big-integer to JSBI, which is supposed to have better compliance with BigInt, but I think the benefit would be marginal.