Choosing a JavaScript MVC Framework

So you love the way single-page apps like Gmail and Trello feel, but aren’t sure where to start.  Maybe your JavaScript code has become disorganized enough that you are convinced to try one of the numerous  JavaScript MVC libraries/frameworks on your next project but aren’t sure which one to choose.  I’m writing  a book on single-page apps so I’ve pretty much “read the internet” on the topic.  I’ll attempt to provide some not so obvious insights to help you make your decision.

Introduction

javascript-mvc-frameworks-greyscale-2

The frameworks discussed are the ones with the most traction at present:  AngularJS, Backbone, Ember, and Knockout.  Batman, CanJS, Meteor, and Spine are also mentioned but not covered in depth.

Each project is examined from several different perspectives including community, leadership, maturity, size, dependencies, interoperability, inspiration, philosophy, and features.

Community

A  good indicator of the health of any open source project is its community. The table below shows the number of GitHub watchers for each of the projects.

github-watchers-javascript-mvc-frameworks

You wouldn’t want to make your framework decision on this data alone but it certainly gives you a sense of which frameworks are:

Most established

  • Backbone.js
  • AngularJS

Experiencing the most growth (in the last year)

  • AngularJS
  • Meteor
  • Ember
  • Knockout

Showing a small following but growing rapidly

  • CanJS

Growth

In particular it is worth noting the incredible growth of AngularJS (379%) in the past 13 months and taking this into consideration when making your decision. The chart below compares the growth  of GitHub watchers (over that 13-month period) to provide an idea of how fast the community has been growing for each project.  Meteor (130%), Ember (104%), Knockout (76%), and Backbone (64%) also have had amazing growth considering their previously sizable communities.

github-watchers-growth-javascript-mvc-frameworks

Leadership

Understanding the people, their backgrounds, and the problems they were trying to solve when they created a framework helps you appreciate their design decisions and motivations. For example, David Heinemeier Hansson, creator of the popular Ruby on Rails web development framework, was working as a contract developer for 37signals design projects and had only 10 hours a week to work on the framework .  Ruby on Rails was actually extracted from some of his initial contract work with 37signals.  This background helps you understand that the framework had to be extremely productive for the developer which means a lot of conventions (decisions already made) and scaffolding (generated code).   Below, I’ll introduce you to the creators of the JavaScript MVC frameworks so you might develop a similar appreciation for their work.

Backbone

jeremy_ashkenas_headshot

Jeremy Ashkenas and DocumentCloud

Jeremy Ashkenas is the creator of the CoffeeScript programming language, Backbone.js JavaScript framework, and Underscore.js a JavaScript utility library. According to Wikipedia, he is currently working in Interactive News at the NYTimes /DocumentCloud.

Image Credit: The Canadian University Software Engineering Conference

 AngularJS

angularjs-team

AngularJS was originally developed at Google in 2009 by Miško Hevery and Adam Abrons as the software behind an online JSON storage service.  Abrons left the project, but Hevery, who works at Google, continues to develop and maintain the library with fellow Google employees Igor Minár and Vojta Jína.

Image Credit: Devoxx 2012

Knockout

steve-sanderson

Steve Sanderson is the original creator of Knockout.  Steve Sanderson is currently working as a developer for Microsoft in the team that brings you the ASP.NET technology stack, IIS, and other web things. Previously, he developed .NET software as a contractor/consultant for clients in Bristol and beyond, plus wrote some books for Apress, such as Pro ASP.NET MVC Framework.

Image credit: Steve Sanderson’s Blog

Ember

The two most well-known and public members of the Ember core team are Yehuda Katz and Tom Dale.

Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core teams; He spends his daytime hours at the startup he founded, Tilde Inc.. Yehuda is co-author of the  best-selling jQuery in Action and Rails 3 in Action books.

Tom Dale was previously on the SproutCore team. He’s a former Apple software engineer who gained expert front-end JavaScript skills while working on the MobileMe and iCloud applications.

yehuda-katz tom-dale

Image Credit: Ember Team

Meteor

The Meteor development group just raised $11.2 million so they can do this fulltime and they have a team of 12 developers with impressive resumes.  The team has ambitious goals that stretch beyond the scope of most Javascript MVC frameworks which focus on organizing client-side code and state. Meteor is a full-stack framework including architecture on the web server and the database.

CanJS

CanJS was created roughly 2 years ago by Justin Meyer and his team at Bitovi, a web application consulting company.  CanJS was extracted from the companies original framework JavaScriptMVC which has existed for 6 years at the time of this writing.  Bitovi’s core business is building applications with the CanJS framework.

Maturity

Considering how mature each framework is helps you understand how big of a risk you are taking when using these newer technologies in your project.  New and unproven frameworks can have problems with documentation, scalability, stability (API changes), and support (finding developers to maintain the code who know the framework) that could cause an otherwise good decision to backfire.  Some things to consider include:  How many  real-world production apps are using these frameworks and how many users do these apps have?  How good is the documentation and how many examples/tutorials are available?  Are the examples up to date?  How stable is the API?  Do other developers know or are they getting to know this technology?

  • Backbone (most mature)
    • apps in production for 3 years now including GroupOn, FourSquare, USAToday, DocumentCloud, etc…
    • good documentation
    • good examples but many now outdated
    • API very stable
    • lots of watchers on GitHub
  • AngularJS (mature)
    • in production now at Google but does not have as long a track record as other projects
    • good documentation, getting better
    • lots of examples
    • lots of watchers on GitHub
  • Knockout (mature)
    • in production for 2 years now
    • great documentation including jsfiddle like examples
    • API stable
    • lots of examples
    • lots of watchers on GitHub
  • Ember.js
    • first production release 1.0 on August 30, 2013 after 2 years of development
    • documentation improving but
    • API had intentionally not been stable until 1.0 release
    • good number of examples some outdated due to API changes prior to 1.0
    • lots of watchers on GitHub
  • Meteor
    • still early in development used mostly in example apps
    • documentation good but a work in progress
    • API still evolving
    • some examples
    • lots of watchers on GitHub
  • CanJS
    • Roughly 2 years old but extracted from framework that is 6 years old
    • Applications in production for Walmart, Cars.com, Apple (store.apple.com), Sams Club mobile app, Wanderfly

Size

It’s important to understand how big  a download each of these frameworks is and what you are getting for that extra weight in your application.  The size affects performance but also gives you an indication of how ambitious a framework is and how long it might take you to learn this new technology as well as hint at how many ways its trying to help you build your application (i.e. how many features does it support and how robust are they).  The more ambitious and feature rich a framework is the harder it will typically be to integrate it with others particularly on the same page of an app.  Lighter frameworks are more like a library and a smaller commitment to include it in your project.

size-of-javascript-mvc-frameworks

Some of these projects such as Backbone and Spine pride themselves on how small they are and think of themselves more as a library than as a framework.  Often these smaller frameworks leave room for “choosing your own” library to use for features such as templates and routing.  We’ll explore this in more detail when we talk about the features of each.

Other projects, such as Ember and AngularJS are more ambitious and are comfortable being called a framework.  They often have more built-in features and depend less on external libraries.

Below is a list showing which projects considered more of a library versus a framework.

Libraries Frameworks
Backbone Ember
Knockout AngularJS
Spine Batman
CanJS Meteor

Dependencies

What other libraries are required to build a real-world application with these projects?  The chart below takes a look at what the average number of dependencies each library requires for the developer to be productive and looks at size including these dependencies.

These numbers were gathered by downloading libraries from cdnjs. In practice, most projects will use jQuery with these frameworks to do DOM manipulation in a web application because they need animation and AJAX support as well.  In a mobile application it’s not uncommon for projects to use  Zepto.js which is a much lighter library for handling DOM manipulation but doesn’t support Internet Explorer which is not a common requirement for mobile applications.  AngularJS already has trimmed down version of jQuery jQLite included but jQuery can override it if used in your project. The AngularJS team encourages developers to not add the full jQuery library unless needed.   To help you make the right choice, the table above shows a mobile column which assumes Zepto.js and a web application column which shows jQuery.

size-of-javascript-mvc-frameworks-w-dependencies-web-app

size-of-javascript-mvc-frameworks-w-dependencies-mobile-app

Interoperability

This section discusses whether each framework is designed to control the whole page or if it can be used as a small part of an existing page as you slowly work this new technology into an existing project.  The earlier library or framework discussion for the most part determines how interoperable each of these projects is…so the libraries tend to be more easy to integrate into existing projects while the frameworks do more for you but don’t play as well with others.

AngularJS

Works well with other libraries but developers are encouraged to see if they can do without jQuery and jQueryUI. In fact Angular has a subset of jQuery called jqLite.  The rationale for following this practice is ease of unit testing as many dependent libraries and plugins weren’t designed with unit testing in mind and are subsequently more difficult to mock away in unit tests.  In practice most developers end up using jQuery for something and including it.

Backbone

Because of its small footprint and un-opinionated architecture it’s easy to include with numerous popular client-side libraries and server side technologies.

 Ember.js

Intended to control your whole page at run-time so not suited for use on only part of a page.

Knockout.js

Can be used as a small part of larger projects and doesn’t need to control the whole page.

CanJS

CanJS plays extremely well with third-party UI library controls including jQuery UI and DOJO allowing the controls to be properly disposed avoiding memory leaks that can plague single-page applications.

 

Inspiration

A favorite question of journalists interviewing musicians is: “What artists did you listen to growing up or who inspired you?”  This often leads to insights or gives hints to their readers of what sound they can expect from that musician.    Most of the ideas in these frameworks are not new to software development but come from technologies the creators had worked on in the past and enjoyed.   This section summarizes what information I could find from interviews with the creators of these frameworks about their inspiration.

AngularJS

Declarative programming languages such as  HTML and the rich internet application technologies (RIAs) such as Flex from Adobe and Windows Presentation Foundation (WPF) and Silverlight from Microsoft were technologies the creators of AngularJS  were heavily influenced by in their work.   These declarative technologies  don’t have a “main” method and just express what needs to happen but don’t specify the implementation .  Two-way data-binding in views to model objects is a canonical example of this declarative programming style in action.    Also dependency injection and inversion-of-control (IOC) containers in particular Juice which is used heavily in server-side Java code by Google engineers is a stated inspiration for the creators as they value unit testing and need a framework that is designed to allow you to inject your dependencies so tests can be isolated from other application layers and run fast.

Ember

Tom Dale did a great job describing Ember’s influence on Quora:

With Ember.js, we’ve spent a lot of time borrowing liberally from concepts introduced by native application frameworks like Cocoa. When we felt those concepts were more hindrance than help—or didn’t fit within the unique constraints of the web—we turned to other popular open source projects like Ruby on Rails and Backbone.js for inspiration.  Ember.js, therefore, is a synthesis of the powerful tools of our native forebears with the lightweight sensibilities of the modern web. –Tom Dale on Quora

In addition, it’s important to understand that Ember.js is an evolution of the SproutCore JavaScript library and became Ember at the point when SproutCore stopped becoming more Cocoa like and was more heavily influenced by jQuery.

Knockout

This Hanselminutes podcast has some great background on Steve Sanderson’s inspiration.  In summary, the  Model View View Model (MVVM) Design Pattern and  declarative technologies such as Microsoft’s WPF (Windows Presentation Foundation) and Silverlight were the biggest inspirations.  You may have noticed that the declarative two-way data-binding that is the best feature of Knockout is very similar to AngularJS because they had some of the same influences.

CanJS

According to Justin Meyer’s Rails was a big influence in particular with the naming and API.  The evolution of the framework particularly the recent features added in 2.0 have been influenced by other JavaScript MVC Frameworks.  More specifically, Angular’s two-way binding and directives (custom elements in CanJS).

Philosophy

Newspapers generally strive to be unbiased in their reporting of the news.  The one exception to this is the editorial section where opinions are encouraged and writers often take a strong position on an issue.   At times both types of writing are not strictly unbiased reporting or strong opinion but somewhere in the middle of this continuum.   Technology frameworks have a similar division tending to be more strongly opinionated or not as opinionated.  For example, Ruby on Rails values convention over configuration and makes lots of decisions on behalf of the developer such as file structure and data access. Consequently, it is considered to be pretty strongly opinionated.  Other server-side frameworks such as Sinatra are more light-weight and not opinionated about file structure and data access.  Consequently, they are viewed as not as opinionated.  Just as these server-side frameworks have philosophies the client-side JavaScript MVC frameworks  we’ve been discussing can be examined in the same light on this continuum of opinionated to not opinionated. Let’s look at each of the projects and discuss their philosophy.

Backbone: unopinionated

The most open-minded of frameworks, extremely unopinionated allowing developers to make their own decisions sometimes to the point where things are done differently enough to make the code less maintainable. The only exception to this stance is the way Backbone assumes a RESTful service on the server which I discuss later in the features section. This assumption can be worked around by overriding the sync method on the model.

AngularJS:  opinionated

Pretty opinionated  in particular their emphasis on testability and dependency injection.   Also, the idea that declarative programming such as HTML is awesome are pervasive in the framework.

Ember: Extremely opinionated

Strives for developers to only make decisions about what is different for their application and take care of the rest through convention and scaffolding. This philosophy is similar to the Ruby on Rails and jQuery and is best expressed by the emberjs.com website:

Don’t waste time making trivial choices. Ember.js incorporates common idioms so you can focus on what makes your app special, not reinventing the wheel.

Ember standardizes files and url structures but does allow you to override these things if needed.  Expect to get a lot more code generated for you and a lot more conventional ways of doing things such as file structure.  Consequently, you’ll need to make less mundane decisions because the framework has already chosen a reasonable default and you can get down to the business of building the unique parts of your application.

Knockout : unopinionated

Leaves routing and data storage to the developer’s choice. Doesn’t dictate file or URL structure.  Even allows declarative DOM-based templates to be replaced with string-based. templates

Features

Think of these various Javascript MVC Frameworks as a set of common features to help developers build single-page apps. The way each framework implements these features or chooses not to implement these features and instead makes plugable another library to complete the framework provides critical insight.

So what are the main features of a Javascript MVC Framework?

  • Two-way Binding between HTML and a client-side JavaScript object model
  • View Templates
  • Data Storage (local or through a web server to a database)
  • URL Routing (keeping the back button working and search engines happy)

In addition, some of the frameworks provide common language services such as generic pub/sub event model and support for object-oriented inheritance.

Data Binding

This is the most touted feature of these frameworks. You change the data in an HTML input and the JavaScript object bound to that input is immediately updated as well as any other user interface elements that are bound to that same property.  In many of the frameworks, it goes the other way as well, if you change the JavaScript object the html will automatically refresh.  Its two-way data binding on the web as you’ve always experienced in rich client application frameworks such as Flex, Windows Forms or Windows Presentation Foundation (WPF).  Below is a table showing which frameworks support data binding.

javascript-mvc-data-binding

Some people might argue Backbone and Spine have some support for data-binding but there is enough work left to the developer that I feel it’s safe to say its not a feature of these libraries.

View Templates

The  client-side Javascript model data needs to get interspersed with the HTML and these frameworks take one of two approaches to solving this problem.

String-based templates, of which the most popular is currently handlebars.js, take string or text templates and replace the dynamic parts with data from your models.  One of the frequently cited but debatable advantages to string-based templates is performance.  The cons seem to be difficulty debugging flow of control type logic.

DOM-based templates embrace the declarative nature of mark-up and create an html on steroids experience where html is annotated with additional attributes to describe the binding and events needed.   These libraries require substantially less code but do substantially more magic on the developer’s behalf.

javascript-mvc-view-templates

Model (observable: change tracking)

Some frameworks (Backbone, Spine) are more focused on the model and ask the developer to extend their JavaScript model classes from a base model type and access all properties via .get() and .set() methods so change tracking can happen and events can be triggered when the model changes.  KnockoutJS has the developer apply observable wrappers around your plain old JavaScript objects and then has you access properties via object.propertyName() syntax (notice the  parentheses).

Other libraries(AngularJS) do dirty checking on all bound DOM elements on the page since there are no standard get and set accessors. Which leads to the performance concern that these libraries will have problems on larger pages.   Not only do these libraries require less code to refresh the templates, they also don’t require you to use specific get or set accessors to change data so your models can just be plain old JavaScript objects.   This results in much higher developer productivity, particularly when first getting started with these frameworks.

 

 

Data Storage

These frameworks store data on the server by

  • automatically synchronizing with RESTful services
  • asking the developer to implement do-it-yourself ajax calls to web services returning json
  • allowing either of the above approaches
REST

Some of the frameworks by default assume you have an extremely clean RESTful JSON service  on the server and that you(at least by default) are pretty chatty with that service updating data asynchronously in the background while the user interface continues to respond to the user.   Internally, these frameworks use jQuery or Zepto to send the appropriate AJAX request to the server.  Just as the user interface’s HTML DOM elements listen for changes to the JavaScript object model for the application, the sync implementation gets notified of changes to properties on the model and sends updates to the RESTful service to keep the model in “sync” on the server.

Connected or Disconnected

Backbone by default sends the requests before the data is saved client-side so the server and client stay in sync more easily.  Spine, a very similar framework to Backbone, takes a different approach by saving records client-side before sending the request asynchronously to the server which provides a more responsive user interface and allows for disconnected scenarios frequently found in mobile applications.  If your project requires disconnected scenarios, be sure to understand how well the framework you’re using supports this feature.

Do-it-yourself (DIY)

These frameworks ask the developer to use $.ajax (jQuery) to make web services calls or add another complimentary open-source library to handle data storage needs.

Data Store Specific

More elaborate frameworks such as Meteor have a much more complete data storage story but mandate a MongoDB database on the server.  They do this in an effort to provide an incredibly scalable solution by default and support a JavaScript from top to bottom development experience.

See the table below for a summary of how each framework approaches data storage.

javascript-mvc-data-storage

Routing

Maps URL routes to JavaScript functions to allow for back button support in browsers.  One major downside of single-page applications is that because the page doesn’t refresh no entries get added to the browser’s history so the back button frequently doesn’t take the user back to the previous page state without the developer doing some extra work during those major transitions of state and implementing a state tracking mechanism through a hash appended to the URL or using the push state and pop state in modern browsers.   In summary, most projects either provide very basic rudimentary but useful functionality in this area.   Knockout simply allows you to plug in another third-party open source library.  An exception with routing seems to be Ember which at one point during their project took community feedback and went back to the drawing board to get this right before stabilizing on version 1.0.0.  CanJS also has a more elaborate router that does more than map functions to routes and can maintain more elaborate “states” in an application.

javascript-mvc-routing

Apples to Apples

After looking at the projects by features it became clear to me that I wasn’t really comparing “apples to apples.”  A more fair comparison might be to compare full frameworks like AngularJS and EmberJS with MV* Stacks that include great but less broad libraries like Backbone and KnockoutJS.  To be more specific, the following comparisons would be more “apples to apples”:

  • AngularJS
  • EmberJS
  • Backbone with Marionette
  • KnockoutJS with DurandalJS, and HistoryJS or SammyJS
  • CanJS

I’ll definitely get deeper into this idea in future posts.

Tell Me More

There is a lot to consider when choosing a JavaScript MVC Framework for a project but hopefully I’ve given you a jump start to wrapping your head around these great new technologies.  Please leave comments below and share your experiences with these frameworks from their awesomeness to their sharp edges.

Tags:

96 Responses to “Choosing a JavaScript MVC Framework”

  1. Emmad October 2, 2013 at 12:17 am #

    Excellent work. Thank you.

  2. Fritz October 22, 2013 at 8:27 am #

    With all the emerging js frameworks out there it’s nice to see an un-opinionated overview of the top contenders. Thanks.

  3. Peter Lyons October 22, 2013 at 6:16 pm #

    Excellent work researching and distilling this information. Thanks for the effort!

  4. Jason L October 26, 2013 at 12:05 pm #

    Thank you for this well written, extremely educational post. I found your analysis of frameworks by maturity, size, dependencies and features most especially useful in getting my head around the question “why should I care about JS MVC frameworks?”

    Do you have any experience using these frameworks? For example (in your opinion), in a green-field project does AngularJS’s jqLite implementation rival jQuery’s for main line DOM manipulation / animation tasks?

    Thanks again!

    • admin October 28, 2013 at 4:15 pm #

      Thanks for the kind words Jason. To answer your question “in a green-field project does AngularJS’s jqLite implementation rival jQuery’s for main line DOM manipulation / animation tasks?” I would say for DOM manipulation it rivals jQuery. As for animation I’m still learning and AngularJS is changing rapidly and adding better support for animations. After researching animation a bit more my first reaction was “Wow, that’s a lot of code to do this in AngularJS” but after seeing this screencast I am starting to come around to the declarative and subsequently D-R-Y solutions it allows.
      http://egghead.io/lessons/angularjs-animating-the-angular-way

  5. Jeferson Koslowski December 4, 2013 at 12:45 pm #

    Discourse (http://www.discourse.org/) is a big app made with Ember.js.

    • Dieter December 20, 2013 at 11:36 am #

      Always funny what definition people have of “a big app” ;-)

      • J.P. Hamilton January 7, 2014 at 12:25 pm #

        Big apps have 50-100 and even more screens and take more than a year to finish. Most of the time 2 years. I’d like to see some real information for once on JavaScript apps built at this scale using one of these frameworks. I can make anything work at a small scale. Source: I build big apps.

  6. oktf December 4, 2013 at 1:18 pm #

    Could you address why jquery.js for Backbone (web) is >30k while for other contenders it’s the same size as zepto.js?

    • Craig McKeachie December 4, 2013 at 1:39 pm #

      Yes, that is totally not cool. My mistake. I’ll fix that as early as tonight (if my wife watches the Voice again). To be clear to those reading the comments jquery zipped and compressed should be the 32.6K number for all the frameworks in the web chart. Update: the charts above have now been fixed to correct the issue brought up in this comment.

  7. Adam December 4, 2013 at 1:47 pm #

    Excellent post. Very well written. Thank you.

  8. Scott Reed December 4, 2013 at 2:52 pm #

    Would it be best to collectively target these as MV* framework, I’ve only worked with Angular, Knockout and Backbone but Backbone has no controllers and is more an MVP style, Knockout is an MVVM and Angular is an MVM framework. All the front end developers I’ve dealt to in the UK industry tend to refer to these that way (way being MV*)

    • Scott Reed December 4, 2013 at 2:54 pm #

      Sorry I see you’ve mentioned this in the Apples to Apples part, should have finished reading :-)

    • Craig McKeachie December 4, 2013 at 4:28 pm #

      Scott, I saw your correction but you are right I don’t go deeply into it because it felt like a lot of the existing content on this topic had covered that REALLY well particularly stuff written by Addy Osmani.

  9. Alexis MP December 4, 2013 at 4:05 pm #

    (Disclaimer, I’m on Google’s developer relations team)
    Maybe a section on how these plan to adopt future standards such a Web Components, shadow DOM, etc… would make this awesome work even more awesome.
    Cheers.

  10. Paul Dechov December 4, 2013 at 4:09 pm #

    This is a great overview — very broad and very sober — thank you.

    Unless I’ve misinterpreted them, the dependencies charts give the impression that Backbone depends on jQuery, and that Ember does not. Backbone’s total size is further inflated by the size ascribed to jQuery for just that example: 32 KB.

    In case anyone is interested, this talk comprises a clear and in-depth counterargument to the notion that Angular’s apples are comparable to Ember’s:
    http://youtu.be/7ecsYtRiD5Q?t=56m36s
    Slide deck: https://docs.google.com/presentation/d/1e0z1pT9JuEh8G5DOtib6XFDHK0GUFtrZrU3IfxJynaA/preview

    • Craig McKeachie December 4, 2013 at 4:25 pm #

      Ember does depend on jQuery, thanks for catching that…I’ll update. I’ll check out the talk as well.

  11. Jon Ericson December 4, 2013 at 4:16 pm #

    I think the math is wrong on the tables in the dependencies section. Shouldn’t the total for Spine be 15.6 (the sum of 5.4 + 10.2)?

    Anyway, this is a great article. Love it. Very helpful.

    • Craig McKeachie December 4, 2013 at 4:22 pm #

      I’ll check that out and fix if needed. Thanks. Update: the charts above have now been fixed to correct the issue brought up in this comment.

  12. Alberto December 4, 2013 at 7:18 pm #

    There is an error about CANJS and data binding. It has two way data binding at least since 1.8, see http://canjs.com/docs/can.Mustache.helper.html#section_Returninganelementcallbackfunction and http://canjs.com/docs/can.Mustache.helpers.data.html

    • Craig McKeachie December 21, 2013 at 10:02 am #

      Justin Meyer, lead author of CanJS, was nice enough to offer to help clear up things regarding the framework so you should see some updates soon.

  13. Wilson Tayar December 4, 2013 at 7:48 pm #

    Congratulations on the awesome research work. Your article is very well written and gives the reader a good notion of what to expect in different scenarios.

    Also, I agree with Alexis MP, an overview of the future (if there is any) of these MV* frameworks would be a valuable information.

  14. Abhishek Shukla December 9, 2013 at 12:09 am #

    I am using knockout and its working out great for me till now.

  15. Zeppelin December 9, 2013 at 5:20 am #

    “[Ember is] Intended to control your whole page at run-time so not suited for use on only part of a page.” – Sorry, this is outright false. See: http://emberjs.com/api/classes/Ember.Application.html#property_rootElement

    But this is just one example, as your article contains several more mistakes and leaves out important aspects of the investigated frameworks. While I love the effort you put into helping people choosing the right tool for their projects, I think it’s just fair to present them accurate information from which they can make decisions they won’t regret later.

    What I see is your article is an excellent starting point for making a decent guide about choosing a client-side framework, and I consider it a very good first draft. But since each framework is a huge topic on it’s own, I’d bring in experts to correct the occasional mistakes and help making a truly comprehensive guide for those interested in developing SPAs.

    At least the only thing I’ve yet to read is an article like yours, but written by several people, all experts in the frameworks of their choice, orchestrated by a single author (like you).
    Hopefully I’ll have the chance to read something like that eventually, and I wouldn’t mind if that came from you ;)

  16. JohnC December 19, 2013 at 3:45 pm #

    You have missed something: Ember.js doesn’t have built in REST support; they have an optional ancillary project called Ember-Data which is…well…let’s just say that it is inadequate for many people who have tried it. In fact their own site Discourse doesn’t even use the Ember-data for REST services because it was inadequate. They have been saying they will update and fix ember-data and modernize it now for over a year with no real sign of progress. It’s one of the main reasons we chose Angular over Ember.

    Your information doesn’t indicate any of this however it is very well known and the most common reason people discount Ember.

    • Craig McKeachie December 21, 2013 at 9:55 am #

      Thanks for your insightful/useful comment.
      Yeah I know technically ember.data is a separate open source project and it’s versioned on it’s own…
      but the documentation is on the emberjs site so I think it’s reasonable to consider it part of the ember “framework”
      (I’ll add something to the comments section of the data storage chart to clarify).

      Your insight on it’s maturity is spot on and useful to readers trying to choose a framework today for a project and should be considered. I’ll update the data storage section to add this consideration.

      However, for readers choosing a framework in the future the ember team still considers the ember.data project in beta http://emberjs.com/builds/#/beta/latest and they are very clear on their website what beta means so I think the jury is still out and honestly most of these frameworks don’t really tackle the hard real world data problems they just punt and say “just call a restful service” and from what I’ve seen ember is trying to go at least a little deeper so I’m going to wait and see.

      I found it interesting that you mentioned discourse doesn’t use ember.data I read a post about that as well recently :
      http://eviltrout.com/2013/03/23/ember-without-data.html
      The post also said:
      “Moreover, using AJAX with Ember is something that is not difficult to do.”
      and I agree if all AngularJS provides is a more modern ajax api than jQuery then having to use jQuery isn’t a deal breaker for me….I myself am still trying to warm up to the ember data-binding syntax.

      By the way, discourse as an end user is freaking Awesome…thank you Jeff Atwood and team.

  17. Adrian Miu December 19, 2013 at 4:41 pm #

    Sorry to see CanJS is not one of the more popular choices. The syntax very is close to Backbone (Models, Views, Collections) and it does a lot more out of the box. It can do WebComponents ( in version 2 which was released after this article was published), can be used with jQuery, Zepto, YUI, mooTools… It is worth mentioning it’s build by the same company that created JavascriptMVC , one of the first javascript frameworks (second after Dojo if I’m not mistaken).

  18. Tim K December 19, 2013 at 5:30 pm #

    Awesome. We need more of this, review, compare & contrast, consolidate

  19. wheresrhys December 19, 2013 at 9:17 pm #

    Great article. I think I found one factual error though: ‘ they also don’t require you to use specific get or set accessors to change data so your models can just be plain old JavaScript objects. ‘ – this is true of angular but not true of knockout, which uses special observable objects.

    Looking forward to reading your apples to apples post

    • Cameron Spear December 21, 2013 at 2:59 am #

      Yeah, I’m with you on this… I think the author made a mistake there? Unless KO changed in the past year or so, you had to use getters and setters.

  20. A. Plutov December 20, 2013 at 3:31 am #

    The best article about JS franeworks. imho, not all listed tools I can call “framework”.

  21. Leonardo December 20, 2013 at 4:48 am #

    Very good! Thank you!!

  22. Jon Merrifield December 20, 2013 at 6:25 am #

    You mention that with Knockout, ‘models can just be plain old JavaScript objects’ but this is only partially true. Granted you don’t need to inherit from a base model, but each attribute must be wrapped in an ‘Observable’ for Knockout to respond to changes in the data, so it *is* necessary to use specific accessors to change models.

    • Craig McKeachie December 20, 2013 at 11:51 pm #

      Thanks for catching that see the similar comment above for my thoughts.

  23. Tomas December 20, 2013 at 7:02 am #

    Useful post. Got some idea about JS frameworks and what they are for. Now I’m going to study each in more details.

  24. Puneet December 20, 2013 at 8:25 am #

    Few small corrections regarding Knockout:
    1) It does not have dependency on Sammy (used to have many months ago)
    2) It does not have dependency on jQuery
    3) It does not do dirty checking like Angular. It is based on Observables, which are supposed to be more efficient than dirty checking, which is done in Angular

    • Craig McKeachie December 21, 2013 at 11:14 am #

      Thanks for your input:
      Points 1 and 2 I was careful to say dependencies needed to actually build an an app with a library not dependencies as in the library doesn’t work if you don’t have this other library which I think is how you are using dependency and how most people think of it.
      Point 3 I was incorrect and lots of people let me know it :) and I have updated the article.

    • Winston Fassett December 23, 2013 at 1:09 pm #

      This is an important point, as it makes Knockout the most lightweight solution at roughly 26.1k based on your tables. And that is still including knockout.mapping, which is also optional.

      To elaborate on the jQuery option, Knockout does not require a DOM manipulation library. Its DOM bindings are an elegant alternative to the jQuery style of DOM manipulation which tends to rely on ids, style classes and DOM queries to identify nodes to manipulate. The Knockout approach obviates the need for all of those things in favor of a write-only DOM with DOM manipulation encapsulated in bindings.

  25. Chris G December 20, 2013 at 10:43 am #

    Masterful article. I love that you’ve provided a deep dive into the compare/contrast of these frameworks/libraries. It’s people like you who make me a better informed developer. Thank you!

  26. hipertracker December 20, 2013 at 11:57 am #

    Durandal is a full stack modular framework using Knockout and RequireJS. Knockout itself is rather an advanced dual-binding library than a framework.

    • Craig McKeachie December 20, 2013 at 11:49 pm #

      Correct, as I said I’ll get into this more in a future post. I see the term two-way data binding most of the time not dual-binding.

  27. Dave Crane December 20, 2013 at 12:20 pm #

    Hi Craig,

    Great article, very thorough and methodical!

    One small correction. You wrote in a section on Angular and Knockout:

    “they also don’t require you to use specific get or set accessors to change data so your models can just be plain old JavaScript objects” – this isn’t the case for Knockout. If you want it to automatically fire events for model properties when they change, you need to wrap the properties as ko.observables (or observableArrays, or computed’s, etc.) – so it’s possible to control the performance overhead by only wrapping some model properties as observables, and leaving others as plain object properties.

    • Craig McKeachie December 20, 2013 at 11:43 pm #

      You’re right, a couple other people caught that as well, I’ll fix that part of the article soon. Since you can apply the observables on top of a plain old JavaScript object and access properties via object.propertyName() syntax I feel like there wasn’t as much in my way as backbone’s get and set methods but you are right it’s definitely not just a plain old JavaScript object. See how isDone() is accessed in this example to clarify what I’m talking about.
      http://learn.knockoutjs.com/#/?tutorial=loadingsaving

  28. Lindsey December 20, 2013 at 1:27 pm #

    You’ve got Ember listed as “Built-in” for Data Storage, which isn’t right – Ember Data is a separate project that isn’t required to use Ember. Discourse, for example, uses straight jQuery ajax calls.

  29. lior December 20, 2013 at 1:52 pm #

    Great research.
    The only part people forget when testing whats best for the project is memory use and initiation time.
    When we added angular it doubled the js load time for the page to be ready with all js modules.

  30. Scott Burch December 20, 2013 at 2:15 pm #

    I have worked with Meteor for over a year now. Several of the things stated in this post about Meteor are wrong and some are possibly just a bit off.

    For example, your table shows Meteor as having URL based routing. This is not true. Meteor does not have two-way data binding, and it is not required to use MongoDB.

    Meteor is quite open in how you use it once you understand how it actually works.

    • Craig McKeachie December 20, 2013 at 11:34 pm #

      Meteor is definitely the framework I am least familiar with …I haven’t been wasting too much energy on it until I heard it maturing. I did notice it was the one framework the other framework authors had a lot of respect for so I’m anxious to learn more. I’d love to hear about your experiences if you can spare some time for me.

  31. syndrael December 20, 2013 at 2:27 pm #

    I don’t know every frameworks.. only AngularJS and KnockoutJS. They’re not MVC frameworks but MVVM !!
    Am i wrong ?

    • Craig McKeachie December 21, 2013 at 10:52 am #

      KnockoutJS is clearly stated to be MVVM and inspired by RIA technologies that use MVVM such as Silverlight and Flex as I mentioned in the post. AngularJS I’m still good with calling it MVC. Backbone sparked a lot of the interest in this debate because it originally shipped with what is currently the Router called the Controller (this has been long ago changed) and a lot of stuff that developers familiar with MVC on the server (Rails, ASP.NET, etc….) expect to be in the Controller is in the Views…which once you get used to it is not bad but just different I think. I called the article MVC frameworks when it would have been more accurately named MV* Frameworks but to be honest I don’t think people who this article will be helpful to will search for MV*. The other thing is every time I read an article on which pattern this framework follows I don’t feel like I’ve learned anything that will help me building applications in the real world with these frameworks.

  32. kasperlitheater December 20, 2013 at 2:56 pm #

    Why is ExtJS never mentioned in those roundups? Is it in another category?

    • Djmm187 December 22, 2013 at 2:26 pm #

      I agree. ExtJS should have been included .

  33. Ambrose Little December 20, 2013 at 4:03 pm #

    Extremely well done. Thanks for the effort.

  34. Mark December 20, 2013 at 10:36 pm #

    great to read an unbiased and factual article on these frameworks.

  35. Muhaimin December 21, 2013 at 12:06 am #

    thank you for the post. Really help in the selection of best script. I already use backbone and now become more clear on what other are using and why they choose it

  36. Hsin Desu December 21, 2013 at 6:14 am #

    Great to see that such quality writing and research still exists online. Thanks for all the work you’ve put into this!

  37. Josh Habdas December 21, 2013 at 4:40 pm #

    I didn’t see an opinion and I’m not about to fight against GFS (Google Fanboy Syndrome), but honestly, if you haven’t programmed with Brunch with Chaplin you haven’t experienced bliss, and I can’t read your article.

  38. Fernando December 21, 2013 at 5:00 pm #

    Great post. *Claps*

  39. Charlie December 21, 2013 at 7:33 pm #

    Thanks for this great article, very informative.

  40. Julien Gilli December 22, 2013 at 5:44 pm #

    Excellent article, thank you. And thank you too everyone who contributed insightful comments. Now I’m really looking forward to reading your book and other articles of this quality.

  41. Ashwin Hegde December 23, 2013 at 6:10 am #

    Excellent article. Made me very clear regarding MVC over Client-Side.

  42. Alvin Crespo December 23, 2013 at 12:31 pm #

    This is a great breakdown on JavaScript MVC frameworks. Thanks so much for your research and help on this, I couldn’t have done a better job. Cheers!

  43. Urvil mehta December 24, 2013 at 2:24 am #

    Please have a look at enyojs and suggest your opinion on same.

  44. Aditya Saxena December 24, 2013 at 3:55 am #

    This.Is.Awesome!

  45. Arul Prakash December 24, 2013 at 6:29 am #

    Thank you for an excellent post.

    While Ember seems to be a good choice to get started without a learning curve, The best way is to choose a framework which maintains the balance between flexibility, performance and convenience. So backbone.js just hits the spot, though I wish they had better user generated content ( examples & documentation )

  46. Ahmed Assaf December 24, 2013 at 7:27 am #

    Keep up the Good Work :)

  47. Arvraepe December 24, 2013 at 4:58 pm #

    Thank you so much for taking the time to write this down. It was a nice and very interesting read!

  48. Harmeet Singh Bhamra December 25, 2013 at 6:32 am #

    Very well written, appreciate the excellent work !
    Helped a lot to understand about JS frameworks….thanks for sharing :)

  49. Leonardo December 26, 2013 at 2:20 pm #

    What about DOJO framework?

  50. Kishore December 27, 2013 at 10:23 am #

    Excellent work.. *Cheers*

  51. Mayra December 30, 2013 at 2:10 am #

    Awesome post thanks!

  52. Kim December 31, 2013 at 2:08 am #

    Hi Craig. Probably worth linking up in the comments at least so other readers can view both of our research articles. Please also leave a link in my comments. http://blog.binarymist.net/2013/12/28/evaluation-of-angularjs-emberjs-backbonejs-marionettejs/

    • Craig McKeachie December 31, 2013 at 5:38 pm #

      The link above was another great post on the topic I came across recently.

  53. Rob Eisenberg December 31, 2013 at 9:27 am #

    Definitely check out Durandal: http://durandaljs.com/ since it’s a more appropriate comparison than Knockout. We’ve also got a tech demo of our next gen here: http://www.kickstarter.com/projects/eisenbergeffect/durandal-2014/posts/703625 It blows away everything that’s currently available. We’re currently running a kickstarter to help raise funds so we can dedicate the time to bringing it to production (among other goals for the project). I hope everyone that’s interested in this topic will have a look.

  54. Dave Combs December 31, 2013 at 1:14 pm #

    I was curious, given its maturity and size, why YUI wasn’t mentioned? Regardless, thanks for writing a very informative and unbiased article!

  55. Roberet Gray December 31, 2013 at 5:23 pm #

    OO-Yah! Great work! Putting together a comparison of this type takes a lot of effort. Thanks. You have saved many of us countless hours of research and covered the topic more completely than most of us would have time to do. Kudos. You have given me a fantastic head start on selecting a JavaScript Framework ( or Library).

    • Craig McKeachie December 31, 2013 at 5:37 pm #

      Thanks! Comments like this really help keep me motivated as I work on my book in the next few months.

  56. Andrew January 2, 2014 at 12:38 pm #

    Great post, but if the author really read the internet about the topic, he would notice that Dojo is a very mature, tested toolkit that on top of MVC provides many other useful features. If you have an appreciation for well structured JavaScript, decent build and dependency management tools, give Dojo a look.

    • Andrew January 7, 2014 at 5:52 am #

      Andrew,

      I’ve had a brief look at dojo but not enough to ascertain it’s drawbacks. In your opinion what are the pros and cons compared to roll-your-own?

      Regards,
      Andrew

  57. HRA March 18, 2014 at 12:28 pm #

    Nothing about Sencha ExtJS ???

  58. googya June 28, 2014 at 3:10 am #

    As a Rubyist, I love Ember.js more!

Trackbacks/Pingbacks

  1. Linkdump for October 12th | found drama - October 12, 2013

    […] Size Does Matter: Choosing a Javascript MVC Framework Craig McKeachie doing some side-by-side, feature-for-feature comparisons of a couple JavaScript MV* frameworks. His emphasis is mostly on AngularJS, Backbone.js, Ember, and Knockout, but a couple of other libraries make cameos as well. The title is a little misleading because he's talking less about the size of each framework and more about how "rich" each one is. He lays out some good points w/r/t/ things you should consider when choosing such a framework (and/or whether you should choose one at all). (tagged: KnockoutJS Backbone.js MVC AngularJS JavaScript Ember ) […]

  2. Choosing a JavaScript MVC Framework « Boardmad - December 4, 2013

    […] source: Choosing a JavaScript MVC Framework […]

  3. Choosing a JavaScript MVC Framework | Enjoying The Moment - December 4, 2013

    […] via Hacker News http://www.funnyant.com/choosing-javascript-mvc-framework/ […]

  4. Coder Read #20131205: Choose Your Right JavaScript MV* Framework | Coders Grid - December 4, 2013

    […] http://www.funnyant.com/choosing-javascript-mvc-framework/ […]

  5. Choosing a JavaScript MVC Framework | Bonnes Pr... - December 6, 2013

    […] So you love the way single-page apps like Gmail and Trello feel, but aren’t sure where to start.  […]

  6. Choosing an MVC Framework, lrNotifier - InfoLogs - December 19, 2013

    […] on something that isn’t the right fit for your project. Craig McKeachie sent in his article, Choosing a JavaScript MVC Framework, which reviews the most popular libraries like AngularJS and Backbone.js. He takes into account […]

  7. choice of javascript mvc framework - December 24, 2013

    […] out there, there are plenty more. I am sure you don’t want to miss this train so jump into this well written article by  Craig McKeachie. He wrote it back in September, but not many things changed since then except […]

  8. Choosing a JavaScript MVC Framework | Web Devel... - December 26, 2013

    […] So you love the way single-page apps like Gmail and Trello feel, but aren’t sure where to start.  […]

  9. My links of the week – January 5, 2014 | R4 - January 12, 2014

    […] McKeachie’s Choosing a JavaScript MVC Framework is an excellent and comprehensive overview of the current popular choices for Javascript […]

  10. Input 2014#03 | Klaus Breyer - January 19, 2014

    […] Choosing a JavaScript MVC Framework - Topaktueller und ziemlich ausführlicher Beitrag, welches Javascript Framework was denn jetzt eigentlich was kann. react.js fehlt dabei leider. Aber irgendwas würde bestimmt immer fehlen. :) […]

  11. An Interesting List of Development Stuff (January 2014) | rionscode - January 24, 2014

    […] Choosing a Javascript MVC Framework […]

  12. Angular JavaScript | DucQuoc's Blog - March 5, 2014

    […] of the masterpieces is jQuery. Another is NodeJs. And for “next-generation” frameworks, there are quite a few ones which are pretty potential and awesome to create full front-end for web […]

  13. OCTO talks ! » Edito March 2014 - March 12, 2014

    […] an article from Craig McKeachie providing a map of Javascript MVC frameworks as of September 2013 : Choosing a JavaScript MVC framework. Instead of doing a simple comparison based on features, Craig is opposing different aspects : […]

  14. Decentralized Micro-Manufacturing Network and Project Platform - Page 2 - March 28, 2014

    […] Backbone.js is compatible in a large extend with zepto. And if you look at some stats here: Choosing a JavaScript MVC Framework. You can see a comparision of the sizes of different frameworks. Ok I might be pushing it too […]

  15. Angular, Links And Resources (3) | Angel "Java" Lopez on Blog - April 18, 2014

    […] Size Does Matter: Choosing a Javascript MVC Framework | Funny AntFunny Ant http://www.funnyant.com/choosing-javascript-mvc-framework/ […]

  16. Backbone, Links And Resources (4) | Angel "Java" Lopez on Blog - April 21, 2014

    […] Size Does Matter: Choosing a Javascript MVC Framework | Funny AntFunny Ant http://www.funnyant.com/choosing-javascript-mvc-framework/ […]

Leave a Reply