Comparison of 4 popular JavaScript MV* frameworks (part 2)

In the first part of our JavaScript MV* framework comparison we introduced AngularJS, Ember, Backbone.js and the newcomer React, we showed some code examples and discussed their strengths and weaknesses. In this second part we are going to have a look at their market share, community support and estimated growth to help you make the right decision for your SPA.

Javascript frameworks

Market Study

The following table lists the 4 frameworks alongside the year they were introduced, their origin or enduring dependency, their main contributors and an overview of popular sites using them. It’s worth noting that every single one of these frameworks is run by (or mainly used by) one of the big players of the web:

  • Ember is used by Yahoo!
  • Angular powered by Google
  • Backbone is used to realise and is a part time project of Jeremy Ashkenas, currently employed by the New York Times
  • React is introduced and powered by Facebook

While the bare listing clearly illustrates project maturity it does not give any indication about general popularity. Stats generated by web crawlers are usually not very accurate when it comes to back-end frameworks, but in our case – where frameworks are client-side and, needless to say, detected by every web client – those stats can be pretty sound.

Comparing with and we received significantly different results. To display the results in a more convenient way we recalculated the total numbers to relative percentages. According to, React is used 74 times in the TOP 1 million websites while detected 18.582 usages in the entire web for the same framework as of this date. Still, it is possible to get a general idea of the market penetration of these Frameworks. All sources show Angular and Backbone being by far the most used frameworks – does not even list the other two since their marketshare is too small to bother. Interesting to note that Backbone.js is used more in the Top 1K sites than in the Top 1M sites according to

For you as a developer it might be more interesting to have a look at the community built around each Framework as it might reflect the amount and speed of support you will find for your upcoming projects. Therefore it is always a good idea to have a brief look at the few occasions where the community activity is shown. Since every project here is listed on GitHub a brief extraction of their stats should be helpful.

Angular was the winner of our part-1 comparison. It’s no surprise to see Angular again as one of the two most popular frameworks. While it almost reaches Backbone’s popularity it surpasses all competitors from the developer community site: Most stars, most contributors, most watchers, most issues (judge yourself if that’s good news), and a large amount of commits. When it comes to this kind of stats the number of git commits since the initial deployment plays a huge role: Ember, for instance, has the most commits. Impressive! But keep in mind: Ember had six more years to collect these commits compared to React. Taking things into perspective, React has more stars (already) than Ember although it is barely out of its childhood compared to the other almost ancient players.

Despite not being visualised here displays Angular in the best possible light as it counts more than the double amount of posts than Backbone and Ember together and over 65 times more than React!

We do realise this is a snapshot in time and might well be outdated by the time you read this post. Which leads to the following question: Which of those frameworks is worth investing in the (near) future? The question is especially relevant for React as its popular contributor Facebook is well-known for the ability to establish new technologies, be it software (Hadoop) or hardware (open compute). Are we close to witness a new star rising on the MV* Framework horizon?

Google Trends has always been a faithful companion to get an idea of how popular a topic is and, by looking at the development over time, how popular it might be in the future. While different search terms around the same topic might bring different results, you can still get a general idea for each framework. The fact that these terms appear around the same time the frameworks were introduced proves our point as being representative, at least to some extent.

What this graph for sure does is manifesting Angular as the most popular Framework. Moreover, fascinating to note, Backbone’s popularity seems to be stabilized or even decreasing over time. Same can be said by looking at Ember. Are they already over their peak and now losing momentum? While Backbone’s market penetration might already be too deep to just disappear from the market, fate seems uncertain for Ember.

No doubt, the most astonishing trend is React’s. While writing this blogpost, we had to rewrite this section three times in two months:

December 2014: Backbone and Ember are closely followed by React. =>Respect!
January 2015: React catching up and passing by its competitors. => Impressive!
February 2015 (partial data!): React’s popularity outruns Backbone and Ember by far and is the runner-up to Angular. => Speechless!

According to Google Trends, React has risen from zero to a fourth of Angulars popularity within 1.5 years without showing any kind of flattening of their popularity curve. If React keeps up its progress we might see a new rival of the popular Angular at least as far as the View component of the MV* frameworks is concerned.

Languages Platforms Tools

Comparison of 4 popular JavaScript MV* frameworks (part 1)

Finding a comprehensive comparison between any kind of JavaScript Frameworks, Libraries or Extensions is not hard these days. Especially when it comes to JavaScript MV* Frameworks, which are used to develop single-page applications (SPAs), and their notorious representatives, i.e. AngularJS, Ember, Backbone.js and newcomer React. A simple Google Search offers a plethora of technical comparisons to choose from.


Which are your favorite and worst frameworks? Take the survey, let us know and you can win awesome prizes and gear.

What they don’t usually mention, though, is the overall features those frameworks provide and how they compete for different use cases. Moreover, it is sometimes difficult, if not impossible, to find information on the origins of those Frameworks, i.e. how they have developed in time and, most importantly, how they will develop in the future.

This article is part 1 in a 2-part series, and will focus on comparing key features from some of the leading JavaScript MV*frameworks. In part 2, we’ll give you some insight on market-related qualities, followed by a conclusion.

Features Comparison

To get our comparison started, we will focus on the heavy-weight and most promising features you, as a developer, expect from a JavaScript MV* Framework.

Dynamic UI Binding

Dynamic UI Binding is not just passing data to our View or template at page load. You want to automatically have the View update when the data of the underlying Model changes. That being said, you may want to have a look at the following jsfiddle examples to get an idea of the huge improvement provided by dynamic UI binding over traditional server-side static data binding.


Ember uses Handlebars as the default templating engine. To update a value, which is bound to the UI, you have to use a specific setter method on your Model while Handlebars takes care of rendering your page. Additionally, Ember offers much more binding options, such as its capability to have your Model in either a one or a two-way binding mode between a View or even another Model.


In contrast with Ember’s approach, Angular.js allows you to use UI binding at plain object or even property level. At the end of every code execution, $scope.$apply() is run to check whether the value has changed and calls $scope.digest() to update your bindings. This may seem like a possible performance issue at first glance, but bear in mind that it allows you to update more than one binding simultaneously without requiring time-consuming DOM updates after each setter call. So the DOM rendering is triggered only once after you updated as many of the Model’s properties as you wish rather than being triggered after every single value change, like in Ember’s setter approach. Having all the magic happen in $scope.$digest() you don’t need to call your UI-Binding-Buddy yourself and even the $scope.apply() call is handled by Angular automatically (e.g. after events, controller init, http callback, etc).


One of React’s rich UI Features is the straightforward linking of states directly to the UI. Since the UI is thought of as the representation of different states of a React Component, you just have to manage your states with the magical #setState(state, callback) method. The state parameter is passed as an object and will be merged into the internal state reference of your React Component. Meanwhile, React takes care of all the updating and re-rendering of your interface using the render method. The callback parameter from setState is optional and can be registered so you are informed after the UI update.

Reusable Components

While all frameworks provide out-of-the-box functionality, you will inevitably end up with a lot of custom code. Assuming you are developing more than one applications, you would like to be able to reuse that code, right?

Ember is making use of a widget-based approach called Ember Components. It enables you to write your own ‘application-specific HTML tags’ using a Handlebars layout and the power of Ember’s backend infrastructure. Your custom element can be used in any Handlebars template you want. Keep in mind, though, that this is only possible at View level, while Controller level reuse is not supported by the Framework.

Similar to Ember, Angular.js provides the ability to create custom HTML tags. Reusable components in Angular are called “directives” and are significantly more powerful than Ember Components. In fact, you will be able to create your own semantic and reusable HTML syntax using those directives. On the other hand, you may also make use of Angular’s extend or mixin system like in Backbone.js and React.

Backbone.js and React:
The way Backbone.js and React solve reusable components is not new, yet it is very reliable. They both use the mixin system for code reuse. You may know this feature already from the dojo toolkit and might remember how powerful mixins can be. Both Backbone and React let you use mixins at view or even controller level, so that your components are not forced to be UI-related and may contain just some utilities or even complex program logic.


The simplest routing infrastructure a MV* JavaScript Framework can offer is mapping functions to URLs, similar to their server-side relatives (e.g. Grails, Spring, ASP.NET, CodeIgniter). For Single Page Applications (SPAs) a URL is whatever follows the hashtag (or might even be full path assuming HTML5 push-state is enabled). This routing functionality is essential for any self-respecting SPA.


The routing in Ember.js is quite intuitive, since you do not even need to provide a path for your route, as long as you follow the naming convention. You just provide the View and an optional Model to the route and there is no need for any kind of controller (as exhibited in the Fiddle above), unless you are planning to do some advanced stuff in your application.


In contrast to Ember’s convention-over-configuration routing mechanism, Angular.js requires a template and even a controller to its router configuration. You have to manage your template and controller manually – but you can do that almost without restrictions.


Similar to Angular.js you provide a View with a Template for your route. The actual replacement of the DOM is done manually by instantiating the View and updating the DOM in your container node with the rendered view template. At the end of your routing configuration you just have to tell Backbone to listen for URL changes with the command Backbone.history.start().

Pit Stop – Concluding the Feature Comparison

It is quite unfair to compare React with the likes of Ember, Backbone and Angular. First and foremost, React is new, while the latter are already established frameworks in the MV* universe. Secondly, React is not a framework, but rather a View engine – even though it competes extremely well in terms of features. In fact Facebook explains it better: “React is mostly used as the V in MVC”.

Let’s look again at our JavaScript MV* candidates.

Backbone doesn’t provide UI binding and does a really good job at reusable, components but loses some of its fanciness when it comes to Routing. Ember offers a slick routing mechanism, keeping things clean and simple by introducing naming conventions. Its UI Binding concept and use of Handlebars, which provides you with very nice benefits, is flawless. The only thing Ember lacks is the reuse of components at Controller level.

To conclude, Angular is our winner – so far. The approach of extending HTML with custom syntax, the easy-to-use data binding features combined with the power of mixins or extends and a clear routing mechanism makes Angular more than just a swiss JS-Knife. With its high abstraction level and a bunch of features it may be the choice for a full featured CRUD application – client sided.

Stay tuned to find out more about how our rivals compete in market penetration, community support, their estimated future usage and, of course, our final conclusion to help you back the right horse for your SPA.


In the meantime, tell us more about what you love or hate for each framework and you might win cool gear. Take the Developer Economics Survey.