Here is my wishlist for the next edition of Ember.
Templates are arguably the most important pillar of Ember. It's why Ember was born in the first place – Ember grew out of the Sprout Core 2.0 exercise, in which the main objective was to introduce templates to the Sprout Core framework. This has proven to be such a controversial idea that Tom and Yehuda ended up forking the Sprout Core framework and the rest is history.
Interestingly, templates are still, in a way, what sets Ember apart in 2019. That being said, Ember's templating system is not without issues, and the folks from the JSX world have pioneered plenty of ergonomics and productivity improvements that makes me jealous.
So, the first item on my wishlist is to modernize Ember's templating language. I would like us to address some of the long standing issues and missing features, as well as bring in some of the nice things from the JSX world, while staying true to what makes templates feel so productive in Ember today.
The first set of improvements I'm excited about is yieldable named blocks. This has been a long awaited feature. After a few false starts, we have finally arrived at a version of this feature that we are happy with. The implementation is mostly completed at this point, and I expect it to land quite soon. After this first iteration lands, I would like to revisit some of the descoped features – such as "capturing" blocks and a named blocks syntax for curly invocations.
Then there is the "strict mode" RFC. This RFC bundles a set of new restrictions to the Handlebars language. At first glance, that may sound like a bad thing – why would I want more restrictions? Well, the thing is, the "freedom" isn't really free: the extra flexibilities come with ambiguity and confusion for both us humans as well as tooling like compilers, linters and codemods. By making certain things more explicit – such as importing components and helpers, we gain back understandability, maintainability and productivity from better tooling ("jump to definition" anyone?).
While each of these changes may feel small, when combined I believe they will fundamentally change the way we develop UI code in Ember and be a dramatic boost in productivity. I hope we can get all of these changes included in the next edition!
Controllers, Routes and Query Params
While I don't have very concrete ideas (at least compared to the above), I think it is quite embarrassing that we still have to teach controllers to new Ember developers in 2019. They stick out like a sore thumb compared to the rest of the modern Ember programming. I would like us to get rid of them in the next edition.
At this point, the main reason to use controllers is for query params. Therefore, in order to finally remove controllers from the mainline Ember API, we will need to design a new API for query params to replace the current approach which is fundamentally based on two-way binding and singleton controllers.
For the purpose of routing and providing a context for the route templates, I think we should replace controllers and route templates with components. In order to do that, we will probably do a light redesign on the Routes API (e.g. an
arguments hook instead of a
File System Improvements
Half way into the Octane development cycle, we decided to remove Module Unification from the Octane goals. The main reason is that we anticipate template imports to render a lot of MU's original design goals obsolete.
However, to a lot of Ember developers, the main feature of MU is just a refreshed and improved file system layout. Therefore, as we work on template imports for the next edition, we should not lose sight on this still-valid goal of MU. We started making some progress there with the component templates co-location RFC, and I would expect us to continue down that direction in the next edition.
I'm very excited for these changes, and I hope they make it into the next edition!