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.
Even today, templates are still controversial. The React community popularized the idea of JSX, CSS-in-JS, images-in-JS... as well as the tooling that makes all of that possible. There are a lot of folks who enjoy programming in that environment, and that is great. But if you are using Ember, you probably enjoy writing templates, and that is great too. Most of us see a lot of value in having a dedicated, constrained template programming language that is more apt for the job than JavaScript.
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.
The next wave of improvements will come via the contextual helpers feature. While the feature itself is pretty neat, it's probably not something that you would use all the time. However, the work to make this happen flushed out a lot of inconsistencies in the language that will be fixed as part of this. It makes components, helpers and modifiers true first-class values in the language, which aligns well with JavaScript developers' expectations. These may not be something you actively think about, but it certainly adds friction and confusion to the developer experience that are hard to attribute.
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?).
Speaking of which, the last few RFCs are all leading up to the grand finale – single-file components. While I think the files are a good way to organize logically separable units of code, component code and template are not really separable in the same way that your login and profile page is. In order to understand either, you really need the other piece to put everything in perspective. Therefore, having the option to put component code and template in the same file would be a nice improvement. Moreover, this unlocks a powerful feature we enjoyed in JavaScript – module scoped (i.e. private/unexported) components, helpers, modifiers etc.
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!
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 model hook).
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!