search

fullcalendar / temporal-polyfill

A lightweight polyfill for Temporal, successor to the JavaScript Date object
MIT License
361 stars 14 forks source link

Recommend avoiding fallback to native Temporal implementation #19

Closed littledan closed 1 year ago

littledan commented 1 year ago

Temporal is still undergoing some changes. If an automatic fallback is shipped in websites, those sites could break when the proposal changes. Ultimately, unfortunately, the deployment of the polyfill could block the proposal from evolving! This has repeatedly prevented TC39 from making changes to the language, e.g., in the famous #smooshgate incident.

For this reason, it's generally recommended (W3C TAG polyfill guidelines) that polyfills only defer to native implementations once they reach a "tipping point":

For features that are yet to reach the tipping point, speculative polyfills should not detect or defer to native implementations, and should not use the same name as a native implementation.

When no native implementation exists yet, we haven't yet reached this tipping point. I stongly recommend exposing the option of fallback to native Temporal only once Temporal has shipped in at least one web browser. Until then, it would be best to stick with only the impl entrypoint.

littledan commented 1 year ago

BTW it's fine, from my perspective, to use the polyfill in a global mode, as long as it overrides the global unconditionally. It's the conditionality, not module vs global, which is most impactful in terms of avoiding creating web compatibility issues.

mrienstra commented 1 year ago

Related: https://github.com/tc39/proposal-temporal/issues/778

Via https://github.com/js-temporal/temporal-polyfill#usage, which links to https://github.com/tc39/proposal-temporal/issues/778 here:

Note that this polyfill currently does not install a global Temporal object like a real implementation will. This behavior avoids hiding the global Temporal object in environments where a real Temporal implementation is present. See this issue for more background on this decision.

arshaw commented 1 year ago

I totally understand. I will implement this for the next release, which will be sometime this week. I'll remove the conditionality of the main entrypoint, effectively making it the same as the impl entrypoint

arshaw commented 1 year ago

Released in v0.1.0

arshaw commented 1 year ago

I only made the change for the 'polyfill' endpoint which is temporal-polyfill/global . I still need to make the change for the temporal-polyfill endpoint

arshaw commented 1 year ago

Fixed in the ponyfill here: https://github.com/fullcalendar/temporal/commit/3a9cc0ccb2281712cd57dc7085e7550e46c8929b

Released in v0.1.1. This issue can finally be closed out.