This was a long pending blog post (since 2018) but I wish not to miss the deadline this time. After having worked with Angular for a brief period of 6 months, 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.
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 it 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-weekly and updating the 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 RecordData RFC (#293) had a brilliant explanation on the architecture for present and future. Diagrams speak a million words what a 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).
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.
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 model, beforeModel, 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.
When the idea of Module Unification (MU) 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. This being still a work in progress, I would like us to see this being brought in the next yearly release like Octane. With MU, I expected Ember to surpass the expectations set by the Single File Components convention set forth by other frameworks like Vue, but unfortunately it was called off at the last minute for various reasons.
Code split based on routes is something I’d want Ember to fancy about any day. Using broccoli as a build tool, have been a huge impediment for Ember, in adopting the best and the latest conventions from other frameworks in terms of build pipeline and tooling. Since other frameworks like React, Angular and Vue are heavily betting on cutting edge packaging technologies like Webpack, Rollup and Parcel, while Ember still fixating on broccoli proved to be a costly mistake for the community. 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.