Ember — the good, the bad and the ugly

In the eyes of a Vue.js developer

Stephan Hug
3 min readAug 25, 2021

Disclaimer: These are my own thoughts. I am in no way saying that any of this is factual. Feel free to disagree with anything or everything. Take from it what you want.

Copyright: Craig Duffy (really?)

I have worked with Vue.js for quite a while now. Most of my time I have spent working with the excellent Quasar framework. Recently, however, I have started a new job at a software company that uses Ember.

The people at my new work are largely “pro”-Ember. This was somewhat surprising to me. I have known about Ember for a long time and even tried it for a bit back in the Rails 3 days, when SPAs were all the hype. However, for the last couple of years I felt like Ember was really falling behind.

Having worked with Ember for a few weeks now, I would like to reflect on a few things that I have observed.

The good: It is battle tested and offers LTS releases

What I definitely like about Ember is the long-term security that it appears to offer. There are clearly labelled LTS releases with clearly outlined deprecations, etc.

We all remember the f**k up that was Angular 2 and some of us might feel similar about the change from the options API to the composition API in Vue.

Ember appears to not have done anything like that. Yes, there has been the change from Ember classic to Glimmer with Ember Octane but, at least at my work, everybody appears to be happy about this, and it also brings Ember very much in line with other contemporary frameworks.

The bad: The eco-system for Ember is just not there (anymore ?)

Let’s be honest. The Eco-system for Ember is lackluster. Ember devs might get mad at me for saying this, but many libraries do not support Ember out of the box without some degree of hacking around.

As far as a UI component libraries for Ember go? I only know of ember-uikit. EmberUI is actively developed (I think?), but offers only 8 components. These is also Ember Boostrap (but its 2021, who still uses bootstrap?). If you compare this with frameworks that are made with Vue or support Vue:

If you are developing an Ember app, you are largely on your own. You won’t be able to simply slap together a bunch of components as you can with Vue. For me, this is a huge decrease in productivity.

You can use things like Apollo, but it's meh. Support is much better for Vue and React.

The ugly: Lack of good life-cycle hooks, build pipeline, BLOAT

There are a couple of things that I have noticed in my short time with Ember:

1. No life-cycle hooks

It absolutely blows my mind that Ember does not have any real support for life-cycle hooks as I know them from Vue. In Vue I got my “created”, “mounted”, “beforeDestroy”, etc. In Ember I need to hack them together using modifiers. However, and this is the kicker, this is apparently not even the recommended approach anymore? Even though it appears in their own guides?

I also find it hideous that my template tells my component that it should execute some kind of life-cycle hook.

2. Build pipeline

Broccoli is bad: no tree shaking, changing a component refreshes the entire app, what is this 2009?. There is an alternative, Embroider (which is basically webpack), but it has been “almost finished” for a long time. Elon Musk would say “soon”.

3. Bloat

Ember is enormous. When I open the Ember documentation, I get over 320 KB of JS. Doing the same thing with the Vue documentation, I download 82 KB of JS. Vue in its slimmest form is 33 KB. Does Ember really need to be this big?

Conclusions

I don’t hate Ember, I really don't. I like it. But I think that if it wants to keep up with modern JS frameworks, it seriously needs to get going.

--

--