Backbone.js Is Not An MVC Framework

I’ve seen this question / statement / argument more than a few dozen times. I don’t particularly care whether or not people try to understand Backbone in terms of MVC frameworks, because that’s how we learn. We adapt new ideas based on existing knowledge experience, before we fully understand the new idea. However, I do care that people continue to say Backbone is an MVC framework, because it confuses people when they don’t see a “Controller” and see things like “Routers/Views are sort of a controller“.

I’m not going to “set the record straight” or try to offer the definitive answer on this, though. I’m not a core contributor to Backbone. I didn’t build it and I don’t have any say in how it’s truly architected and designed. So, none of what I say is official. I am going to offer my opinion, though. I feel my years of experience in working with MV* family applications at least gives me enough knowledge to do that… which, honestly, is only going to muddy the waters more because I seem to be in the minority on this opinion.

There Are No Controllers In Backbone

There simply aren’t. In spite of the documentation saying that routers or view may be sort of maybe almost kind of close to some of what a controller might do, there are no controllers. It’s not a construct that exists in the backbone namespace, and there’s no implementation that represents what a controller does, architecturally.

A router is not a controller. It’s a router. A view is not a controller. It’s a view. Yes, both routers and views share some of what a modern web-server MVC framework, such as Ruby on Rails, would call a controller. But neither of these is a controller.

More MVP Than MVC

I’ve spent 5+ years building MV* family applications in thick-client / GUI systems (Windows / WinForms / WinMobile) and on the web (Rails, ASP.NET, ASP.NET MVC, etc). Backbone clearly fits in to this family, but it’s also clearly not MVC. My opinion says that it’s closer to MVP, where the backbone view is closer to a P (presenter) and the HTML/DOM is the V (view).

Consider this picture of an MVC process flow (from Wikipedia):


Here, the models contain data which is used to populate views. Actions that a user initiates are handled by the controller which processes the request and updates the models. The models are then fed back to the views and the cycle starts over. It’s cyclical in nature.

And now consider this picture of an MVP process flow (from


Notice the difference? Right – it’s not circular. That’s the big difference between MVC and plain-jane MVP (a.k.a. “passive view“). MVP does not work in a circular fashion the way MVC does. Instead, it relies on a presenter (the “P” in MVP) to be the coordinating brains of the operation. The presenter in an MVP app is responsible for taking the data from the models and stuffing it in to the views. Then when an action is taken on the view, the presenter intercepts it and coordinates the work with the other services, resulting in changes to models. The presenter then takes those model changes and pushes them back out to the view, and the elevator of moving data up and down the architectural stack begins again.

Does the idea and responsibility of a presenter sound familiar when thinking about Backbone? It should… it fits almost concept for concept with Backbone’s views, in my mind. But that doesn’t mean Backbone is an MVP implementation, either. It only means that views should be thought of as presenters, not controllers.

Neither MVP, Nor MVC, Nor MVVM, Nor …

Ultimately, trying to cram Backbone in to a pattern language that doesn’t fit is a bad idea. We end up in useless arguments and overblown, wordy blog posts like this one, because no one can seem to agree on which cookie-cutter pattern name something fits in to.

Backbone, in my opinion, is not MVC. It’s also not MVP, nor is it MVVM (like Knockout.js) or any other specific, well-known name. It takes bits and pieces from different flavors of the MV* family and it creates a very flexible library of tools that we can use to create amazing websites.

So, I say we toss MVC/MVP/MVVM out the window and just call it part of the MV* family. Or better yet, let’s just call it “The Backbone Way” and forget about trying to fit some cookie cutter mold around a fluid and flexible library.Then we can focus on what Backbone actually provides and how these pieces should work together to create our apps.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs - the amazingly awesome podcast audio hosting service that everyone should be using, and where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Backbone, Design Patterns, Javascript, Model-View-Controller, Model-View-Presenter. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • >>More MVP Than MVC

    I don’t agree.

    I believe Backbone more closely resembles the original MVC GUI paradigm as existed before MVC web frameworks changed its meaning:

    • Like I said: bits and pieces of many flavors of MV*, not MVP or MVC, my opinion, and useless discussions that don’t get us anywhere. The point of the article is at the bottom.

    • and FWIW: I agree with you. I wasn’t considering the old-school MVC, though, as that’s not what people refer to when they say MVC, in general. I usually hear people say “SmallTalk MVC” when they refer to that.

  • Lance Harper

    What about Spine.js?

    • I don’t have enough experience with spine to say much about it. I’ve only looked through the docs and played with a few samples, a few times.

    • Blake

      In spine, the controller is similar to the view in backbone. Collections and models are consolidated and instantiated/managed on a more global scale. Other than that the patterns are the almost the same. Controller creates views and subscribes to changes on models in order to update.

  • Mike

    I propose a new acronym MVS, Model-View-Something

  • Just a thought, but because of no controller or presenter, we end up needing things like Marionette to provide view switching, etc…?

    IMO, I view that part of Backbone ‘out of the box’ as being incomplete.  Although you could say he just left it open for others to implement the controller/presenter/viewmanager.  Once your app starts to go down that composite route we are in need of these ‘missing’ pieces

    • Yeah, I think that’s part of the downside of open and flexible libraries like Backbone. If Backbone provided an application layer it would likely become more prescriptive in how you have to do things… like Sproutcore or Batman.js. There are plenty of benefits, but also some drawbacks, to both situations. Open and flexible, but less guidance and a few missing pieces… or more prescriptive, but with all the pieces right there in the framework for you.

  • gabriel

    Change Backbone.View to Backbone.Controller. What do you think?

    • No… calling an orange a hammer doesn’t mean you can pound a nail into wood with an orange.

      I could get behind renaming it to Backbone.Presenter, for the reasons I’ve stated above, though.

      • Derick, Backbone.View IS AN MVC CONTROLLER, it’s just a poor choice of words. The view in HTML models is the HTML and CSS which the Backbone.View (the Controller) handles!

        Read my presentation to see an image which explains the relations:
        TBH, it’s quite simple once you accept the fact that Backbone.View is a controller. BTW, check out Android programming, they do something really similar – there, the Backbone.View is called an adapter.

        • p l

          Why must one accept something doesn’t like to be this??? ;-)

          Controller in MVC (we are talking about its original in Smalltalk-80, aren’t we?) didn’t have some functions the BB.View have. The View was more active about data fetching, its state holding and manipulating itself. All this we don’t have in BB. The View ist simple markup without logic. All logic about presentation is bound to BB.View. So I can see BB implementing MVP and brings some nice features for data layer with.  

        • In MVC, a view wires itself to the controller, and changes as the controller changes. The controller has no reference to the view. In MVP, the presenter reaches into the view and messes with it, and can also talk to other presenters.

          I don’t think these discussions are super important, but I would highly recommend reading

  • Luc Perkins

    I argue here that Backbone does have an implicit and somewhat creepy deus ex machina controller: 

  • Chance

    Here is the controller for Backbone.js :

  • Vlad

    Hi Derick!
    I have 1 small question/suggestion. When you say

    “A router is not a controller. It’s a router. A view is not a controller.
    It’s a view. Yes, both routers and controllers share some of what a
    traditional MVC framework would call a controller”

    I think the 5th sentence should be corrected to “yes, both routers and VIEWS share some…”.

    Or did you really mean “controller” as old name of router in Backbone?

    • Yes, you’re correct. I meant to say “views”. Fixed. Thanks! :)

      • Vlad

        cool :)

  • Guest

    By now the term MVW (Model-View-Whatever) has already been coined and the carrot that is isomorphic javascript, or JS that runs both on the client and server, is furiously being sought after. Will Flatiron the first one to the finish line?

  • Guest

    By now the term MVW (Model-View-Whatever) has already been coined and the carrot that is isomorphic javascript, or JS that runs both on the client and server, is furiously being sought after. Will Flatiron be the first one to the finish line?

  • By now the MVW (Model-View-Whatever) has been coined. More patterns have emerged and the carrot, still dangling, seems to be isomorphic javascript:

  • Hi,

    I know this is an old post but I found it during my googling and I’d like to give my thoughts on it.

    I find Backbone appealing because I come from a Django background and I find it very similar to it, since Django has its own router (a urlpattern tuple), a set of templates, views that are responsible for rendering a template and models.

    Django refers to itself not strictly an MVC but MTV (Model-Template-View), which is a bit different but from the same “family” of frameworks.

  • Javier Lorenzana

    I have to say – tomatto, tomato. This whole thing pretty much misses the point of what MVC is meant to accomplish; I love being specific, but this is ridiculous.

    Backbone.js makes an MVC block out of a piece of your page.

    As mentioned above, there’s no MVC framework for web apps which complies entirely with the behaviour you’d expect from a native app – nor do they need to.

    They’re still called MVC because, given the architecture of the system in which they run, REST, they are still providing the separation and interaction that makes MVC useful. Which is exactly what Backbone.js does on the system in which it runs – the browser.

    Every single JS “MVC” framework out there adapts the pattern in their own way. Tomatto, tomato. If I have my model separated from the data presentation and control interface, and the actions those controls trigger upon my model, then I call it MVC.

  • jraede

    The Backbone.View IS the controller. It takes information from the model or collection and displays it on the ACTUAL view, which is the DOM. It literally does exactly what any controller in any MVC framework does, it is just poorly named. View Controller would be more appropriate.

    Think of it like iOS. The view controllers do what backbone views do. The nibs are the equivalent of DOM elements.

  • nice article…but please check back Top 10 Javascript MVC Frameworks

  • Shine Li

    “There Are No Controllers In Backbone”

    I don’t think this is a valid statement. When you take a closer look at the framework, you will find template is actually ‘View’ and Backbone.View is actually ‘Controller’.

  • tipiirai

    Thanks for the article! Backbone indeed looks like MVP to me. So why it is not?

  • Jan

    If you search for a nifty MVP JavaScript library, take a look at Riot.js.

  • Asad Hasan

    Event callbacks are event controllers, but not total controllers in the traditional mvc setting. Its an MVE framework if anything.

  • Mr CSharp

    I think people need to know how to program first before thinking too much about patterns. Next after knowing how to code, then think about consistency and the format of the code. I’ve seen too many crappy coders who always talk about different frameworks and patterns, especially using MVC or MVP. These crappy coders usually massacre the hell out of an application such that it’s non-intuitive for others to follow. When this happens, you start to get cowboy coding to try and bypass the intended framework. In the end, you’ll be left with a piece of toilet app and all the crap overflows.

  • felixzacat

    MVP and MVC are almost the same. Your post hasen’t convinced me that MVP is different from MVC. The P and the C are the brains. End of story. In MVC there is a soft reference from view onto the model, but thats about it.