Deprecate all of Ember Classic about rfcs HOT 16 OPEN

I've brought this up with core team members in the past but I think I may as well lay it out here.

Ember can't deprecate classic unless ember-data deprecates it first. We've got a chicken-egg problem and it seems better for ember-data to absorb the break first because otherwise it has to somehow support ember both with and without classic support and in doing so would be flooding folks with deprecations they couldn't resolve.

For ember-data to stop using classic APIs we'd have to drop support for classic ourselves, most notably Mixins, Reopen, computed properties, and observers. We began this work with #738 and #793. The rough idea is to break lockstep and target releasing our own major in which we drop support for pre-4.0 ember + all classic ember APIs (e.g. our support matrix will be tighter than simply 4.0 ember, it would also limit what ember we supported to soley the class+tracked world)

from rfcs.

(For what it’s worth, I’m one of those members who has had that conversation and I agree. @runspired and I and many others are talking about the path forward here, including multiple discussions at Framework team meetings throughout the spring, and I think we’re getting toward consensus. That RFC will likely need to come before or in parallel with this one.)

from rfcs.

Speaking for all the teams with legacy Ember codebases for which this is going to involve lots of work:

Is there an opportunity for (at least the major parts of) Ember Classic support to be moved into an (intimate) addon, similar to what was done with ember-jquery?

I totally understand the drivers for Ember core to shed itself of Classic, since I imagine removing this support would likely:

• Remove a substantial amount of code, thereby reducing Ember's page weight
• Improve (or at least create opportunities to improve) load/render performance
• Enable future functionality to avoid having to consider how they interop with classic syntax

If this support could be migrated into an addon (a big "if" no doubt), then I feel like you could still reap most of these benefits for new/modern Ember apps, without forcing legacy apps to either rewrite or stagnate. Certainly I imagine Ember core would need to retain some hooks for the classic addon to utilize, so you may not be totally free to change things in core, but I think you could still be free to introduce new, optional functionality that is incompatible with classic, just as there are times when new Ember functionality may be incompatible with existing addons. Maybe it's simply infeasible given current resources, but I feel like if this option were taken, then the changes would be much more readily received by the entire Ember community.

If Ember Classic is simply unsupported in the near future, then this is IMHO akin to the Python 2->3 transition, where every app and addon must either achieve compatibility or effectively die. The Python 2->3 transition lasted for more than a decade, and ultimately required changes in core and the introduction of compatibility libraries, and even then many Python 2 apps and libraries were simply left behind in the process. I recognize that spacing the breaking changes over several major versions (#830) is an attempt to mitigate this problem, but the total effort to get off Classic remains the same (and is potentially larger if you are forced to do it over a period of years) so I'm concerned that we're likely to end up with a similar or worse outcome. Arguably, Python 3 has come through the transition and now reaps the benefits, but it only occurred with lots of effort over a long time from a much larger community, whereas Ember is (like it or not) a much smaller framework in larger JS community. Faced with a need to rewrite much of their app, many teams may simply (and sensibly) choose an more popular web framework than betting on the long-term prospects of Ember community who just left them with an unsupported app.

Admittedly, the last paragraph contains much fear, uncertainty, and doubt, but I really fear that as a likely outcome, so I return to my opening question:

Is there an opportunity for (at least the major parts of) Ember Classic support to be moved into an (intimate) addon?

from rfcs.

I expect this to be one of the main subjects covered by the RFC. Certainly pieces of it will be able to support that, but not all of it. For example it is essential to simply get entirely rid of the classic observers and computed properties; from what I can see, the interoperability story there is either baked into core or it would come with so many caveats that it would require substantial rework anyway… at which point you should just be going to Octane. Likewise, I think we have to completely get rid of classic classes.

That doesn't mean that we have to completely get rid of everything, though. Figuring out what those cut points are, and what can reasonably be pushed into a legacy support ad on and what cannot is one of the major things that I plan to work through as I work on the RFC and discuss it with the community and the Framework team in the months ahead!

Also, look for a blog post from me on the LinkedIn engineering blog sometime this year discussing how we have successfully incrementally migrated the entirety of the flagship app to Octane—millions of lines of code!

A meta point: while I am trying to reassure people a bit here, this issue is not the place to hash out all of these things. The RFC itself is!

from rfcs.

Don’t panic, everybody. 😅 This will happen with ample time for migrations! I’m waiting in part to get to a decision on #830, so I can target the deprecations for an appropriately generous timeframe!

from rfcs.

Not the RFCs, but basically the roadmap for EmberData's next major is now here: emberjs/data#8086

from rfcs.

Idk if it's been mentioned anywhere, but when the usage of prototype-extensions are deprecated and eventually removed from ember-source, I think it'd be good to have a v2 addon re-providing those extensions for those that are not yet ready to migrate away.

For example, when prototype-extensions are deprecated and eventually removed, folks could opt-in to installing a new addon, maybe @ember/prototype-extensions (or @ember/legacy-prototype-extensions to be clear prototype extensions in general is a legacy pattern), and folks could install those extensions in their app.js:

// app/app.js
import '@ember/prototype-extensions/array';

// ...

This side-effecting import would install the array prototype extensions, and there is no need for build-time transforms because with v2 addons, stuff that's not imported is not included in the build.

from rfcs.

Agreed! You and I should sync up next week and work on that!

from rfcs.

We should get the ball moving on "ember-data controls its history / ember-data timeline" though. Roughly we would like to major ember-data around late early December and that would be the release in which we drop support for classic.

from rfcs.

@robbytx Thanks for the detailed feedback. What you've shared is definitely a valid concern and I'm hopeful we can mitigate it. I do think it's possible for at least some of the classic behavior to be moved into addons such as was done with @ember/legacy-built-in-components.

from rfcs.

@robbytx I should also point out that, unlike migrating to an entirely different library, one can migrate away from Ember Classic incrementally. This is a huge win. I've tried doing "rewrite the world" migrations before and they never go nearly as smoothly at it seems like they will. I have, however, done rewrites from Ember Classic to Octane and, though a non-trivial amount of work, those didn't have any of the major issues that "rewrite the world" has.

from rfcs.