Use native classes with decorators.
The wind has been blowing this way for quite a while, and the time seems right to switch. The conversion doesn't appear too difficult, can be done gradually, and the benefits (standard JS, cleaner code, better tooling, slimmer framework) are clear. This blog post by Chris Garrett is a nice introduction to the topic.
Use tracked properties as soon as they're available.
Ooooh do I like this one! The idea of tracked properties is to explicitly mark the changeable state so that anything that depends on it will know when it must be rerendered. Think computed properties, but in reverse. In addition to removing the need to use
set(which is nice), it is more explicit and fixes the "flow" of change propagation. The before-and-after code examples look excellent, and I love that it can be adopted incrementally (one field at a time). This blog post by Chris Garrett is a nice introduction.
Use Glimmer components.
tagName: ''in our classic Ember components made them way easier to reason about by putting the entire template in the template. Glimmer components simplify things in a first class way, and when combined with element modifiers, they provide what looks to be the right separation of concerns. This blog post by Chris Garrett provides some examples.
Transition to modifiers.
If you want to get excited about modifiers (which oddly weren't talked about much at the conference except at lunch which turned out to be an excellent impromptu talk by Matthew Beale), check out the Ember Functional Modifiers video from EmberMap. Moving behavior into the template at the element level is both more clear, and is more flexible (you don't need component hooks for the kind of functionality that have historically relied on them). There is some work left to do before this feature is finalized, but some nice add-ons are available that allow for exploration right now. This blog post by Chris Garrett provides some additional detail.
Use EmberData Storefront to attack data loading bugs.
I had a conversation with someone that attended the pre-conference data loading workshop focused on EmberData Storefront. We haven't tried the library yet, but I expect that we'll adopt it right away. One of our largest categories of bugs relate to being either overly optimistic or overly pessimistic regarding data loading. I love that there's an add-on built to attack this problem that goes with the EmberData flow. I haven't watched it yet, but there's a video on YouTube with Sam Selikoff and Ryan Toronto from EmberMap that I'll watch next.
Maybe extract primitive components and styles into a styleguide add-on.
In his Building a UI Styleguide in Ember talk (which I saw in a version of at EmberCamp Chicago), Frédéric Soumaré demonstrated an interesting approach that they use at qonto for bundling reusable presentation components and styles into an add-on. The cost seemed pretty low save some initial setup, though I imagine it could be a bit difficult if there was significant churn that had to be synced across a medium-to-large team. I'm interested in exploring the option value of having the reusable bits be portable across apps, and making the choice about where to put a given component seems valuable by itself.
I was happy that I learned FastBoot when I figured out how to deploy a static-first version of this blog using prember, and I could tell from the great Anatomy of an Addon Ecosystem talk by Lisa Backer that I'd be happy if I learned about how to better use service workers too.
Build something real with ember-animated.
After watching Ed Faulkner's great ember-animated talk last year, we built a fun proof of concept using it. But since then, we haven't done too much. I heard some good things about the pre-conference animation workshop over lunch, and that encouraged me to have us build something a bit more substantial with the library this year. I think my main problem is that I don't have a lot of confidence about what and when to animate! I could use a book like Refactoring UI but for animation. For now, I feel most comfortable copying things that I see elsewhere.
I first tried Ember because I believed in the sensibilities of Yehuda Katz, and that bet has paid off. I also believe in the sensibilities of Dan Gebhardt, and so it's time to try orbit, his composable data framework.
When I see Ember apps written in TypeScript, I'm jealous. They look excellent. I've only ever written a toy glimmer app in TypeScript, and I think it's time to do something more substantial (but probably with a limited surface area to start as I learn the language and tooling).