I am a web developer and I'm starting to develop a web application on a large scale, but I'm not sure what framework to use. I was thinking of Angular.js, but I also considered Backbone.js. For you, what would be the best framework? or at least have a comparison between the two to see the performance.
Anybody here claiming that one solution is faster or slower than other either doesn't know much about any of these libraries or frameworks (or perf testing in general) or is a liar.
Performance is a very tricky characteristic to measure because of so many variables that affect it. Just to name few:
but more importantly, what exactly do you mean by performance? performance is a very broad term that covers too many things, including:
The best way to answer your question is to create an application that is well representative of the application you are intending to build and implement it with the competing libraries/frameworks. Then write a quality benchark that will compare them head to head in a stable environment.
This is obviously a very laborious task and only someone with a lot at stake would undertake it.
There is however a different solution to this problem: understand the framework/library you are using and specifically:
As for the actual comparison between Backbone and AngularJS, you are comparing two very different solutions.
Backbone doesn't do any dom manipulation for you, so the speed of your app will mostly depend on how well can you do dom manipulation (is this your expertise?).
AngularJS does most of the dom manipulation for you and we have a ton of expertise in this area, so unless you are really good, you'll have a hard time matching us.
Secondly, backbone's model mutation observation is based on events, model wrappers and use of artificial getters and setters. Not only that this can be very inefficient due to lack of event coalescence (there might be a workaround for this in latest backbone versions), but the use of artificial getters and setters also interferes with the JIT compiler in your browser.
Misko wrote up a long post on how Angular does its magical model mutation observation. So I'm not going to repeat it here. But basically the performance of an AngularJS app is directly related to the number and complexity of bindings used in the current view of the application. With this in mind, you can easily predict Angular's performance. Even better is that with tools like AngularJS Batarang extension for Chrome, we allow you to easily instrument your application and understand which bindings on the page are slow and this allows you to focus on fixing the parts of your code that really matter.
I'm going to conclude by saying that no library or framework will be the best solution for all of your use cases, so you should learn more about the tools you build your apps with and when it really matters, decide which one is the best for a given use case. My bet is that for most of the apps you are going to write, performance is not going to noticeably change if you switch framework or library. So I would put more weight on other factors like productivity, easy of use, testability, community and documentation before I would worry about performance.
And the very last thing: benchmarks are often misleading, but check out these ones and take them with a grain of salt.
Backbone + Ember: http://jsfiddle.net/jashkenas/CGSd5/AngularJS: http://jsfiddle.net/mhevery/vYknU/23/You can make backbone faster easier if you strip it down to the minimum. I removed the dependency underscore or lodash from backbone making it way lighter and modified there events to use bean and pretty much enderjs libs minus morpheus I swapped it out for tween light.I will tell you this its wayyyyy faster than angular. Pages load in milliseconds vs seconds. The thing with angular is MVVM design pattern is slow because you have a ton of direct DOM interaction. Javascript is fast with out the dom. So use the DOM as little as possible and thats impossible with MVVM. Its best to have your logic separated out with very small fast and light weight DOM references, the use of pointers when you can is always a better option. I have used and reviewed each framework line bye line. Stock you will get about the same performance modified is a different story. Backbone stock is bloated and most of the template engines are slow. So use dotjs for templates, use ender and not jquery, use bean for custom events. Angular has a extremely slow template engine thats baked in and it heavy DOM usage makes it even slower... Not to mention all the declarative bindings mixed into the markup is hard to maintain and read. I have done jsperfs on just about every framework and library known to JS I build frameworks for a living. Yes there are allot of variables involved but if done right I would choose backbone any day of the week. MVVM will die out... MVP is where its at when it comes to front end frameworks.
There is another performance comparison between Angular, Ember, and KO here:
http://jsperf.com/angular-vs-knockout-vs-ember/2
Clear winner in this case is Angular, but as said earlier, performance tests are rarely straightforward or fair.
have a look at knockoutjs too. Look at the video to get an understanding of how MVVM works in javascript world.
I have used it for few projects and so far very happy about it. I see it being a part of new ASP.NET MVC 4 (SPA), and backed by Microsoft.
not necessarily an answer but another resource link w/ a generic pros/cons for each framework. I think what Igor Minar said is really important, focus on what is easy to learn, easy to implement & doesn't get in the way of your productivity over obsessing about performance.
http://codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed/
For what it's worth, Angular JS and Ember JS appeal to me primarily because of their use of binding is very much like Flex's binding mechanism (at a high level) AND it leaves the HTML mostly decoupled from the controller/model logic.
Tangential, but relevant information on top of what @igor-minar already said in http://stackoverflow.com/a/11498872/850996
There have been several examples where I ran into performance issues that are related to what is discussed here. And these examples did not involve any frameworks (beyond jQuery core to access the DOM).
We had several UI components that we were building, styling and rendering to a DOM tree that consisted of a large number of elements. Javascript and the DOM has the inherent performance characteristic that reading DOM attributes blocks on any pending updates to the DOM [1]. For example, if you change 5 CSS attributes of one element, which the browser may queue up and execute later, and then try to read one CSS attribute, it needs to complete the pending DOM writes before it can give you back the one attribute you just read. For instance, simple scenarios like reading an element.offsetHeight can be expensive because it requires the DOM to complete pending updates and then measure and layout the elements before it can determine the height of the particular element.
We had a lot of code that was written without consideration for this basic characteristic. Fixing it required optimizing it in such a way to minimize the blocking DOM reads. Also, building DOM subtrees offline before attaching them to the document helped in some cases.
With all of these tweaks, we still couldn't get the kind of performance we needed for scenarios like large lists (e.g. a scrolling list view that could have several thousand list items, each made of multiple DOM elements to get the desired visual style). Here, we had to change the code to virtualize the list and only render the sub-set of DOM elements that were actually visible in the list [2].
The main comment I wanted to add to this topic is to say that the framework you choose won't solve all the performance issues you are likely to come across in your application. So, as pointed out by other responses, knowing your how your chosen framework implements it's magic and choosing a framework that allows you to see into what it's doing (via performance instrumentation) will pay off in the end. And the framework is not a substitute for understanding core characteristics of modern browser implementations. The high performance javascript book that was written many years ago is still a great resource. And learn to use the many profiling tools available so you quickly narrow in on where the bottlenecks are in your application.
best,
--
References:
[1]. http://shop.oreilly.com/product/9780596802806.do Read chapter 3 on DOM scripting
[2]. https://github.com/shyam-habarakada/js-virtual-list-view
Backbone wins http://jsperf.com/angular-vs-ember-vs-backbone-vs-canjs-vs-knockout/24
Angular wins http://jsperf.com/angular-vs-ember-vs-backbone-vs-canjs-vs-knockout/23
As you can see those code the performance is very tricky thing and totally depends of a developer. But BB has a good potential for performance improvement
Not benchmarked Backbone and Angular. Still sharing my real experience I had with both on same app - a medium sized application, with SPA. First we used Backbone, and completed whole lot of features. More productive and clear code than direct writing in JS/jQuery. After an year, we moved to angularjs. Rewrote everything in angular, now we have around 140 directives, controllers and services mixed. Code quality and productivity much better. But its not as fast as same app in backbone. Now just watching for object.Observe to be released in chrome for perf boost. Angularjs team must be watching performance corner.
Before you choose a framework, you should really read well about where it fits. If your json response is heavy with too many attrs, and too many such objects will be alive at any time, angular will be slow. There Backbone wins, but again, you need to manage a lot of things, code-quality and patterns yourself with Backbone.