This blog post builds off the ideas started by Preston Sego, Dan Gebhardt, and many others.
It's been really exciting to see Ember turn a new page with its move towards modern JavaScript and slimming of its API surface. Routes rendering a template that is backed by a controller remains the most obviously clunky part of the Ember API. Getting consensus on moving query parameters and having routes load components will give us an API that we don't have to make excuses for (especially in conjunction with Component Templates Co-location).
This might go without saying, but as part of this change, the loading and error substates should render components, rather than templates.
At EmberConf 2017, Tom Dale presented the Ember Hierarchy of Skepticism:
- Metamorph Tags/ {{bindAttr}} (addressed!)
- No Documentation (addressed!)
- Custom Object Model (addressed!)
- Big File Size
- Monolothic
While I believe moving past controllers is the most important issue facing Ember at the moment, I think this hierarchy is otherwise still accurate and should continue to be a guide towards prioritizing Ember's developerment.
Ember's file size has always been a sticking point, and while that concern is often overblown, it still has merit. Embroider is a great step is reducing file size through tree shaking and code splitting. Getting Embroider to 1.0 and included in Ember CLI by default should be a top priority. Any further work to make the most of tree shaking and code splitting (such as making Ember Data work well with these features) should also be a part of this priority.
Serving ES2015 assets to modern browsers should also be a priority for a straightforward win on file size.
I don't think I can say anything new about why it's a good idea to modularize Ember into independent packages. Dan Gebhardt does a great job explaining what needs to be done. I imagine that this modularity will also lead to file size improvements for people who aren't using older parts of the framework.
Glimmer components have started the movement away from the Ember object model. The more that Ember embraces modern JavaScript and sheds its object model, the easier it will be for new developers to come and not get hung up on Ember's vestiges of the past. Moving Ember's classes to native classes and extracting EmberObject into an add-on will allow EmberObject to be deprecated and push the entire community towards native JavaScript.
With all of the deprecations from the past year, and hopefully the future deprecation of controllers and EmberObject, there will be a lot of deprecated code included in Ember. Tree shaking will take out this code so that it doesn't impact end users, but after a few releases for people to move off controllers and EmberObject, a 4.0 release will signal to the community that Ember's smaller, native JS-based API is the way forward. As Preston Sego put it, let's achieve "the vision of ... ember [as] just a thin layer on top of native javascript"!