It has been asked, so I'll play the game and give inputs for Ember.js 2019/2020 roadmap!
Big things have been shipped this year. Native classes is probably the most important one 🤩. Congrats! But there is also the work on ember-data 🏗 (thank you @runspired). jQuery removal 🚿 was a big thing. As well as the runloop elimination 😅 and ember-auto-import 🚀 creation.
I don't intend to deliver here a wish list. That doesn't make much sense. Instead, I'd like to point out things that really matters IMHO. I'll give along these a few examples. To help Ember keep moving forward.
At Qonto, we now have open source days to contribute back to the ecosystem. So, some examples above may eventually become PRs.
First things first, DX should not be neglected!
ember help takes too long. If it provided an early feedback in less than 150ms. And then printed a result in, say, less than 1s. Do you imagine? That would change our every day lifes! I'm talking about the help command as an example of course. It applies for all other commands.
The build is too long. More details below!
CX matters as well!
Reasonably quick reviews: IMHO reviews are at least as important than actual contributions. They are essential to help people move in the right direction. It drives contribution to the projects. It let people improve their skills and thus it strengthens the ecosystem. A lot of people are doing an amazing job in doing reviews. I don't want to increase the pressure on them. Instead, I want to point out what I see as a bottleneck of the organization. That can be frustrating.
ember-cli error logging should be improved. In some cases, the stacktrace leaks to stdout or stderror after the process has been killed. It's not a big deal but still it remains a poor experience.
ember-inspector matters. The tool already covers a lot features. Modernizing the design a bit would be nice 🙂.
That being said do not take me wrong
I'm not complaining! I say that to help moving forward. Because I think that honest feedbacks can help. At the same time, I think that Ember has great strengths. Among which:
- a dependency injection system
- a best-in-class rendering engine
- a super efficient plugin system (and an overall very good architecture)
- a very good testing story
- a very good component API (coming with Octane)
- smart people working in the same direction
- pretty good documentation if we forget about stackoverflow and google search results 🤣
My point is: DX is key to onboard and retain new users, especially for frontend technology. In my opinion, it is less about doing a lot of extra work than paying attention to the small details.
At the crossroads: embroider
Also, this would unlock the much awaited and needed features: tree shaking and hot reloading out of the box.
As far as the framework is concerned
side-note: The following items look secondary to me. I wouldn't be shocked if embroider would be done next year but none of these items.
The file layout is now - at best - odd! 🤣 It is probably the most confusing thing for newcomers. At some point, it'll probably need to be addressed.
Controllers are a footgun (quoting @hakilebara). Their main problem is that they are singletons. It’s easy to forget that their state is not cleaned when the route changes. Their
init() hook is only triggered once, but it is easy to think that it is triggered whenever it’s associated route is activated.
The concept of route is also confusing for newcomers. From a developper standpoint, it would be totally fine to drop loading / error states from the routes. Actually, it would be best to have them as a feature of the component API, maybe as a plugin. Rendering a template per state (loading, error, loaded) would be a great feature. Ember builds ambitious application. But I feel this feature is too much ambitious for the routes. Being added by a plugin would be totally fine.
Moving the model hooks at a component level could be considered as well.
Scoping css in routes' template is hard. Today we use
ember-component-css in our apps to do this. The addon adds a dynamic class on
<body /> based on the active route. But this way of scoping CSS is brittle.
A few side notes about communication
Providing with rough and realistic release versions for the features listed in the roadmap would improve the communication.
It’s hard to track when a specific Ember feature was released.
Unify the ecosystem's websites to demonstrate the power 💪. Like Vue for instance is doing in its
ecosystem tab on https://vuejs.org
Thanks for reading! Feel free to ping me for further discussion.