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.
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.
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.
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?
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.