Ember.js – 5 Reasons You Should Avoid It

bug

Let me share with you 5 reasons why you should avoid this “ambitious” and “opinionated” framework.

Reason #1 – Ember Data is not production ready

The first thing you see at https://github.com/emberjs/data.

Screen Shot 2013-07-31 at 1.58.15 PM

Yikes, a cute little gopher holding a construction sign. They say it’s not production ready and won’t be until 1.0. The latest release is currently at 0.13 and there are 193 open issues. It’s supposed to support polymorphic sub-models, but we couldn’t get that working. We also weren’t able to customize foreign key relationships on some of our models. For example we needed to sideload an array of ids in comments (vs the standard comment_ids). The included REST adapter isn’t very customizable and only works for a limited number of use cases.

Reason #2 – Singletons, singletons everywhere

While not technically singletons, things are setup and behave in a very similar manner. You define and throw everything (models, views, controllers, the router, etc) into a single global App namespace. An instance of each object will be instantiated on startup and is retrievable by the name you gave it. For example, App.IndexController would be retrievable by this.get(‘controller.controllers.index’). This is the framework wanting to be opinionated. Dependencies must be defined using the “needs” API. Controller A needs Controller B, Controller B needs Controller C, and so on. If you’ve read about or used singletons before, I think you can see the danger. There is potential for things to get messy real fast where we’d end up with circular dependencies and tight of coupling.

circular-dependency

Reason #3 – Model-View-HUH?

Taken from: http://emberjs.com/guides/controllers/

In Ember.js, templates get their properties from controllers, which decorate a model.

This means that templates know about controllers and controllers know about models, but the reverse is not true. A model knows nothing about which (if any) controllers are decorating it, and controller does not know which views are presenting its properties.

embercoupling

In Ember.js, the views know about their controller. They assume properties on the controller exist in order to draw themselves. While I see how this might make it easier for designers to work on templates, it goes against my intuition as a programmer. Plus I’ve never seen this type of reversed coupling in any other framework. Ember views are even granted DIRECT ACCESS to other controllers within the app (via controller.controllers). Spaghetti anyone?

spaghetti

Reason #4 – Difficult to Test

Because of tight coupling and the many assumptions being made in a typical Ember.js app, it becomes increasingly difficult to test individual parts of your application. You also have to deal with the asynchronous nature of the Ember.js runtime (property bindings and automatic observer method calls) where it can be difficult to track down bugs caused by race conditions. It’s not really the frameworks fault when that occurs, but it does present a new set of challenges.

Reason #5 – Limited Flexibility

Making a single page CRUD app against a standard REST interface? You’ll probably be fine. Need to customize things? You might find you’ll quickly run into problems. If you need customizability, instead of fighting with the framework every step of the way, I recommend looking into other options such as Backbone.js and Require.js.

About these ads

4 thoughts on “Ember.js – 5 Reasons You Should Avoid It

  1. Thanks for elaborating with examples what’s bugged me about Ember the whole time. Dependencies may creep in through string arguments – this is as bad as eval if you’re trying to to modularize. Go with a framework that ensures separability – CanJS, Angular, and even Knockout if MVVM may fit your need better..

  2. Reason #6: a LOT of bugs, Reason #7: (when using with hamlbars, … in Rails) – programmint within strings, Reason #8: no version management for blocking bugfixes (must use nightly builds to get a “stable” version running), Reason #9: Permanent changes of everything (no example matches the version you are working with), Reson #10: No documentation that’s worth looking at, Reason #11: ember-data nice for single resource test app, can’t handle nesting in a depth > 2, Reason #12: most layouting goes to javascript, Reason #13: No examples for common problems (I am sure they have no idea how to solve xy, otherwise they would have spent 1 day for that in the last years), Reason #14: “I have an application and when I click on ‘div with ember code 576′ nothing happens” -> happy debugging!, Reason #15: The great error messages that say nothing about the error or where to begin searching for it, … – ember has a lot of potential, since years, never changing there, I am sure it still will be completely unusable in 10 years from now…

  3. Forgot: Reason #16: Typo somewhere in your >300 ember files? Get a nice error like “factory.create is not a function”. You have to debug the framework every few minutes because it has no error messages with a meaning or description. Reason #17: No community. Search for a ember error -> almost no results, if result than in most cases no solution :D

  4. @Anton Been developing in Ember for more than a year, I am frustrated with all of this. (Maybe except documentation and ‘App’ namespace, since I’m using ES6 modules.) I spend much more time debugging Ember core, bindings and various ‘render’ methods than I’d like. At first it seemed like core developers were interested in fixing ‘usability bugs’ but I was probably mistaken.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s