There are too many JavaScript frameworks out there, and I am not a JavaScript expert. I have neither the time nor the inclination to put all them to the test and come up with rational, experience-based arguments as to which one is superior, be it in general or for a specific task. Similarly, if I look for opinions of experts, I am always going to find articles praising one over the others, in all sorts of situations and contexts. Therefore, when the time came for me to choose one of them to use, I had to rely on different metrics.

My choice was Ember.js, and these are the reasons for my decision.

A community effort

Ember is a fully community-directed effort. Several companies, large and small, with competing interests are involved in its development. This is in contrast with React.js, developed mainly by Facebook, or Angular.js, developed mainly by Google.

I do have a small, yet significant concern that these frameworks will make progress in accordance with the desires of their primary backers, rather than those of the community. In other words: this opens the door for behaviour, features, or simply general direction that benefit the use cases of a single company, against those of their users outside of it. This is a concern I do not have with Ember.

(There’s also the matter of whether React’s license is open source or not, good or bad, but I’m not going to go in there).

The development process

In a related point, Ember’s development process is extraordinarily open and deliberate. Every substantial change requires going through an RFC process where the initiator must not only present their case, but also list possible drawbacks and alternatives. This greatly increases the chances of all possible use cases being considered for the benefit of all users.

Convention over Configuration

Ember follows the principle of Convention over Configuration. Some time ago, I tried out Angular.js, and one of the sensations I had was that I didn’t know where stuff went; how to properly organise a project. As a long-time user of Ruby on Rails, I appreciate a framework being opinionated. It removes from my mind these small worries, while letting me focus on how to work on the actual problems that the project was created to solve. It enables new members of the project to quickly understand it, as the structure will be similar to that of other projects with the same framework. It provides tested, stable solutions for common problems, supported by established best practices in the community.

I have met people who felt otherwise, and wanted more control over small and purely technical details of the software they were building. I think that is not control, but an illusion of it. At the end of the day, you will end up having to build the same foundations that an opinionated framework would have provided in the first place: you are bound to reinvent the wheel… poorly.

Stability without Stagnation

Ember commits to provide Stability without Stagnation. The JS community is too used to having to reinvent itself every year, throwing away yesterday’s tools and rebuilding everything at the whim of today’s new fad. Ember promises to offer clearly-defined periods of backwards compatibility combined with clear upgrade paths. In the words of co-creator Tom Dale:

The Ember community works hard to introduce new ideas with an eye towards migration. We call this “stability without stagnation”, and it’s one of the cornerstones of the Ember philosophy.

An example of this is the introduction of LTS (Long Term Support) releases. Development teams have better things to do than upgrading their framework every six weeks (the length of Ember’s release cycle). To avoid this, LTS releases allow teams to stick to versions for longer, while still getting support (ie: bugs being addressed) and increased attention to upgrade paths.

Not everything is rosy

Before order, there was chaos

Before Stability without Stagnation, there was a fair amount of confusion. Not sure when this changed, but at some point before version 1.13 order was restored, or rather formally instituted for the first time. Until then, changes were happening too rapidly and without that much fanfare. Each new version could bring a breaking change that would affect your app. It affected me a bit, but I was lucky to arrive towards the end of this previous era, and with small apps that were relatively simple to upgrade, so I made it through unscathed.

Lessons were learned and good overcame evil, but some of the fallout remains. One manifestation of this is that I must filter Ember-related searches to content from 2015 onwards. Anything older than that is very likely to refer to abandoned practices and interfaces. Remember to do this when you search for resources.

Documentation can improve

Ember’s official documentation wasn’t always up to scratch. Fortunately, this has also been addressed with the creation of the Learning sub-team, tasked not only with improving the documentation, but also generally make Ember easier for users old and new.

There’s still some way to go here though. I regularly have conversations with Ember users where we agree that certain idioms are not well explained, and sometimes there’s confusion as to the best way to implement certain common patterns, or make known parts of Ember work together. Still, I have seen great improvement in the last year, and I have high hopes in this venue.

Ember is large

As built on my laptop right now (using Ember 2.9.1), the framework portion of Ember.js weighs 655.62 KB (175.49 KB gzipped). that’s a big download for the JS of your website, and about 3x-4x the size of React’s according to comparisons online.

In its defence, Ember does more than React, and when using the latter you’d need to incorporate a large number of third-party packages in order to get the functionality that you’d normally get by default with Ember. And sure, you may not need some pieces, but it does help your process if you don’t have to think about which plugin to choose when you are faced with a decision on how to fill a functionality gap that Ember would have already provided.

Not only that: Ember is en route to provide a solution for this problem too. It won’t be tomorrow, but it will arrive. There is an active effort, formalised in the form of several RFCs, to reduce the weight of your Ember builds. One such feature will be present in Ember 2.10 (slated for November 2016): lazy engines. This is the ability to split your application into smaller applications that will only be loaded if the user actually visits them, all with minimal configuration on the developer’s part. More is expected to come, such as dead code elimination or removal of old APIs (within the constraints of Stability without Stagnation).

Drinking the Kool-Aid

This is the Kool-Aid I have decided to drink. From the information available to me, it does appear to be the best, most sensible choice. I am hopeful it will be. Of course I can be wrong, but I have to work with what I have.