The Popular MVC Frameworks in Town
- 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
- 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
- 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
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.
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.