Updated notes on Ember and Angular


Ember vs Angular

I’ve been studying the two for a while and I thought my notes might be useful for others. If you spot errors or have additions that might help others decide, please leave a comment and I’ll update the text. Thanks, enjoy!

My take overall

It would be lame not to say where I landed after all this reading, so here it is: I like Angular’s declarative easy-to-read markup (“it’s just extended HTML”), its use of dependency injection everywhere, the simplicity of its direct action on the DOM, and its highly flexible directives for making components. It seems more inherently modular and flexible to me, less prescriptive than Ember but with enough power for pretty much any application. That said, Ember promises to be tightly integrated with Rails (like Java-Granite?) so for a committed Rails shop Ember may well be the better choice (but then what happens if you switch server technologies as you grow?).

My rule of thumb is that Ember is basically automating well-thought-out Backbone application construction, very much as Rails does for ruby server app construction. It’s good for those who think in terms of creating complex web sites.

On the other hand, Angular extends HTML itself, creating new component sets that can be used as quickly and easily as the “<table>” tag. Angular is good for those who think in terms of creating complex applications in more traditional software.

Things that worry me about Ember

  • No one seems to know how asynchronous testing should be done
  • Ember Data is very much a work in progress
  • Though they’re simplifying it to only work with conventional APIs, so it could stabilize fairly quickly, performance characteristics for it are unknown since it’s been changing so much, and therefore the same is true for how to optimize it
  • A nice set of links about Ember’s recent growing pains, especially the links from the Ember team
  • Errplane had a rough time with Ember, mostly because of Ember Data
  • Does its structure tempt one to make monolithic client apps rather than combining small apps to make a bigger one?

Things that are exciting about Ember

  • Yehuda Katz
  • Familiar concepts for Rails devs
  • Notes on a happy migration to Ember from a Rails app

Things that worry me about Angular

  • Do directives make markup harder to read? (I think actually they make it easier to see the intent of the software, especially for junior devs)
  • Directives have some complexity to them, which may limit their use (On the other hand, they’re really flexible and could handle making complex components.)
  • Why are there so few public libraries of directives if they’re so handy? Angular 1.x has been out for a year. (Possibly it’s that most users are enterprises that are less likely to share code)
  • Complaints from a blog: Not every framework is perfect, and you’ll find scenarios where Angular is not a good fit. There are certainly scenarios when change detection will be milliseconds slower than observing changes. It’s not obvious how to track animations or respond to focus events. Form validation is subpar. Angular is not minimalistic and comes with strong opinions. Writing lower level components, like custom directives, requires some focused effort. You also need some understanding of prototypal inheritance to avoid getting into trouble in more advanced scenarios.
  • How easy is it to use widgets from other libraries, like Bootstrap? The issue is the bindings, you need a way to pass values into the widgets. I think it might be easy because it’s just HTML. Put the widget in, have the bindings and use it. But I need to test it.
  • Something to be careful about with Angular: Unfortunately it is way too easy to add slow comparison into angular, so it is easy to build slow apps when you don’t know what you are doing. But we hope to have an answer by providing an instrumentation module, which would show you which are the slow comparisons.

Things that are exciting about Angular

  • It makes HTML markup declarative, which is nicer and more flexible than the more standard iterative approaches
  • It uses dependency injection everywhere, so both testing and programming in the functional style are easier
  • Google uses it on major production sites
  • Google funds its development (though Tom Dale asserts that an order of magnitude more are working on Ember)
  • Directives should make sharing assets and functionality trivial across projects; you just need to depend on a company library of new HTML tags
  • Using Bower to manage your directives
  • Its end-to-end testing system is very simple and cool
  • Performance looks good if this is at all to be believed (I think it’s really of very limited value as a measure)

My summary of the arguments I’ve seen

Ember advocate says: Ember integrates more easily with widget libraries like Bootstrap
Angular counter: the wrappers are pretty easy to make (where’s that ref?)
Counter counter: The way AngularJS manages the DOM is somewhat at odds with the way people are used to building CSS and “widgets”. AngularJS does a lot of DOM *re-structuring* whereas a lot of widgets do a lot DOM *hiding*. This caused a number of problems with things like Twitter Bootstrap which has a lot of “content” DIVs with “active” classes on them to indicate show/hide. The problem was, we have AngularJS actually ripping those things out of the DOM with ngSwitch so the concept of “active” becomes irrelevant at the CSS level and only relevant at the DOM level.

Ember advocate says: Ember will integrate seamlessly with Rails
Angular counter: true, Ember will always be tighter with Rails, for good and bad

Ember advocate says: Ember’s templates are just strings and so can be compiled on the server, improving app startup speed
Angular counter: those templates are separate from DOM so updates have to be inserted into the DOM using innerHTML, which can clobber ongoing user input; using the DOM directly simplifies cases like that, improves consistency and is worth the insignificant startup speed cost

Tom Dale arguments for why Ember is better, with Angular counter-arguments

Ember advocate says: Ember is based on Cocoa, Backbone and jQuery; it uses the best of all to make writing apps in the browser that feel native
Angular counter:Ember is bolting on non-web stuff from Rails and Cocoa. Angular improves HTML, the actual core of the browser experience

Ember advocate says: Angular is a research project; Ember talks about MVC whereas Angular talks about scopes, directives and transclusions
Angular counter: this seems pejorative and misleading. Angular is used by big players like Sony and DoubleClick (Double Click talked about their 100k SLOC javascript Angular app here, though DC is Google property) and appears to have a strong community. It’s not the Rails community, though, like Ember has. Angular talks about MVC but also talks about “scopes, directives and transclusions” because they’re necessary to solve problems that come up when you add new HTML tags. No one has to do that, it’s a power-user feature

Ember advocate says: Ember’s template syntax (Handlebars) is nicer
Angular counter: Not really, it’s more complicated since you’re not just working with DOM but instead bolting something onto it

Ember advocate says: Ember should be faster starting up because Angular has to compile and link the whole DOM whereas Handlebars templates can be compiled server-side
Angular counter: No one seems to comment on slow startup being a noticeable problem

Ember advocate says:Ember should be faster at model-view update cycles because it has listeners on each item rather than using simple dirty-checking like Angular. Ember achieves O(1) performance from data bindings whereas dirty-checking makes Angular O(n), which is why Misko Hevery recommends no more than 2000 bindings in a current view; Ember doesn’t need to limit you like that.
Angular note: Angular dirty-checks everything under the $scope that was used for a call or binding update, not the entire page (unless you call $rootScope.$apply()). You can have 40,000 elements on your page, split up into 20 groups, and if you have each group in a separate scope then angular will dirty-check at most 2,000 elements at a time.
Angular counter: dirty-checking simplifies developer effort and markup by not requiring endless “get() and set()” entries; it also is fast enough for practical purposes now and will soon be blazing fast when Object.observe lands in Chrome and FF (it’s landed in Chrome Canary and is likely to be in AngularJS 2.0, so data bindings will go from O(n) to O(1))
Ember counter: “get() and set() won’t be needed when ES6 proxies land

Ember advocate says: Ember has more people working on it, meaning more man-hours of development: “By making this a truly community project, instead of a “by Google” project, I believe we get an order of magnitude more man-hours contributed to it.”
Angular counter: Angular has a thriving community that contributes, it’s not just Google (ref?)

Ember advocate says: If you ever want to render your app on the server (for indexing by Google crawlers or to make first loads display faster), Angular requires you to boot an entire browser environment like PhantomJS, which is resource-intensive. Handlebars is 100% JavaScript strings so all you need is something like node.js or Rhino.
Angular counter: why would that be a significant problem?

Ember advocate says: String templates are easy to divide up and load lazily, if your app starts getting large.
Angular counter: dividing up the HTML seems just as easy. For lazy loading, just use different Angular apps for different pages, right?

Ember advocate says: Angular allows you to embed arbitrary expressions that live update, which means that Angular has to recompute them every time an involved variable changes, which could be slow
Angular counter: this is a worthwhile tradeoff. Ember makes you specify your dependencies, which is a hassle. Having the computed properties be easy for developers to write makes life better and, used carefully, doesn’t have to slow down the app noticeably

Ember advocate says: Ember is much better positioned to take advantage of the performance benefits of ECMAScript 6 features like Object.observes because Angular has to use a custom parser
Angular counter: the opposite is true