Wishes: Policy Changes 🧹

There are a number of concepts that were proposed (or actually existed) in Ember-land that are now broadly considered a dead end. The Ember project as a whole needs to get much better about closing the loop on these dead ends, and communicate more clearly with the community so that they can avoid known future pitfalls when developing their ambitious applications.

Ember 2019 Roadmap Process 🛣

The #EmberJS2019 call for blog posts went out a few days ago. Seeing these posts pop up made me start to think about what I would like to see happen in the next year. The pressure of "getting the perfect list" is too much pressure for me 🙀, so I've decided to try to do a few smaller posts where each is focused on a specific area that I think we can improve on in the coming year.

This is the second post (SEE I DID IT!) in my personal wishes for Embers 2019 Roadmap process, if you missed the first one please check it out here: Wishes: Packaging Improvements.

Module Unification 🔫

It's time for some cold hard truth: Module Unification is dead 😭 (see here, here and here for example). No one is more sad than I am (well, maybe @mixonic is), but it's time. Seriously.

It's unlikely that I would explain the issues better than @tomdale did over on the main Ember blog so go over and read through that post (make sure to come back though 😉).

The thing to keep in mind here is that I am not saying:

We should throw away all of the thinking and designs that were part of it.

But instead, I'm saying that the specific implementation that was proposed can't be implemented (it's been years and still not done, if it were "simple", don't you think we would have done it!?). The vast majority of file system design still absolutely makes sense and I imagine that when the dust settles on all of this what we have will be quite close to the filesystem layout proposed as part of Module Unification.

Instead of trying to solve "all the things" (which the Module Unification RFC valiantly tried to do) we should be focusing on how we can iteratively move forward into the future that can actually happen. For example, one of the major benefits of Module Unification (and pods 🤫) was the ability to co-locate a component with its template. Well, emberjs/rfcs#481 suggests exactly that, and it's close to being implemented (behind a feature flag). This is exactly the type of iterative improvement we need!

In order to move forward here, we _must_ clear the deck. A large amount of the existing Module Unification code (behind a feature flag) is essentially tech debt at this point, and it's getting harder and harder to move forward while keeping it around. The folks on the core team (yes, even the strongest proponents) see the current strategy as a dead end, it's time to make that official so we can move forward.

Module unification is dead! We should put together a "revocation RFC" to explain the rationale and communicate clearly to the community. Then we can show what we've learned about shipping things iteratively and actually make our file system layout dreams happen.

Lockstep Versioning 🦹

Lockstep versioning is the policy that ember-data and ember-cli follow to ensure their version numbers and release schedule match Ember's own. For those that are interested in the origin story, I dug up the link to the introduction of Lockstep Versioning from all the way back in the EmberConf 2015 keynote. The goal is to ensure that the official packages can be used without having to manually dig to figure out what versions of Ember, ember-cli, and ember-data actually work together. The proposed way to accomplish that was to ensure that all "official" packages use the same major and minor version number, which (at least in practice) is ultimately dictated by Ember itself.

I personally think that the goal of not having to do a bunch of work to figure out what "magical" combination of package versions to use is a very good goal. However, in practice very few things evoke such strong negativity amongst "official" package maintainers than the idea of lockstep versioning. To quote Steve Klabnik's blog post on SemVer:

Fundamentally, version numbers are a communication tool, and SemVer provides a framework for said communication.

The promise of following SemVer is that your users can know when a given version upgrade is safe for them to do versus when an upgrade may break something in their library or app. Unfortunately, the concept of lockstep versioning removes the maintainers' ability to declare something as a "breaking change". The result is that from the perspective of our users the version numbers of projects like ember-cli and ember-data are practically useless.

For example, ember-cli@3.10 dropped support for Node 6. Dropping support for a given previously supported platform absolutely should have been a major version bump, but due to the requirement that ember-cli and ember-data releases match Ember's own version number the ember-cli core team could not do the right thing here.

Now, I know what y'all SemVer lawyers are going to say:

Since ember-cli declares that it only supports versions of Node that are themselves supported by the Node Foundation, dropping support for an unsupported Node version isn't a breaking change.

You know what I say? Bull$#*! 🤬. While this is technically true, the entire point of using version numbers is to communicate to our users when a given version should be safe. If people in practice upgrade and have breakage, no amount of "SemVer lawyering" is going fix their app. The fact that we publicly stated that we only support "supported Node versions" is just a way to weasel out of doing the right thing.

I propose that the Ember project drop the idea of "lockstep versioning", and instead focus on solving the original problem (being able to easily pair related official packages together) in a different way.

Our community is very smart, we can do this. 😁

Conclusion

I'm sure this has been a bit more blunt than usual, but I think that being direct (while still being respectful) is the only way that #EmberJS2019 is any help at all. To state the obvious: as a core team member I care very deeply about the Ember community.