AngularJS vs. Ember.js

AngularJS

Pros

1. The ease of writing tests.

There’s a big caveat, however: It’s necessary to write tests because the framework relies on executable code in strings (“weak typing”, see below). And so the Javascript interpreter can’t find errors on its own very easily.

Further, in practice I found that a lot of time was taken just getting the test environment functioning.

(At this point in my research, there were too many cons and they were show-stoppers: I could no longer recommend AngularJS to my clients.)

Cons

1. It’s a Google project, not a grassroots open source project

• Is it just a “flavor of the month”?

• Google doesn’t seem to use it on any public apps. (!)

• Can’t find any busy well known apps using it. (The YouTube app on PS3 is the biggest production app I could find.)

2. Coding Style Reduces Maintainability

In short, AngularJS takes Stringly Typed design to a whole new level.

• Weak typing

What I mean is, lots of important code is written into simple strings. Also, the framework entities such as services and apps, all seem to be simply plain Javascript objects.

This makes Angular hard to debug. Line numbers in error messages are unhelpful or wrong. E.g, I had an error was in a file, controllers.js, but its name isn’t listed in the error message.

• Generic functions don’t describe their purpose

E.g. to create an app:

(i) shoeStore = angular.module('shoeStore', []);

(ii) This code doesn’t make clear that it’s creating an “app”, the Angular project’s name for it. Note also the redundant app name and required empty options array. 

compare with Ember:

(i) shoeStore = Ember.Application.create();

E.g. to create a service:

(i) myApp.factory('weatherBureau', function() { return { message: "Today's weather" }})

(ii) Same issue here. Nothing to indicate this is a “service”. This is also another Angular neologism to learn. However, this term doesn’t usually appear in the code itself.

• Not DRY

3. Problems with the Docs

• Docs & Videos don’t show real-world syntax. Confusingly, there are two syntaxes in use: one, which is easy to understand, and which the docs use. And another, which production apps must use, which is far more difficult to understand.

• Academic, harder to read, and neologisms.

4. Framework is very minimal

• Need to manually build “Active Tab” navigation support.

• The “Dot” issue violates Principle of Least Surprise. http://www.egghead.io—DTx23w4z6Kc

“Lots of tutorials show this [potentially incorrect] way to code”.

“You’ve [inadvertently] destroyed the scope inheritance.”

• The design exposes implementation details & requires app devs to understand the implementation.

5. Other Gotcha’s

• Controllers don’t execute, and report no error, if the partial is just an empty file.

Examples

1. http://builtwith.angularjs.org/

(But this site is misnamed: it’s actually just tutorials and demos. Couldn’t find many/any production sites here)

2. DQ Cakes

Angular.js product chooser

• http://www.dqcakes.com

II. Ember.js

A. Pros

1. Built-in support for “Active Tab” navigation.

2. Strongly typed.

• The interpreter often gives helpful error output.

3. DRY.

4. In use by high-volume, well known apps

• Square

• Travis CI

• Zendesk

• Groupon

• Living Social

5. Framework

• Seems to avoid exposing implementation details. App devs work via the public API.

• All framework features are exposed via well named API methods.

Makes the code easy to read and understand.

• Uses HTTP caching to avoid redundant server requests It’s faster out of the box; caching built-in.

B. Cons

1. Gotcha’s

• Attributes fail silently if they’re not set up as “bound” or “unbound”

2. Framework

• The REST adapter is not considered ready for production use.

• Has gone under rapid development in the past few months. The API is now at a stable 1.0, but lots of docs & S.O. posts online are outdated.

• Code errors can sometimes result in no output and no error message.