This was a long pending blog post (since 2018) but I wish not to miss the deadline this time. After having worked with Angular and ExtJS for a brief period of 6 months each, building websites with jQuery and creating products with Ember, I am so grateful that I have decided to stay with this framework for 4 long years and would still continue to do so. So here are my thoughts or rather the wish list that Ember as a community should solve in the near future.
1. Documentation / easing new developer onboarding
Being an experienced Ember developer myself, on-boarding new and fresh minds from a different background of frameworks into teams that use Ember, has been quite a challenge. Not because the framework is difficult to learn, but the dots around the documentation need a bit more connectivity. I’m sure the learning team is already involved in solving this by sending out ember-times and updating the ember guides, but somewhere the connect seems to be missing. Simply put, when a developer joins a team, the first thing that they visit is the website and the first impression isn’t that catchy. We need to do better at making the first impression stand out. In order to make the website standout, there is a new website RFC in the making and I must admit it looks good!
The other aspect of documentation, is in terms of “Advanced” topics where the guides in itself could contain details on how the architecture is setup, how ember data works, and so and so forth. For example, ember-data’s Ember data internals RFC (#293) had a brilliant explanation on the architecture for present and future. Diagrams speak a million words what 10,000 word documentation cannot! It could also help to increase the community contributions. The same goes with Embroider, ember-engines, and so on (Of course these are still WIP).
2. More Octane like yearly releases!
Octane is a huge hit that represented a collection of awesome features that Ember as a community launched. Not just marking releases, but also heavily marketing them is something we need to focus on as a community. Quick-to-demo apps built with a release like Octane, could interest more Ember devs to start trying out these new features.
3. Do we really need controllers anymore?
I for one, still believe controllers have been doing good in projects that are large scale. My way of using controllers is to use them for defining actions, calculating computed properties and defining query params (with or without ember-parachute), while routes are primarily used for
afterModel, and other events. There’s still some confusion with Controllers and Routes, when to use what. As a community, we need to make sure, this is tracked under guides where there is a clearer definition of what is the right approach. In general, a place that talks about best practices.
4. Module Unification or better file system layout
When the idea of module unification was pitched in, it was super simple to quickly view file paths, write test cases, change things in the template, and also help onboard new developers. Though this was planned for Octane and couldn’t make it for the release this time, I would like to see this make it for the upcoming release.
Code split based on routes is something I’d want Ember to fancy about any day. Frameworks like React, Angular and Vue have a heavy bet on cutting edge packaging technologies like Webpack, Rollup and Parcel, while Ember remaining to use Broccoli seems to be slowing down in the race. I think Embroider will not suffer from the same fate, by adopting Webpack as a tool in the build pipeline.
Ember engines do solve the other aspect where apps have logical isolation units, while embroider could be the future of ember-cli for all ember applications. Invoking
ember new sample-app and making embroider the default build system would be the coolest of all things I’d expect in #EmberJS2019.