Knockout vs JavascriptMVC vs Backbone

“I asked Matt if it was ok to repatriate this article since his blog is now offline (will be back soon), Backbone is not portrayed in a good manner here, but I can understand his frustrations and found his point of view interesting” – Cedric Dugas

Recently we had a project that called for heavy Javascript interface. Awesome! A chance to try out some of these new fangled Javascript frameworks; namely Knockout, JavascriptMVC, and Backbone. The project’s UI would have to respond to many different events across many nested templates. It would also have a fair amount of objects that would need to be synced to the backend when they were updated.

Disclosure: I’m a server-side guy. I went from PHP to Rails over the last 10+ years. I’ve avoided Javascript successfully until jQuery lowered the bar so far that I could heft my unwillingness up and over.


My first foray into Javascript frameworks was Knockout. Knockout has the nicest site so I chose it first (you do it too). Knockout felt really great at first. It made sense. It sells the fact that when an attribute in your view model changes, your UI refreshes automatically. To be clear, all three frameworks do this. Anyhow, Knockout was going well enough, but I did have some issues getting my Javascript ‘classes’ to mix in with Knockout’s view model. It wasn’t horrible, and quite honestly, it could have been a learning curve issue, but things rarely worked the way I’d assumed. Knockout is really just a MVVM (Model View View-Model) design pattern implementation and deals with the UI. It has no built-in way to structure/load/save your objects back to a REST interface. Knockout solves half our needs, so we moved to JavascriptMVC.


JavascriptMVC (JMVC) is a robust (heavy) framework that does everything from giving you an opinionated way to structure your Javascript code, to generating it for you. The framework adds 20M+ to your public folder as a result. This isn’t a huge issue, but it nearly doubles the Heroku slug size my existing Rails backend uses. EDIT: I misspoke here. According to Justin Meyer, the author of JMVC, the framework is actually quite small (7KB). I downloaded the entire project (including tests, documentations, etc.) and dropped it into my project.

JMVC provides a clear way to CRUD your data and test it, and has a bunch of decent documentation and tutorials. What turned me off was that it’s super heavy. My gut feeling is that when one project solves too many problems, it doesn’t do them well. From the sheer amount of stuff it generates and perusing the documentation I honestly got overwhelmed. I thought, hell, if I’m learning their way, why not learn it from the ground up and really get a good feel for it? This is also the same principal that kept me on Slackware until 2005 — but is also the reason I’m at home on the command line.


I’ve heard about Backbone.js from a bunch of people and it was my first thought when it came to this project. I guess I saved it to last as it was the most bare bones implementation of a Javascript MVC stack; the very reason I now turned to it. Backbones has a decent amount of streamlined documentation and a few live app examples. For the first twenty minutes I missed their underscore.js dependency and sat there staring at a super obscure Javascript error that had nothing to do with the missing dependency. After a Twitter buddy nudged me in the right direction, I was on my way — for about five minutes.

I started a simple Todo List app that was meant to be a quick learning exercise. Creating Backbone Models and Collections was a snap. Creating a View was less than straight forward. Is their View a View-Model? Are you supposed to have one large View and many sub-views (templates)? The frustrating part was that all examples on the web showed many ways to use a View — and none of them worked for me.

I sat back and thought to myself that I was biting off too much at the first pass and that I would work my way through one of their example apps. I typed it all up, then clicked refresh on the page. It erred out. I double checked everything. The error was something like “undefined blah blah in underscore.js on Line 8”. Not exceedingly helpful — especially to a beginner. I even went so far as to directly copy the app and its templates. It failed to run.

I gave up.

I think these frameworks are a great idea, and something like them are going to be a necessity as the web matures, but they introduce a whole slew of their own issues. If I had to use one today, I would recommend JMVC. It’s the most mature of the three projects and it shows.

I’d like to see a mixture between Knockout and JMVC rolled together like ActionView, ActiveRecord, and ActionController in Rails. Backbone would fill Sinatra’s slot as the barebones implementation. Who wants to make the first MVCMVVM framework? You (and the Romans) could call it “2915”.
Some stats:

Software Artisan at EdgeCase, co-founder of Protected Method LLC. Ruby, Rails, Brewing, Metal. I do things with stuff. Follow me on twitter.

9 Comments on "Knockout vs JavascriptMVC vs Backbone"

  1. Matt Darby says:

    As a prologue to this blog post, I should not that I use (and no rather like) Backbone.js. It has a learning curve as it aims to be hands off and Javascript's error traces are lackluster. Otherwise it's a quite nice. I've used it on several projects now and find uses for it everywhere.

  2. The error I most often hit with Backbone is probably the same one you hit: “undefined blah blah in underscore.js on Line 8”. It's not Backbone but Underscore.

    It has to do with HTML templates (_.template function). You probably have a variable not defined being interpolated in the template. So you get a reference error. Here's an issue on GitHub about it giving a bit of background:…

  3. Juri says:

    Did you try Spine?

  4. Mike Coolin says:

    try angularjs

  5. Michael says:

    Thanks for posting your experiences with these.

    The frustration level in the little chart you made is great :)

  6. Mike Barlow says:

    I have tried Backbone and Knockout, but not JMVC. My experience with Backbone and Knockout was very similar as yours experiences. I picked-up and became productive with Knockout fairly fast. It took me over 2 weeks to understand and use Backbone. I’m not sure if Backbone is better than KnockOut, but I do like the flexibility and structure that Backbone provides.

  7. Carlos Vega says:

    I tried backbone and JMVC and both are good in their own way. I prefer Backbone because it allowed me to actually build my app model. The learning curve was high but once you learn how to use it you’ll love it. The thing is that you need to understand that backbone provides only the structure but not an organized way to code.

  8. Ryan martin says:

    Your post brought me some sort of comfort knowing I am not losing my ability to learn technologies quickly as we’ll as understand these new technologies following best practices. I’ve been building large complex enterprise applications mainly in the .net realm for 12 years and since stepping into the world of JavaScript I’ve been completely useless with all of the so called great libraries and frameworks that the majority of community praise and promote.

    Over the past 5 days I’ve been trying to get one of my web pages which is written entirely in HTML and jQuery into either backbone, knockout or knockback but its been a frustrating frugal endeavor. I’m about to give up and stay with my plain old JavaScript calling my WebApi REST Services.

  9. Neha Khanna says:

    I have tried all these 3 frameworks. There must me some other parameters in this table as well. The learning curve with knockoutjs is much less compared to the other two frameworks. I totally ruleout the backbone.js.

Got something to say? Go for it!