View From The Front: JavaScript MVC Frameworks Crash Course

JavaScript MVC Frameworks

The Rise of JavaScript MVC Frameworks

There was a time when front-end web authoring technologies were the “V” of MVC frameworks. As user interaction became more complex, JavaScript MVC frameworks became necessary in order to meet those needs. In this article, you’ll get the gist of what’s popular today, and what’s on the horizon tomorrow.

When to Use A JavaScript MVC Framework

JavaScript MVC frameworks aren’t suitable for every project, but for the right projects, they are clutch. These include single page apps, pages with large datasets being frequently requested and changed, pages with complex user interactions, or likely all of the above. e.g. WordPress and Drupal dashboards.

The Popular MVC Frameworks in Town

There are currently three popular open source JavaScript MVC frameworks:



  • Easy to onboard and take to cruising speed
  • Maintained by Google developers (curiously, no notable Google project to date was written in it)
  • Has the most adoption and buzz among its peers, along with an active Github repo
  • Lots of Silicon Valley startup projects use it, hence more available expertise out in the wild
  • Lots of Angular modules and 3rd-party directives


  • HTML markup-purists object to its unconventional “ng-” directives polluting the markups
  • Too many unresolved pull requests and bugs
  • Core team declared there will be no new features until version 2 and the upgrade path is uncertain (more on this later)
  • Open-ended framework leaves lots of trivial decision-making to developers



  • Considered the “grandfather” of JavaScript MVC frameworks; very stable APIs
  • Extremely flexible, easy to onboard and be productive in
  • Robust documentation and plenty of resources on Google and StackOverflow
  • Small and lightweight in size
  • Suitable for projects of almost any size


  • Development has been stagnated since version 1.1.x; lack of forward momentum inspired projects like Marionette to consolidate and organize common Backbone patterns
  • Its simplistic approach means many technically trivial choices are deferred to developers which could mean more code
  • It’s easy for the codebase to look very different in parts of the same project (even for a small team of three developers) if there’s no established and enforced coding conventions; this leads to unmaintainable projects



  • Maintained by established JavaScript and Rails veterans (this translates to arguably better framework architecture)
  • Runs on “convention over configuration” methodology — “Magic” happens if you follow conventions (e.g. you rarely have to handle ajax anymore); this has added benefits:
    • Internal dev team does not have to reinvent common patterns and conventions, implicitly enforcing code consistency
    • Trivial technical design decisions are handled by the framework (e.g. ajax lifecycle, event (re)binding… etc)
    • On average, you write a lot less code
  • Active community with a busy Github repo
  • Clockwork six-week release cycle
  • Framework rapidly evolves and features are added through a transparent and community-driven process; major API changes go through RFCs for feedback; “The Road to Ember 2.0” RFC is a great example (contrast to Angular); this leads to predictable and less stressful upgrade visibility
  • Active #emberjs and #ember-cli IRC channels (gasp!) for almost real-time support
  • Shipped with a test framework built right in!


  • More painful ramp up than other frameworks (ember-cli, node.js dependency… etc)
  • Emphasis on conventions can turn off some developers
  • Rapid release schedule can take its tolls:
    • Conflicting and outdated documentation
    • Google search and StackOverflow results often contain outdated solutions
    • Time allocated to framework upgrades adds up if you want to keep up (you should); fortunately this is mitigated by well documented release docs
  • Existing in-house JavaScript libraries may need modifications to work with Ember

The Current State of Affairs

Angular announced in its v2 roadmap that there’ll be no upgrade path from existing Angular versions. I can’t imagine large Angular apps being rewritten to compensate for the Angular team’s lack of foresight. The roadmap also deferred all new features to v2, which effectively orphans the current Angular 1.x project.

Backbone has seen slow but steady releases. There’s no sign of the framework going away or seeing major upgrades. I don’t expect this to change soon. But it’s mean, lean, easy and works right now.

Ember has the least adoption of the three. But it garners a disproportionally active community with rapid releases and new features. Unlike Angular, the Ember core team pledged a clear upgrade path to Ember v2, to be released in 2015.

Parting Thoughts

Angular’s core team has painted itself into a tough corner. Until a clear upgrade path is announced, you should steer clear of Angular for projects besides throwaway prototypes. Then there’s Backbone, a safe bet for projects big or small — A gateway MVC framework before diving into other beasts. But be mindful of the freedom it affords. Ember is a tough nut to crack, but once your team gets used to its conventions, the architecture will redeem itself with less code, implicit code style consistency and easier cross-team collaboration.

Before you decide on a framework, visit ToDoMVC and take all the different JavaScript MVC frameworks out for a spin. Decide for yourself what’s best for your projects. With the Javascript community moving to ES6 modules (using compatible transpiling), whatever framework you choose, be sure to put that on your checklist for forward compatibility.

Happy coding!

Shun Chu

Profile Photo

Leave a Reply