Intent to RFC: Svelte Flags

[pzuraq]

Ember Octane is now nearing completion, and the core team is hard at work polishing up the final release, myself included. We're really excited about all of the new features and the new programming model, and are maintaining a laser focus on making sure it's a great experience for users who are upgrading, as well as users who are new to Ember altogether.

Because of this, we haven't really had time to focus on much else! I've stopped writing blog posts until Octane officially ships, and I know there has been considerably less activity on RFCs in general. However, community members have stepped up and kept the ball rolling with various RFCs, which has been amazing and encouraging - this is a sign of a strong and vibrant community!

I wanted to put a number of pre-RFCs out there, both to lay the path out for simplifying Ember and jumpstart discussion on the timing of various things, and in case anyone wants to pick one up. This is the first of those pre-RFCs: Svelte Flags

What Are They?

Svelte is an idea that has come up a number of times in Ember, and with some recent changes it's finally a possibility. The idea is that when we deprecate some functionality, we can also flag that functionality within Ember such that users can opt-out of it early on entirely. This has two major benefits:

1. Users who have removed those features from their apps entirely no longer have to pay the cost of these features. If a feature is 5kb after min+gzip, that's a decent sized chunk to download when you aren't even using it anymore.
2. Users can prevent reintroducing a deprecated feature. Large team's can be difficult to coordinate, and it's always possible that someone didn't get the memo about a particular feature being removed. Removing it prevents anyone from accidentally using the feature in the first place. Additionally, it prevents users from accidentally including dependencies which use the feature.

Svelte flags will incentivize users to remove deprecated functionality sooner rather than later, since they can get real benefits from them today. Additionally, new applications can be made with the flags enabled by default, allowing us to market Ember as a smaller framework, and preventing new apps from accidentally relying on older functionality.

How Do They Work?

There are two major thoughts on how Svelte should work:

1. Every deprecation specifies the version it will be removed in. This means users can specify a future version their app is compatible with, and all deprecated features for that version would be disabled. This is nice for its simplicity, but has a couple of flaws:
   1. If multiple features are deprecated in the same version, e.g. both EmberObject and computed properties are deprecated in v5.0.0, then it might be difficult to remove both at the same time.
   2. If new deprecated features are added for that same version in future releases, then apps that were compliant may no longer be compliant, and may break.
2. Every deprecation should be enabled/disabled manually via a flag. This would allow for fine grained control, but would be more difficult to maintain, especially for enabling flags out-of-the-box with new applications.

I personally think we need to have some ability to specify things directly, as in option 2, but I think we could do some combination of both as well.

What About Tree Shaking?

Tree-shaking is a great way to get similar benefits to Svelte, but reorganizing certain parts of Ember Metal to take advantage of it would be very difficult, and may even introduce performance regressions. This is because many of these features are directly tied under the hood, using shared abstractions like Ember's meta system.

There are cases where tree-shaking absolutely makes sense, and we should continue to work on the codebase to get Ember to a place where various parts of the framework can be tree-shaken (one great example is the Router's location API, most people only use history or hash, there's no need to ship all three!)

[mehulkar]

Huge subscribe to this. This would be a fantastic reward for adopting new paradigms quickly and keeping the framework moving forward. Not sure if feasible, but it would also be great for addons to use the same mechanism to add custom deprecations and offer a way to shave off those bytes.

[michaelrkn]

This would be a great step forward for Ember's file size! I think another important and complementary approach is the long-talked-about npm-module-ification of Ember. Perhaps it warrants a different issue/intent to RFC, but I could see users either choosing to have a package.json indicating they implicitly want everything:

"dependencies": {
  "@ember/everything": "^3.14.0"
}

explicitly want everything:

"dependencies": {
  "@ember/application": "^3.14.0",
  "@ember/array": "^3.14.0",
...
  "@ember/routing/history": "^3.14.0",
  "@ember/routing/hash": "^3.14.0",
...
  "@ember/object": "^3.14.0",
...
}

or don't want to include some or all of the deprecated (or soon-to-be-deprecated) parts:

"dependencies": {
  "@ember/application": "^3.14.0",
  "@ember/component": "^3.14.0",
  "@ember/routing/history": "^3.14.0",
  "@ember/service": "^3.14.0"
}

This would provide a familiar API for choosing what to include or not include.

That said, maybe this runs into the issue you alluded to where "many of these features are directly tied under the hood", and this module-based approach has the same issues as getting them to where they can be tree-shaken.

[pzuraq]

The core goals of this pre-RFC have been for the most part implemented via the Deprecation Staging RFC: https://github.com/emberjs/rfcs/blob/master/text/0649-deprecation-staging.md

As such, I'm going to close this! Thanks for the discussion everyone!