Skip to content

Latest commit

 

History

History
95 lines (67 loc) · 2.77 KB

0984-drop-safari-less-than-14.md

File metadata and controls

95 lines (67 loc) · 2.77 KB
stage start-date release-date release-versions teams prs project-link suite
accepted
2023-11-02 15:40:00 UTC
cli
data
framework
learning
steering
typescript
accepted

Drop support for Safari < v14.1

Summary

Until v14.1, Safari doesn't support:

Other features in the ecosystem,

class static initialization blocks:

This RFC is not concernd with static initialization blocks, as those can easily by transpiled without adding a a lot of code.

Motivation

Private class field transpilation has a big impact on the kind of code emitted. We want to transpile as little as possible -- ideally nothing, and let app users decide if they need to transpile further.

Detailed design

Ember v6 Will not support Safari < v14.1

This is the bulk of the RFC.

Explain the design in enough detail for somebody familiar with the framework to understand, and for somebody familiar with the implementation to implement. This should get into specifics and corner-cases, and include examples of how the feature is used. Any new terminology should be defined here.

How we teach this

What names and terminology work best for these concepts and why? How is this idea best presented? As a continuation of existing Ember patterns, or as a wholly new one?

Would the acceptance of this proposal mean the Ember guides must be re-organized or altered? Does it change how Ember is taught to new users at any level?

How should this feature be introduced and taught to existing Ember users?

Drawbacks

Why should we not do this? Please consider the impact on teaching Ember, on the integration of this feature with other existing and planned features, on the impact of the API churn on existing apps, etc.

There are tradeoffs to choosing any path, please attempt to identify them here.

Alternatives

What other designs have been considered? What is the impact of not doing this?

This section could also include prior art, that is, how other frameworks in the same domain have solved this problem.

Unresolved questions

Optional, but suggested for first drafts. What parts of the design are still TBD?