Site Meter

Rich JavaScript Applications – the Seven Frameworks (Throne of JS, 2012)

A week ago was the Throne of JS conference in Toronto, perhaps the most interesting and different conference I’ve been to for a while. Quoting its website:

It’s no longer good enough to build web apps around full page loads and then “progressively enhance” them to behave more dynamically. Building apps which are fast, responsive and modern require you to completely rethink your approach.

The premise was to take the seven top JavaScript frameworks/libraries for single-page and rich JavaScript applications — AngularJS, Backbone, Batman, CanJS, Ember, Meteor, Knockout, Spine — get the creators of all of them in one location, and compare the technologies head to head.*

Disclaimer: I was there to represent Knockout, so obviously I’m not neutral. In this post my focus is on what the creators said about the scope and philosophy of their technologies, and not so much on whether I agree or disagree.

* Yes, I know that’s eight frameworks, not seven. This part was never fully explained…

TL;DR Executive Summary

  • For many web developers, it’s now taken for granted that such client-side frameworks are the way to build rich web apps. If you’re not using one, you’re either not building an application, or you’re just missing out.
  • There’s lots of consensus among the main frameworks about how to do it (Model-View-* architecture, declarative bindings, etc. — details below), so to some extent you get similar benefits whichever you choose.
  • Some major philosophical differences remain, especially the big split between frameworks and libraries. Your choice will deeply influence your architecture.
  • The conference itself was stylish and upbeat, with a lot of socialising and conversations across different technology groups. I’d like to see more like this.

Technologies: Agreement and Disagreement

As each SPA technology was presented, some fairly clear patterns of similarity and difference emerged.

Agreement: Progressive enhancement isn’t for building real apps.

All the technologies follow from the view that serious JavaScript applications require proper data models and ability to do client-side rendering, not just server rendering plus some Ajax and jQuery code.

Quote from Jeremy Ashkenas, the Backbone creator: “At this point, saying ‘single-page application’ is like saying ‘horseless carriage’” (i.e., it’s not even a novelty any more).

Agreement: Model-View-Whatever.

All the technologies made use of model-view separation. Some specifically talked about MVC, some about MVVM, and some specifically refused to define the third piece (just saying it’s models, views, and some kind of application thing that makes them work together). The net result in each case was similar.

Agreement: Data binding is good.

All except Backbone and Spine have a built-in notion of declarative data binding in their views (Backbone instead has a “bring your own view technology” design).

Agreement: IE 6 is dead already.

In a panel discussion, most framework creators said their IE support focus was limited to version 7+ (in fact, Ember and AngularJS only go for IE8, and Batman requires an ES5 shim to run on IE older than v9). This is the way of things to come: even jQuery 2 is set to drop support for IE older than v9.

The only stalwarts here appear to be Backbone and Knockout which support IE6+ (I don’t know about Backbone’s internals, but for KO this means transparently working around a lot of crazy edge-case IE6/7 rendering and eventing weirdnesses).

Agreement: Licensing and source control.

Every single one is MIT licensed and hosted on GitHub.

Disagreement: Libraries vs frameworks.

This is the biggest split right now. You could group them as follows:

Libraries Frameworks

Backbone (9552)

Knockout (2357)

Spine (2017)

CanJS (321)

Ember (3993)

AngularJS (2925)

Batman (958)

Meteor (4172) — unusual, see later

Numbers in brackets are a point-in-time snapshot of the number of GitHub watchers, as a crude indicator of relative influence.

What does this mean?

  • Libraries slot into your existing architecture and add specific functionality
  • Frameworks give you an architecture (file structure, etc.) that you are meant to follow and, if you do, are intended to handle all common requirements

By far the most passionate advocate of the framework model is Ember, whose creator Yehuda Katz is formerly of the Rails and SproutCore projects (similar philosophy). His argument was that anything less is just not ambitious enough and isn’t seriously advancing the state of the art. The counter-argument is that libraries are more focused, and hence can be easier to learn, adopt, customize, and help minimise project risk because your architecture isn’t so deeply tied to a specific external project. Based on my conversations, I’d say the audience was split and supported both sides of this debate.

Note that AngularJS is arguably somewhere in between library and framework: it doesn’t require a particular layout of files at development time (library-like), but at runtime it provides an “app lifecycle” that you fit your code into (framework-like). I’m listing it as a framework because that’s the terminology the AngularJS team prefers.

Disagreement: What’s flexible, what’s integrated.

Each technology has different levels of prescriptiveness:


URL routing

Data storage


Built-in DOM-based templates (mandatory)

Built-in (optional)

Built-in system (optional)


Choose your own (most used handlebars.js, a string-based template library)

Built-in (optional)

Built-in (overridable)


Built-in DOM-based templates (mandatory)

Built-in (mandatory)

Built-in system (mandatory)


Built-in string-based templates (mandatory)

Built in (optional)

Built in (optional)


Built-in string-based templates (mandatory)

Built-in (mandatory)

Built-in (overridable)


Built-in DOM-based templates (optional, can do string-based too)

Choose your own (most use sammy.js or history.js)

Choose your own (e.g., knockout.mapping or just $.ajax)


Built-in string-based templates (mandatory)

Built-in (mandatory?)

Built-in (Mongo, mandatory)


Choose your own string-based templates

Built-in (optional)

Built-in (optional?)

As expected, whenever a library leaves a decision open, they argue it is better overall to guarantee composablity with arbitrary 3rd-party libraries. And the obvious counter-argument is that integration can be more seamless if built-in. Again, based on my conversations, the audience was split and opinions went in all directions — usually based on how much other technology stack an individual was wedded to.

Quote from Tom Dale of Ember: “We do a lot of magic, but it’s good magic, which means it decomposes into sane primitives.

Disagreement: String-based vs DOM-based templates

(As shown in the above table.) For string-based templates, almost everyone used Handlebars.js as the template engine, which seems to dominate this space, though CanJS used EJS. Arguments in favour of string-based templates include “it’s faster” (debatable) and “theoretically, the server can render them too” (also debatable, as that’s only true if you can actually run all of your model code on the server, and nobody actually does that in practice).

DOM-based templates means doing control flow (each, if, etc.) purely via bindings in your actual markup and not relying on any external templating library. Argument include “it’s faster” (debatable) and “the code is easier to read and write, because there’s no weird chasm between markup and templates, and it’s obvious how CSS will interact with it“.

In my view, the strongest argument here came from the AngularJS guys who stated that in the near future, they expect DOM-based templating will be native in browsers, so we’ll best prepare ourselves for the future by adopting it now. AngularJS is from Google, so they are already working on this with Chromium and standards bodies.

Disagreement: Levels of server-agnosticism

Batman and Meteor express explicit demands on the server: Batman is designed for Rails, and Meteor is its own server. Most others have a goal of being indifferent to what’s on your server, but in practice the architecture, conventions, and some tooling in Ember leans towards Rails developers. Ember absolutely works on other server technologies too, though today it takes a little more manual setup.

The technologies — quick overview

Here’s a rundown of the basic details of each technology covered:

  • Who: Jeremy Ashkenas and DocumentCloud
  • What:
    • Model-View in JavaScript, MIT licensed
    • Most minimal of all the libraries — only one file, 800 lines of code!
    • Extremely tightly-scoped functionality — just provides REST-persistable models with simple routing and callbacks so you know when to render views (you supply your own view-rendering mechanism).
    • The best-known of them all, with the most production deployments on big-name sites (perhaps easy to adopt because it’s so minimal)
  • Why:
    • It’s so small, you can read and understand all of the source before you use it.
    • No impact on your server architecture or file layout. Can work in a small section of your page — doesn’t need to control whole page.
    • Jeremy seems to exist in a kind of zen state of calm, reasonable opinions about everything. He was like the grown up, supervising all the arguing kids.
  • Where: GitHub and own site
  • When: In production for nearly 2 years now
  • Who: The Meteor development group, who just raised $11.2 Million so they can do this full-time
  • What:
    • Crazy amazing framework from the future, barely reminiscent of anything you’ve ever seen (except perhaps Derby)
    • Bridges a server-side runtime (on Node+Mongo) with a client-side one, so your code appears to run on both, including the database. WebSockets syncs between all client(s) and server.
    • Does “live deployments” every time you edit your code – client-side runtimes are updated on the fly without losing their state
    • Makes more sense if you watch the video
    • Like everyone I spoke to at the event, I really want this to succeed — web development needs something this radical to move forwards
  • Why: You’ve had enough of conventional web development and now want to live on the bleeding edge.
  • Where: GitHub and own site
  • When: It’s still early days; I don’t know if there are any production Meteor sites yet except built by the core team. They’re totally serious about doing this, though.
  • Who: Yehuda Katz (formerly of jQuery and Rails), the Ember team, and Yehuda’s company Tilde
  • What:
    • Everything you need to build an “ambitious web application”, MIT license
    • Biggest framework of them all in both functionality and code size
    • Lots of thought has gone into how you can decompose your page into a hierarchy of controls, and how this ties in with a statemachine-powered hierarchical routing system
    • Very sophisticated data access library (Ember.Data) currently in development
    • Intended to control your whole page at runtime, so not suitable for use in small “islands of richness” on a wider page
    • Pretty heavily opinionated about files, URLs, etc., but everything is overridable if you know how
    • Design inspired by Rails and Cocoa
    • Tooling: They supply project templates for Rails (but you can use other server platforms if you write the code manually)
  • Why: Common problems should have common solutions — Ember makes all the common solutions so you only have to think about what’s unique to your own application
  • Where: GitHub and own site
  • When: Not yet at 1.0, but aiming for it soon. API will solidify then.
  • Who: Developed by Google; used internally by them and MIT licensed.
  • What:
    • Model-View-Whatever in JavaScript, MIT licensed
    • DOM-based templating with observability, declarative bindings, and an almost-MVVM code style (they say Model-View-Whatever)
    • Basic URL routing and data persistence built in
    • Tooling: they ship a Chrome debugger plugin that lets you explore your models while debugging, and a plugin for the Jasmine testing framework.
  • Why:
    • Conceptually, they say it’s a polyfill between what browsers can do today and what they will do natively in a few years (declarative binding and observability), so we should start coding this way right now
    • No impact on your server architecture or file layout. Can work in a small section of your page — doesn’t need to control whole page.
  • Where: GitHub and own site
  • When: In production now (has been at Google for a while)
  • Who: The Knockout team and community (currently three on the core team, including me)
  • What:
    • Model-View-ViewModel (MVVM) in JavaScript, MIT licensed
    • Tightly focused on rich UIs: DOM-based templates with declarative bindings, and observable models with automatic dependency detection
    • Not opinionated about URL routing or data access — combines with arbitrary third-party libraries (e.g., Sammy.js for routing and plain ajax for storage)
    • Big focus on approachability, with extensive documentation and interactive examples
  • Why:
    • Does one thing well (UI), right back to IE 6
    • No impact on your server architecture or file layout. Can work in a small section of your page — doesn’t need to control whole page.
  • Where: GitHub and own site
  • When: In production for nearly 2 years now
  • Who: Alex MacCaw
  • What:
    • MVC in JavaScript, MIT license
    • Worked example originally written for an O’Reilly book grew into an actual OSS project
    • Is a kind of modified clone of Backbone (hence the name)
  • Why: You like Backbone, but want a few things to be different.
  • Where: GitHub and own site
  • When: It’s past v1.0.0 now
  • Who: the team at Shopify (an eCommerce platform company)
  • What:
    • MVC in JavaScript, almost exclusively for Rails+CoffeeScript developers, MIT licensed
    • Most opinionated of them all. You must follow their conventions (e.g., for file layout and URLs) or, as they say in their presentation,”go use another framework
    • Full-stack framework with pretty rich models, views, and controllers and routing. And observability mechanism of course.
    • DOM-based templating.
  • Why: If you use Rails and CoffeeScript, you’ll be right at home
  • Where: GitHub and own site
  • When: Currently at 0.9. Aiming for 1.0 in coming months.
  • Who: the team at Bitovi (a JavaScript consulting/training company)
  • What:
    • MVC in JavaScript, MIT licensed
    • REST-persistable models, basic routing, string-based templating
    • Not widely known (I hadn’t heard of it before last week), though is actually a reboot of the older JavaScriptMVC project
  • Why: Aims to be the best of all worlds by delivering features similar to the above libraries while also being small
  • Where: GitHub and own site
  • When: Past 1.0 already


If you’re trying to make sense of which of these is a good starting point for your project, I’d suggest two questions areas to consider:

  • Scope. How much do you want a framework or library to do for you? Are you starting from blank and want a complete pre-prepared architecture to guide you from beginning to end? Or do you prefer to pick your own combinations of patterns and libraries? Either choice has value and is right for different projects and teams.
  • Design aesthetic. Have you actually looked at code and tried building something small with each of your candidates? Do you like doing it? Don’t choose based on descriptions or feature lists alone: they’re relevant but limited. Ignoring your own subjective coding experience would be like picking a novel based on the number of chapters, or a spouse based on their resume/CV.

Despite the differences, I’d argue there is one killer feature all the above technologies share: the idea of Model/View separation. This is a classic design pattern that predates the web itself by about 20 years. If you’re building even the most basic kind of web application UI, you’ll almost certainly benefit from applying this on the client.

104 Responses to Rich JavaScript Applications – the Seven Frameworks (Throne of JS, 2012)

  1. What about the recent Twitter sorry-but-server-rendering-is-faster fiasco? What’s you opinion on that?

    BTW, great post, thanks!

  2. Really interesting stuff. Was there any discussion about SEO and Accessibility with client-side rendering? Any consensus on how developers are dealing with these issues?

  3. Jaap

    How whould you position Kendo from Telerik between this list of libraries? Or is it completely out of band?

  4. Nice article! Interesting to see such an overview of all the different frameworks.

    The only problem I’m currently facing with this is that we work for government and other companies who need to adhere to all kinds of accessibility rules.

    So we first build our site and then enhance it with AJAX/JavaScript that’s not required. Are there any recommendation how to deal with this? Can browsers/frameworks help with making JavaScript more accessible?

  5. My personal website is built with meteor ( I wouldn’t use it for a large website without the database authentication. It seems it’s implemented on a different branch on github.

  6. Jonathan

    This is all great in theory, but the reality is client-side rendering is still too slow for anything but simple scenarios. You get anything very complicated going and it all grinds to a halt.

    We tried to do client-side with Knockout on our last application, but with the amount of data we needed it took seconds just to parse the JSON, and then Knockout has to parse and render the templates. We were seeing 10-20 seconds just to get the page to initialize (on top of the 2-3 seconds for the server to go to the DB and send it back in JSON).

    We switched to server-side rendering then do client-side operations on the DOM using a light-weight engine we wrote that uses the DOM as the data storage, instead of doubling everything up (data in both JS objects + rendered DOM). Now page parse times are in the milliseconds the way you would expect (browsers have gotten really good at parsing HTML over the years).

  7. TJ Holowaychuk

    IMO they’re all at the wrong scope, backbone is the closest as far as size goes, but “good” separation is inherently boring I suppose.

  8. Great overview, thanks!

    Myself, I’m using Backbone for quite a while and recently started to use Chaplin – it builds on top of Backbone and together with Brunch provides/mandates file layouts and makes some nice architectural decisions. Quite happy with this setup so far.

  9. Steve

    Eduardo: Twitter’s much more of a “site” than an “application”, so these kinds of technologies aren’t ideal for it.

    Carl and Wouter de Kort: There was some brief discussion about accessibility. ARIA is how it’s meant to work.

    Jonathan: Those figures are crazy. I’m not sure what you were doing to get those kinds of processing time, but seriously that’s not normal. Did you post in the Knockout discussion group to see if someone could help you see what was going on?

    TJ: Yep, that’s the essence of the frameworks vs libraries debate :)

  10. ctrlShiftBryan

    ember.js is IE8 only? “Ember and Angular only go for IE8″ What do u mean by this?

    Should I avoid it for a site the needs to fully support IE7?

  11. Jonathan

    Steve: It was an order placement application that needed to handle up to 100 line items, with each order line item potentially being split across any number of shipments. Each shipment then had its own specific list of warehouses, each with different availability of the material including in-stock and in-transit quantities. Pricing was dynamically updated as quantities were adjusted via calls to a JSON service, and a shipment summary had to be updated as the user modified the order.

    It seemed like a perfect candidate for a client-side MVVM framework such as Knockout, but performance just wasn’t acceptable. Doing server-side rendering with custom JS on the client to make the updates as the user modified quantities, split shipments, and selected warehouses turned out to work much better, but was also a much bigger hassle to write.

    Also keep in mind that we had to support all the way back to IE7. If everything was in Chrome we probably would have been okay…

  12. Geeth

    Nice article. What happened to dojo? It advocated lot of these principles years back. Was it ahead of time?

  13. For me one of the factors for selection is design-ability. Sure you call that out Steve with “string” versus “DOM” templating (Angular can do String too by the way). But I think there’s a missing facet – loading the page without the import of the lib/framework yields very different results for Knockout / AngularJS / Batman / CanJS than it does for the others. What you get is the app loaded w/o data and with a single row where applicable (instead of multiple rows as if data were bound), and also alternates of the if/else nodes concurrently visible. Eg..


  14. mark

    One of the best frameworks is missing Enyo. We’re moving away from Backbone to Enyo. We’ve built several Backbone sites and it’s too low level and I don’t want my team building frameworks anymore.

  15. matt

    Well yeah IE7′s JS engine is a dog, of course you aren’t going to get good performance from a client-intense app.

    Current versions of Firefox, Safari, and Chrome all do fine with an intense load of JSON parsing and client rendering.

  16. Chris Gardner

    Thoughts on Maria? Haven’t used this, but haven’t heard about it recently.

  17. “Yes, I know that’s eight frameworks, not seven. This part was never fully explained…”

    If you’re truly not sure why they’re saying “seven,” it’s probably a reference to the Game of Thrones books/show (the seven kingdoms), which makes some sense since the conference is called Throne of JS. It’s a stretch, but that’s most likely why it’s named that way.

  18. Hi Steven,

    few corrections:

    1/ AngularJS is definitely more of a framework than a library. It’s very lightweight, but by defining an app life cycle it fits the definition of a framework better.

    2/ According to Github AngularJS is watched by 3122 people, which is ~7% more than what you stated.

    3/ It’s AngularJS rather than Angular

    4/ At the conference Yehuda claimed that Ember works on IE6 because jQuery runs on IE6 and they depend on jQuery. But he said that they don’t test against it, so I think it’s BS.

  19. Oh yeah.. and thanks for the post! Very nice summary!

  20. Steve

    ctrlShiftBryan – If you want a definitive answer about Ember and IE7, it’s best to ask the Ember team directly. At the conference Yehuda mentioned something about not explicitly testing for IE6/7 support, but it wasn’t 100% clear to me at least.

    Paul – If you want to avoid a possible flash of unrendered content, you can use CSS to hide the bulk of your UI initially and then make the view rendering process show it (in KO’s case, via a binding). If you prefer to prerender some content on the server that then gets replaced during client-side rendering, you can do that in KO’s case by referencing named templates (either DOM-based or string, doesn’t matter) – I’m sure it’s possible to do something similar with AngularJS too.

    Igor -
    1/ OK, thanks for the correction. I’ve updated the post.
    2/ I wrote this post last week on the journey home, so the figures are a point-in-time snapshot from then. Naturally I won’t be continually updating them :)
    3/ Thanks – updated
    4/ Yeah, I was a little confused by that too. The conversation seemed inconsistent, but in my notes I recorded the point that they don’t test IE6/7 (and v8 support was unclear). Knowing how many insane quirks KO has to solve in each different older version of IE, I wouldn’t expect solid IE6/7 support to happen by chance alone! Perhaps old-IE support is something Ember could add later if there’s demand for it.

    Great to meet you last week BTW!

  21. Rick

    Jonathan – you’re probably doing it wrong if its too slow – it is possible to build complex apps on the client! Dont give up.

  22. vc Best by miles.

  23. My organization just deployed a ASP.NET MVC3 app that works restfuly with content negotiation that uses Knockout for all UI presentation.

    I don’t really buy into the value of pure single page applications, there is too much little separation so much complexity to manage in the browser. However I do feel the concept has merit, all of our pages behave as single page applications for the same resource and every resource is a different page. This allows us to not worry about managing templates as they’re all inherently the Razor view.

    We also directly return our MVC viewmodel inherently in the page so this eliminates needing to issue a separate request to the server to get the data to initialize the page which dramatically reduces the time for the UI to be fully ready.

    And the backend is RavenDB so we get to work directly with our rich data models partitioned logically as opposed partitioned batshit crazy the way rich models get partitioned in RDBMS and ORMs across many tables.

  24. excelent information!

    What do you thing about the new characteristics of js?

  25. lol, after I read about Meteor and went and researched it, I didn’t bother reading the rest.

  26. Hi Steve,

    Thanks for the great summary and also for being part of Throne.

    “Throne of JS” and “Seven Frameworks” are intended as allusions to Kurosawa’s “Throne of Blood” and “Seven Samurai”, respectively.

  27. SharpDog

    We’re seeing much better performance with Sencha than is being reported above with other frameworks. Sencha 4.x has MVC architecture while the still-supported 3.x is more of a library. We’re seeing initial page loading of around 5-6 seconds and sub-second reloads due to it’s re-use of the js objects. And this is with the debug libraries which are not minified. Our sites are 99% client -side for the gui with a MySQL back end and a thin PHP ORM layer in-between.

  28. Brice T

    Thanks for this big post about things I should go deep into when I have time and hardiness.

    FYI, your “own site” link for angularjs is mispelled to ;)

  29. A few tiny points:

    You can use any part of CanJS on it’s own via it’s builder so nothing is really mandatory.

    CanJS supports IE6.

    I think library support is a “bullet point” of CanJS. It supports Dojo/Mootools/YUI/jQuery/Zepto. And by support, I don’t mean just it runs along-side. I mean you can use it’s templated events to listen to a Dojo or YUI widget event. It will use swap dojo’s methods for it’s own.

  30. To Mark — the Enyo team is actively looking at integrating Backbone’s model and sync system with our UI layer, so hopefully you’ll be able to use the best of both worlds.

  31. great post! I knew only Backbone before and this is a new universe for me…so thank you, man:)

  32. Steve Gentile

    Just thought Id’ mention I’m using Hasher.js with KnockoutJs for routing and it’s worked well. I’ve used sammy.js, but wanted something more directly related to just routing. History.js has known issue with how it handles IE routing so that was problematic.

    Steve, I’m curious if Dojo was mentioned, Dojo appears to fall under framework

  33. Too bad Serenade.js wasn’t represented in this meeting. Great article by the way!

    I’ve migrated from Serenade.js to Knockout.js recently after Serenade.js dropping support for IE < 8 while I still have to support IE7.

    But other than that Serenade.js is a great framework. Also its HAML-like syntax for templates are great. But I really don't like this logic-less templates idea and I think you've missed this point in your comparison table.

    The fact that I can use a bit of logic in my Knockout.js template is a strong argument in my opinion why I chose KO instead of Angular for instance.

    There is still something that I miss in all those frameworks though. I feel that it is possible to be faster than all used approaches by using pre-compilation. Serenade.js has a bit of pre-compilation but it still does some dynamic evaluation.

    By using some syntax like in Serenade.js and other frameworks (like using @attribute so that you can detect what is an attribute) you could do automatic dependencies detection in compile-time instead of at run-time, like KO does.

    Investing more on pre-compiled templates approach would certainly allow browsers to render big tables much faster for example. I'd wish to see some effort on this direction.

    Congratulations for your article and for KO :)

  34. Tim

    Wow – thanks for this! I was familiar with a few of the more traditional offerings but had not heard of Meteor.

    Meteor looks really awesome!

  35. “the seven top JavaScript frameworks/libraries for single-page and rich JavaScript applications”

    What exactly is the metric for determining which frameworks are most popular/useful?

    I have serious doubts that several of the frameworks here are more popular than ExtJS. I am actually very surprised Sencha’s frameworks weren’t a part of this discussion (not that they’re better or worse than anything else out there).

  36. Additionally, no YUI? No Dojo?

  37. Do you guys have heard about Mojito? I think is a good comepitor framework:
    I would like to see some feedback as well..

  38. “FYI, your “own site” link for angularjs is mispelled to ”

    still…please correct, everyone should check angularjs too.

  39. Mat Landers

    Thank you for this article. I had heard of a couple of these frameworks and libraries but had no idea what each one did. Very very informative.

  40. Jeado Ko

    Wow! This post is what I wanted !! it has all information I wanted! Cai I translate it into Korean?

  41. I know people who use Batman with a Perl server. It doesn’t really depend on Rails.

    Ember doesn’t have built-in data storage (Ember.Data is a separate library) and doesn’t force any file structure (you can actually use one js file for your whole app if it’s small enough. also, there’s an example of using Ember with RequireJS on TodoMVC).

    Also, comparing file sizes eg. of Ember and Backbone is unfair. If you want to compare Ember and Backbone, you have to compare Ember and Underscore+Backbone+Handlebars. Backbone can’t work without Underscore and Handlebars is included in Ember.

  42. Great post Steve. We’ve had this debate for years in many technologies of libraries/toolsets vs frameworks. Its really a choice between how the development team wants to build the app. I’e done it both ways and I personally prefer libraries since I can use a combination of ones that I feel gives me the best architecture. But the frameworks are nice if you are getting out of the gate and want to follow conventions.

    I was glad to read your thoughts on DOM based and string based templating. I know we’ve discussed this in the past and I certanily hope the major browsers all start optimizing for DOM based manipulating and templating more. String based is super fast (think JsRender and Handlerbars), but there are clear advantages to the DOM based, as shown by Knockout.

    I’ve built a few apps using a combination of libraries and have a course coming out in a few weeks on Pluralsight that uses Knockout and Sammy in a MVVM manner (more tech listed here). Its been a great experience, but also clarifies some of the pains points that still exist. For example, a great client side data context is a huge opportunity … though I know of a few libraries that are targeting this … but none has impressed me enough yet.

  43. Forgot the tech list link fro my previous comment.

  44. Why was derby only briefly mentioned, but not otherwise covered?

  45. Alex.G

    Which framework/library to use is mostly a matter of personal preference indeed. From that list of 7+, there are a few I would never ever touch.

    Here’s my personal feeling on a few of the other ones:

    Backbone almost does nothing beside providing hooks; Considering how low level the current version of Javascript/Ecma is, I need a bit more from a framework/lib than providing a few hooks and enforce some base types on my code. Still, I understand why it’s widely used, most sites don’t need more than Backbone + JQuery and once you’ve seen one view/model wiring, you’ve seen them all so it’s easy to feel familiar. I wouldn’t feel happy about the boiler plate code past smaller projects though.

    Emberjs is clean. The source code is pretty clean and the solutions are clean. The documentation was lacking but is clearly getting better. Unfortunately, I find the rendering to be too slow still (3-5 times slower than backbone or knockout) to use ember in a big project. I come from Flex which has some pretty insane performance bottlenecks (most notably the non native CSS engine) so I grew quite demanding regarding speed. Also, successful websites/applications are the fast ones so I’m going to watch ember’s progress for the time being.

    KnockoutJS: My little favorite overall. Good documentation and active community. The rendering speed is similar to backbone which is quite something considering backbone itself does nothing ;D Knockout also naturally integrates well with all sort of other technologies such as AMD and any architecture you want to plug-in behind the view models. Easy to get started and still end up with clean code.

  46. Jon

    This has inspired me to write my own javascript application framework. Thanks for the write-up!

  47. I’ve been working on a library the past year, jquery-auto-async. I posted about it recently. Check it out.

    The article uses Microsoft MVC for the backend implementation, but any backend would work with the client side code.

  48. “It’s no longer good enough to build web apps around full page loads and then “progressively enhance” them to behave more dynamically. Building apps which are fast, responsive and modern require you to completely rethink your approach.”

    … unless you happen to be github or 37signals, in which case you can easily build apps and progressively enhance to be fast and responsive ….

    +1 on the ‘completely rethink’ bit though. it turns out that’s the actual key to making an app fast and responsive – not the framework chosen.

  49. I agree but check this out

    It brings a framework like approach to the backbone.js library.

  50. Tom Geiger

    Hi Steven… GREAT POST, I’ve been enjoying all the great information your have been publishing, especially KnockoutJS. .. just an FYI on this post.. your AngularJS links are broken…
    Tom G

  51. Ashish Jindal

    Agree with Diego Ferreiro.
    Y can’t find Mojito in this? :)

    Because it takes away .Net from the server side? ;)

    On a serious note… I think Mojito is definitely a noteworthy and serious competitor to any and all of these frameworks, specially when you start implementing the web-server stack for any application, and that too you need a great framework for developing across devices.

    What do you think?

  52. Pingback: Your Javascript Framework / Library Of Choice? | Leader I/O

  53. Gersart

    Thank you for the post. Very clear and more useful than many with the breakdowns of info. I especially like the suggestion to try the various systems before committing to one.

    As for those who post “you forgot this one” or “what about blah”, they can’t play if they don’t participate. I think the prelude as to why and how was very consise, even if your favorite wasn’t included. This is far more useful than a “umpteen JavaScript blah-de-blahs that you should know about” blog post…

  54. Brad Williams

    FWIW, we recently transliterated our app from Ember.js to AngularJS, and except for moving some code out of the Ember.js router state machine out into the controllers, there is almost no difference in usage and patterns. Sure there are “philosophical differences” such as how the framework has you template in and around HTML elements, but in practice it’s a distinction without a difference for the developer who needs to get user stories to done-done.

  55. Nick Husher

    I’m curious what you thought of Eric Ferraiuolo’s “Advocatus Diaboli” presentation.

  56. Pingback: Daily Update – Too Hot | Everyday Achievements

  57. Alan

    Thanks for being the first read on the Internet able to clearly explain frameworks and libraries without making my head explode. A fresh read.

  58. Hi bro, nice article. Initially, i hate javascript because i don’t like and i don’t trust any codes that running on client side. Thats why i was using some java frameworks such as zkoss/ZK, GWT, etc to do the javascript jobs. But now, in my current company i have to use many javascript codes. thats why i have to go in deep with the javascript and i’ve found many articles and tutorials about javascript stuffs. I’ve just known that javascript also had many good OOP concepts, frameworks and design patterns too. so, i thought it’s not pretty hard for a guy that already familiar with java like me to learn it. that makes me very interested to learning this language now. So, thanks bro to give us such a nice article. Btw, i’m from Indonesia and currently living and working in Malaysia. Two thumbs up for u :-) . btw, i’ll add your blog in my blog as a buddy. I hope you don’t mind with that :-)

  59. Pingback: Building Single Page Application - Ori Calvo

  60. eMBee

    nice overview. one question i am wondering about though is how updates are detected as explained here
    it explains that angularjs does a simple dirty-checking whereas knockout or backbone use change listeners.

    how do the others fare here?
    was this topic talked about?

    greetings, eMBee.

  61. Yakup İpek

    I found meteor.js have amazing features but one thing was looking horrible when i see that client is able to write to db. After check this question on stackoverflow I understood that it is unfortunality not ready for production :) .

    How can we develop a serious app without restrict user permissions to db on client side ???

    By the way it is again a great post Steve .

    Please keep posting

  62. In my opinion, the morale of the story is:

    (a) go read the Backbone source and learn object attribute binding, routing, and see what clean/testable JavaScript looks like.
    (b) take what you’ve learned and write your app on top of light-weight single-purpose components (without or without Backbone and definitely without a monolithic framework).

    But hey, if one of those mono-frameworks is an 80%+ fit for your scenario, go for it.

  63. morale => moral (but you knew what I meant)

  64. Pan

    Hi,can we translate this article to Chinese on our website ?

    Ituring focus on IT and science books and information, and we use markdown on this website. Of course, this article will open to all visitors freely, and there will be a link back if you need.

  65. Dan

    I’d like to hear more about why Progressive Enhancement is dead. Seems like having a version that has no JavaScript and one that has rich interactivity are both possible.

    Also, if a browser didn’t support HTML5 video wouldn’t you still want to try to fall back to Flash? Or if a browser didn’t support drag and drop, you still support the upload button?

  66. Kudos for this summary and its obvious evenhandedness. A couple of nits:
    1. It would even more meaningful to weight the followers/watchers of a product by the amount of time the product has been available (as soft as that is..)
    2. Agree 100% with the point about KO’s awesome docs & tuts; you could note that AngularJS also sets a high bar for the docs and tuts. Not so for the others; the developers focus seems so much to be on dev’g the product that communicating about its benefits and use falls entirely to the reader. How dumb is that?

    Anyway, thanks again for the clarity, SS.

  67. Angel. L

    What do you think about Qatrix ( It`s also small and high performance.

  68. Very nice post. Got fantastic idea about different library/framwork.


  69. Jerry

    A) re: SEO and “one-off” apps; when javascript controls the client, the html file become a container of rich metadata, that upon docload, is rejected for the User interface. Think if every keyword, and ONLY keywords were contained within the body tag of your document. This would greatly enhance your ratings.

    B) I’m finding that the closer to 3GL any library gets, the greater the support. Browsers will one day (hopefully W3C compiant) be 3GL runtime engines. They already are if you can code javascript. Think about how much an impact xBASE had on the world. Javascript needs to be reduced to 3GL just like C and C++ were reduced to 3GL like dBase, Clipper, Foxpro and Paradox.

    C) Glad to hear there are many others out there thinking along these lines.

  70. Pingback: scot hacker's foobar blog » Comparing Javascript frameworks

  71. dan

    Currently at work we build websites for clients, an aggregated mobile site and have started to build native apps.

    We are currently looking at rebuilding our mobile website as well as another web application that will have to be mobile friendly. At the current moment in time we use jQuery for the sites that we use.

    Seeing as we are building a new web app and a new aggregated m-site I thought it would be a good time to review frameworks both for web and mobile and see if we need to change from jQuery.

    So the frameworks I have looked into are

    jQueryMobile Sencha with Sencha Touch JQtouch JQmobi

    Backbone Knockout

    My inital thoughts are to stay with jQuery as the knowledge is already here and dont want just to change for the sake of it but at the same time if there is another Framework we should be using I want to look into it

    Also seeing as this framework needs to serve both web applications and mobile sites I wondered what people though was best.

    The mobile site will mainly be sourced from JSON files from as restful API made in PHP and I can imagine that the web application will work in the same way.

    with some many new frameworks coming out it can be quite tricky to know which to choose, which has the best support and which will stick around.

    I welcome your thoughts.

  72. Pingback: Lectures en vrac | Carnet de notes

  73. Maarten

    Why are there so few people aware of Wakanda?
    It’s a complete stack from backend to frontend based on javascript, html5, css.
    noSql database included with awesome modelling.

  74. Dawesi

    Can’t be taken seriously without Sencha frameworks in the comparison.

    Pity, would have been great to see a framework that supports everything from IE6 to the latest kick all butts on all browsers!

  75. I have gone through 4 frameworks Sandy, Backbone, KnockoutJS and PureMVC. I liked Sandy for lightweight and quick development where as i prefer KnockoutJS for some big developments especially when you are migrating some flex applications to HTML5.

  76. jeff

    All you Sencha-philes: Sencha is not free.

  77. I have to say I’m completely with Wil Moore III. It seems like the “enterprise” frameworks attempt to create entirely new languages — presumably for people who don’t understand JavaScript. An example of this and a testament to learning the language is the perceived issue of “zombie events” in Backbone.js. That is a clear lack of understanding of the DOM, event binding, etc. In many examples of zombie events, you see the person writing the code making obvious mistakes creating statically referenced objects instead of non-static clearly showing a lack of understanding for the language.

    At this time I’m a believer in Backbone.js because it embraces what JS developers already know — events — and suggests a level of organization that we’re already familiar with, models and views (quite literally; some other frameworks use the M, V, and C terms so loosely it’s frustrating). I’m intrigued by the observables and bindings of KO and AngularJS, yet I’m still not convinced that will scale in terms of performance and maintainability.

  78. J A Fernandez

    I have been developing a small mobile app in AngularJS and have been quite satisfied with it. We usually write lots of server side Java code, but in this instance wanted a purely client-side app (except for a small JSON feed for the data to be displayed) running out of plain Apache.

    My question is: Given the completely different issues on browser capabilities in the mobile/tablet segments, how does this affect the usability these frameworks?

    There is no IE6 issue but lots of other like processor speed and browser fragmentation even in the “smart-phone” segment. Any thoughts of which ones of these frameworks are designed with mobile as one of their targets?

  79. Diego Martelli

    Great article. Thank you.
    There are a lot of library/framework and few time to try and understand each one.
    Some times we works in one man or all senior front end team, sometimes we works with js junior (super skilled java or c# developer may be JavaScript junior too). So for me Another great point to analyse is: what about the learning curve for junior and senior developer?

  80. Nice! Its very easy to know about architect on this site.Very useful information here.Thanks

  81. I have to say, web development these days seems like the Wild West to an outsider. It’s hard to know as a novice which of these libraries (or frameworks!) to choose, and once you think you have a handle on it, something new and shinier comes along. I guess that’s good for the industry as a whole in the long run that competition should make the tools that much better.

    Anyway, thanks for putting this information out there.

  82. Ida

    Big collection of various replies. On site pages You can find data about software and computers, art and culture, Internet and music, jurisprudence and english language, bdellotomy and fishery, foreign words and thesis defence.

  83. Various singular winged words for all. On site pages You can find winged words about music and english language, summer and beauty, politics and love, science and smile, friendship and life, dreams and winter.

  84. Different useful publications and notes about garden. On site pages You can find data about agricultural engineering and agricultural methods, orchard management and agrotechnology, also gardening tools and gardening equipment.

  85. Useful publications and articles about various fireplaces for everyone. On site You can find data about granite and marble, onychite and adarce, indoor scene and tabletops, veneer and stairs, also drawing rooms and antechambers.

  86. Different wholesome notes and articles about commercial law. On web-site pages You can find data about medium business and small business, cash and currencies, internet business and profitable business, also companies and customers.

  87. Different interesting publications and articles about Michel Telo. On site You can find life history and notes from MSM, photographs and discography, tours data and lyrics, video materials and social links.

  88. Aman

    Initially chose Knockoutjs but got stuck.
    1) there is no multi-view management. You can’t build Single Page Applications with it.
    2) you need at least 10 other js libraries to use knockoutjs, as it hardly handles much. We wasted 1-2 months figuring out what all needed to be used. This can be confirmed from other user’s experiences. There is a tutorial on Pluralsight and a blog on SPA using ASP.NET MVC and knockoutjs. The author has had to spend lot of time evaluating all these libraries.

    Emberjs is more verbous than Angularjs. .get() and .set() need to be used just to read and write properties. You have to explicitly define all viewmodel properties which is not required in Angularjs. (Please correct me if I am wrong)

    Finally we got everything (almost) and more from Angularjs in just a 29k download. Believe me there are a ton of features in just 29k download.

    The things we would never find time to use are available and so easy. Inbuilt internationalization. There is a superb testing framework also.
    We will finally be able to write tests for our App.


    We are thankful to Angularjs team for doing such a great job.

  89. nice posts, thank you for sharing with us.

  90. K

    Any thoughts about Dart-based frameworks? What about Dart Web Components?

  91. Aman

    It seems that Mr. K has stolen the show here.

    ‘Any thoughts about Dart-based frameworks? What about Dart Web Components?’

    A quick search tells me that: we all were sleeping while the next big thing for Web Apps was taking place in the form of Dart.

    @K Sir request you to please say more. Some of us don’t have mental blocks to see the obvious next big thing.

    Exciting! & Amazing!

  92. Magnificent site. Plenty of helpful info here. I’m sending it to several buddies ans additionally sharing in delicious. And obviously, thanks in your sweat!

  93. Previously mentioned was accessibility, and this actually is very important, since it depends on the functional behaviors of interactive component design.

    ARIA by itself will not fix this.

    There is a Bootstrapping library available at
    That helps with this.

  94. Pingback: 流行js框架对比分析:Backbone vs Ember vs Knockout | 深邃的狮子座

  95. Dave Smith

    Terrific summation. Thanks for taking the time to do this!

    I’m going to watch Meteor closely.

    I’m thinking KnockOut could benefit a lot from Angular’s simplistic expression language. E.g.: {{foo}} vs. data-bind=”text: foo”

  96. Earl

    I’m wondering why SproutCore was mentioned in the article but not part of the comparison? Was it just that they didn’t have anyone at the event? Or is SproutCore a different class of platform?

  97. Hi there colleagues, its impressive post concerning tutoringand entirely explained, keep it up all the time.

  98. Terry

    Check out Lava JS. It looks very cool!

  99. Thanks for some other fantastic article. The place else may just anyone get that type of information in such an ideal way of writing? I have a presentation subsequent week, and I am on the look for such info.

  100. Hi, Neat post. There is a problem along with your site in internet explorer, may test this? IE still is the market chief and a large component to people will omit your great writing because of this problem.

  101. Tony Brown

    It was fun to read, amazing all the miss guided devs out there that are just jumping on the hipster bandwagon, don’t get me wrong, I absolutely love working with Backbone , Node and Mongo and either Mocha or Jasmine to test but it’s kinda funny how people are just dead up wrong in their thinking “Angular is the best, or Knockout rules” lol good read :D

  102. Various publications and articles about software and computer technology. On web-site pages You can find details about machines and devices, drivers and security software, browsers and optimization, utilities and organizers.