Digesting JavaScript MVC – Pattern Abuse Or Evolution?

In my talk from London Ajax, we'll explore the current state of MVC in the JavaScript community, how Smalltalk-80's MVC differed and whether modern frameworks abuse (or evolve) the MVC pattern. We'll also look at a framework that tries to stick more closely to Smalltalk MVC and close up with a panel discussion.

For readers/redditors/hacker news readers, I'd love to hear your takes on these topics too so feel free to comment below or contribute to the discussion.


Note: The above deck is a slightly updated version of the slides presented at the talk, but should you wish to view the recording it's available below. I only had about an hour to get the slides together as this was last notice, so my apologies if it isn't polished!.


  1. Awesome presentation,
    I’ve always wondered why so many MVC’s are out there…

    Now I understand, that something of academic use was released to the wide public and it become used by the crowd.

  2. Hi Addy,

    Once again thanks for the great pres. Good Job!
    Here’s my two cents:

    When you write that “in 2012 most developers realize maintanable code is important”, you’re probably refering to the JS (jQuery fanboy) community… (excuse my french)

    I have worked with other languages (PHP, Java, Python, ActionScript/Flex (haters gonna hate), C, and also played with Ruby for a while), and 10 years ago, maintanable code was already important (you probably knew that already) … actually 34 years ago that’s probably what made the Smalltalk community go for MVC …. (brilliant idea since some people still talk about it in conferences all year long 30+ years later)

    MVC (or MV*, and even actually M*) can be implemented in many many ways, making it actually a very interesting design pattern (unlike Singleton, Factory, Facada, Decorator, Adapater or Observer which are almost always “the same”) … MVC definetly has it’s place in JavaScript land and I really like the fact that each MVC framework has it’s own “flavor”, depending on the project, one framework might be more suitable than another depending on the project/work to be done.

  3. Very interesting slides. I do believe that the classical MVC pattern is very clever, and sticking to it can make it possible to almost eliminate direct manipulation of the view, which is great for maintainability. That’s my main goal with Serenade.js, and so far it seems to be working really well, I discussed this further in my blog post about why I wrote Serenade and why I believe that the classical MVC approach is well suited to modern web development:

  4. If you’re prefixing a framework name you’re doing it wrong “Backbone *”, “Spine *”. All these components should just be “JavaScript *”. I’m guilty of this on the server-side to a certain extent with Express, though it’s much more important on the client. We need to get rid of “jQuery paginator” etc, it should be nothing more than “paginator”.

    • I think that’s a sane naming approach TJ, though a follow-up question: I feel most framework authors guilty of prefixing do so to make it more easy to

      a) distinguish what context their work is for (e.g Backbone Paginator is obviously a pagination component for BB, whilst Paginator might initially confuse developers looking for a more general solution that works with everything) and

      b) to make it easier to find when quickly looking through a list of similar frameworks (again, for context reasons). We could easily find Paginator, whoaPaginator, jeezAnotherPaginator if opting for a non-prefixed name but would expect users to dig down and read the repo readme/tagline to figure out where it works and where it doesn’t.

      Do you feel those are valid concerns? Given the likes of Walmart’s Thorax (also a BB project) I think there are very much devs on both sides of the naming fence atm.

      • It’s not that it looks silly or anything, it’s that these components are coupled to this parent framework. I think this is a big flaw in the javascript community in general, we’ve seen it going away a bit lately with things like hammer.js etc but we can do a lot better than this.

  5. Pingback: » Blog Archive » Javascript MVC/Maria/Design …

  6. Would the be any way to download the presentation?
    I like to watch presentation offline on my daily commute.

    I could not access the video page on the Vimeo site itself to do download it. Maybe there are some regional restrictions? I’m in Canada.

    • I think the event sponsors keep the download links private as I’ve noticed it’s the same with some of their other videos. If you drop a request over to @London_Ajax they might be able to help with that : )

  7. “Maybe we need something else than a framework”

    When I saw this I immediately thought of Web Components. A lot of this core stuff could be built into the underlying html spec.

    • Absolutely. I and a few others have plans to write a lot more about how Web Components might change how we view the broader landscape and use of these structural frameworks in the future. Hoping to cover this later in the year.

  8. Rhys Brett-Bowen, I agree that the view does not need to be aware of either the domain or application model. The MVP pattern emphasizes this, with each view and presenter working through interfaces.

  9. Pingback: Tools, libraries and patterns used at Huddle « Andrew Chaa, cha cha

  10. Great presentation, you should add a few slides about MVVM.
    It is an awesome design pattern to combine with web API.

  11. Historic addition:

    Sun called is original Java AWT (Abstract Windowing Toolkit, its UI library) an MVC implementation. It wasn’t.

    Reminds me of the early days of relational databases, when marketing slapped the “Relational” label on everything, table-based or otherwise.

  12. Sometimes it seems a JavaScript framework is released each week. Believe me, I understand this can be overwhelming. But, in my mind, this is more a beauty of the language than a challenge.

    Pattern memorialization in specs feels like a step backwards to me. Something more totalitarian in a space that has flourished as an entrepreneurial republic. That’s why I believe this yearning to experiment, this propensity for choice, is best approached from an evolutionary standpoint.

    Put plainly, we will use the best framework for the job. The remaining will either change form or forever fade into the ether. Choice is not a challenge. Choice is the fruits of a well tilled garden.

  13. I am not sure if a buy the idea that the smalltalk pattern is the “old way” of doing it. If we look at neighboring technology, like as3 and flex, the classic MVC/ MVP has been very successful (see robotlegs, puremvc, pixlib ++ ). What Addy calls “javascript mvc”, is in reality an adoption of the java model2 pattern used in Rails, developed in the 90’s.

    I think it is important to ask if the model2 pattern is the right way to go for javascript, and not only blindly implement conventions from Rails.

    Personally I rather draw experience from as3, as it has much more in common with javascript than Rails (being highly dynamic and evented on the client side).

  14. Really nice slides as usual, and always inspiring. Addy, you really rock the web world !

    I think we came to the point that too much frameworks will kill the frameworks and as a J2EE developer using mainly MVC design pattern using Struts or SpringMVC on server- side having again a MVC on client-side will be too too much. Let’s be simple and think about it, when should I use a Javascript MVC when the MVC for enterprise apps are done server-side ? the answer for me is : NEVER.
    Let me explain : we’ve build an in-house javascript (jQuery based) interface / controller / presenter that handles the requests made in the UI and sends them to the server (ajax mainly), the server stores the model (form) and the controller itself (action) who handles the requests, updates the model and send back to the view plain JSP fragments, so efficient and maybe too simple I guess, or too old-fashioned ?
    In real-life apps, I really don’t see where those frameworks will find a place without adding an extra (overwhelming) layer to the already complex J2EE package.

    What’ your return guys about it ? has some of you already experienced one of those frameworks inside a big-sized enterprise app ?

    • groels, like you I’m a Java (and C#) guy originally. Imho this discussion of MVC is not applicable to a scenario where most of the code is running server-side in J2EE.

      It’s for one-page JS-only thick-client web apps where the server side typically only handles the data storage.

  15. Pingback: טכנולוגיה, קסם, אצבעות, משימות ועוד. רשימת קריאה ויומן שיטוט ברשת הפתוחה « טכנולוגיה בשביל אנשים

  16. Pingback: Journey Through The JavaScript MVC Jungle -

  17. Pingback: Journey Through The JavaScript MVC Jungle

  18. Pingback: Extending the MVC design pattern | Soniple

  19. Pingback: Journey Through The JavaScript MVC Jungle - FREE THEMES FOR WORDPRESS – FREE THEMES FOR WORDPRESS

  20. Pingback: Journey Through The JavaScript MVC Jungle

  21. Pingback: [Перевод] Обзор JS-фреймворков. Путешествие через джунгли JavaScript MVC. Ч. 1 | wp2005 [Перевод] Обзор JS-фреймворков. Путешествие через джунгли JavaScript MVC.

  22. Pingback: JSSpy » Mvc: primer

  23. Pingback: Journey Through The JavaScript MVC Jungle - Goodfav Howto

Leave a Reply

Required fields are marked *.