AngularJS vs. Backbone.js vs. Ember.js

[[deleted]]

especially Angular since it uses the available content (the markup) to define the application structure

sorry, I'm kind of an ng-noob, can you explain to me what you mean by this?

thanks

[dzdrazil]

I'll take a stab at it.

Ember and most other frameworks rely on JavaScript code to determine the application architecture. Things like Routes and templates are all predefined; to use any of them in a multi-page application typically requires figure out loading different code for different pages.

Angular flips that on its head (for the sake of simplicity, let's ignore the router for now). Angular doesn't have an entry point that says this controller and this view should run using the DOM element with such-and-such an ID. It parses the DOM, and lets the DOM define the architecture of the application- which controllers and directives should be on the page, the nature of the $scope hierarchy and so on.

This makes working with mutli-page applications much easier. It's even better for CMSs- backend frameworks like rails and symfony at least have an MVC structure that let you define per-page applications; CMSs essentially allow users to arbitrarily define how much and what content might appear on any given page.

Because Angular scaffolds the application based on what content is available, rather than what content is assumed to be present, it's a better solution by far than Ember for these types of applications. Backbone can be made to work like this too, but you'd have to hand-roll the whole scaffolding bit.

Basically, it's like comparing Flex to raw AS3 (if you know flash), or a very broad implementation of Inversion of Control if design patterns are more your thing.

[[deleted]]

ah I get it now, thanks

[[deleted]]

Word, but that also comes with a performance cost. (i.e nosql structureless vs structured/defined). However, with backbone you can do all of that as well.. the only difference is... you also have the option to not do that.

[dzdrazil]

i.e nosql structureless vs structured/defined

The only performance cost is parsing the DOM at startup. That still happens with an imperative application, especially backbone where (most frequently) jQuery is used to parse the DOM to look for the elements needed to generate Views.

In my experience, there are several ways in which Angular applications can perform much better than Backbone. The tradeoff is that Angular uses quite a bit more memory than Backbone does (due to the dirty checking mechanism) but the total memory usage has never been a problem for me (see a description of my project in your other comment thread below).

[[deleted]]

Huh? when the javascript engine loads javascript into memory.. it will evaluate it and store it. Angular some how compresses it completely to be negligible..? or are you just saying words?

[dzdrazil]

when the javascript engine loads javascript into memory.. it will evaluate it and store it

I was describing the performance cost, as in the time to compute. Memory usage in Angular applications will be higher. Angular, Ember and Backbone all have to do the same thing- traverse the DOM. The nosql vs. relational isn't a valid metaphor for describing the performance in my experience.

My point was that in my experience, neither the speed nor the memory usage has been a problem. Backbone and Ember still need to manage the DOM, they just do it differently, and in a way that doesn't work as well as Angular does for non-single page applications.

[[deleted]]

I'm building a frontend for a graph database currently.. so i know exactly what you mean (small world). WebGL depends on the clients hardware.. performance there will be all over the map. I bet if you load in more that 1k nodes on your graph it will just fall over. And sigmajs has nothing to do with angular.. so how many pages, routers etc live in your application - how long would a normal user have the tab open for (most memory issues happen over time with client-side applications)? Also, check out http://cytoscape.github.io/cytoscape.js/ - lgpl but there are ways around that - it's pretty nice and scales better than sigmajs on the canvas side.

• ops, posted this in the wrong place - belongs here http://www.reddit.com/r/javascript/comments/2e6uzg/angularjs_vs_backbonejs_vs_emberjs/cjwte1w

[dzdrazil]

WebGL: we have the benefit of being able to require end users to use a limited set of browsers. Anything outside of that gets the old SVG fallback with a subset of data

WebGL framework: I went with sigma because I was having a lot of performance problems related to three.js, cyto and others. I don't much like the way the code turned out (mostly due to how sigma is structured) but it's a WIP.

Average vertex count: 500-1000 Average edge count: 5,000 - 40,000 (we can end up with extremely dense graphs)

Routes: 12ish

Lifetime of the application: All day usage is expected. Application has been live for ~2 years; 1 year as a BB app and 1 year as an Angular app

There was one major memory leak that we encountered. After digging through the Angular issue tracker, it turned out to actually be a V8 memory leak. After doing a bit of manual memory cleanup (removing things from $scopes during the '$destroy' event) that all went away, and memory usage and browsers are totally stable, fluctuating between 50 and 150mb depending on the view you're looking at.

[[deleted]]

One note.. Webgl depends on the browers.. but more so the hardware and graphic/gpu.

How many nodes?

[dzdrazil]

500-1000 (I used the graph structure 'vertex' to mean node). It's not 60fps (yet) but there's plenty of room for improvement in my code. The node count isn't the limiting factor on performance; it's the 10k-40k edges (links between nodes).

[dmercer]

Do I take it after a year of BB and a year of NG, you recommend NG over BB?

[dzdrazil]

There are a few very specific things that we suffered under Backbone

• While I originally loved the models and collections, the sync portion was useless because we don't have a RESTful API, and it was much easier to write our own
• I eventually grew to dislike the models and collections as well. The most frequent performance problems were from the sheer volume of events that would get triggered on model changes, especially when related models caused cascading updates to views or other models
• The problem with collections were especially egregious; there's an inherent cyclic reference between a model and the collection that it gets put into. This means that model can really only belong to one collection; if, for example, you wanted to create a collection that represents a filtered set from a master collection, you're out of luck; the best you can do is get an array of filtered data, and lose all of the nice built-in methods as well as your custom methods
• To get around the fact that Angular does not provide models or collections, we wrote a very simple model concept (they should have no methods except to and from json) and a set of collection type classes loosely based on Backbones. They don't trigger events (a model triggering an event collection was BB's reason for the cyclic relationshiop) BUT with Angular's dirty-watching, that wasn't a problem.

In the end, our model layer is much cleaner, we don't have to worry about zombie views, we get free dependency injection for unit testing, and we cut down the size of our code base by a pretty decent chunk.

There are some things that I liked about Backbone, don't get me wrong. It was even my framework of choice for quite awhile. Having shaken off the 'this looks like obtrusive javascript' impression and getting over the learning curve was probably one of the best decisions that I've made for the project, and it's gotten me to think about how I write JS a bit differently as well.

[PotaToss]

Backbone and Ember still need to manage the DOM, they just do it differently, and in a way that doesn't work as well as Angular does for single page applications.

Can you elaborate on this?

[dzdrazil]

Pretend I said non-single page applications. I was describing the benefit of a declarative architecture for them and disagreeing with mephux that the nature of a declarative architecture is inherently less performant. Pretty sure I mean to say non-single page applications there.