Thoughts On Ember Octane
Despite trailing behind newer, faster and smaller options, Ember has enjoyed success at numerous companies including LinkedIn and Intercom. Nobody can argue that Ember isn’t used or that it is even dying, it’s just not that popular any more. It’s hard to deny that React has eaten front-end development.
With Ember Octane, many facets of Ember have been improved, Ember applications are still overly verbose and the templating syntax which uses Handlebars feels outdated.
In Octane, some of the changes actually resemble that of Aurelia dating back to 2015. Previously, view-models and templates were located in separate directories. The old approach looked like this:
app/ components/ my-component.js templates/ components/ my-component.hbs
In Ember Octane, this now resembles that of frameworks like Angular or in my opinion as mentioned, more closely to Aurelia:
app/ components/ my-component.js my-component.hbs
As you can see, the view-model and template are in the same directory now. Likewise, Ember Octane introduces a new decorator for computed properties called
@tracked which is reminiscent of Aurelia’s
@computedFrom decorator. A similar concept further cemented by the introduction of a decorator called
@computed in Ember Octane.
For me personally, there is nothing in Ember Octane that is exciting or innovative enough that it would suddenly win back developers who left Ember or have eschewed it for other options such as React and Vue. Still, it is great to see the project is maintained and this is all a positive step in the right direction.
I don’t want people to misconstrue this post as a beat-up of Ember with a hidden agenda to promote another framework. I think the more frameworks and libraries there are, the better. But when you’re competing with the big daddy React or up and coming superstar Svelte, you have to bring something substantial to the table and really, Ember doesn’t feel that different when you dig beneath the surface.