Before writing his post, Paul and I briefly spoke about the “state of union” given the proliferation of MVC/MVVM client-side micro frameworks. He raises some important points in his post posting and it is a good read to complement this MVC frameworks comparison table.
What this means to me is that:
- we will end up with a too many frameworks with brilliant pieces and also not so brilliant pieces, but we will be forced to take the good with the bad rather than just take the good (if you’ve looked at Sproutcore 1.x, you know we are all fortunate that Yehuda Katz was involved with Ember/Sproutcore 2.0)
- programmers will need to jump from framework to framework whenever they change projects that have chosen yet another, slightly different MVC/MVVM framework until things consolidate. As each framework grows, their communities will need to devote more time to not only help programmers up the learning curve, but also to explain common solutions and best practices given their specific framework (Knockout is amazing at this by the way!)
But what do we need? I believe we need to have the flexibly to pick and choose. Some personal examples:
- Backbone’s Models and Collections are really quick and intuitive to learn, but their View (or partial-Controller) implementation is quite limited. Combining Backbone with Knockout into Knockback allowed me to iterate quickly and make beautiful, dynamic Views (easily using multiple Backbone models per View) with a templating engine that I was comfortable with.
- jQuery Mobile’s default approach is a page per screen so they implement history and screen transitions as part of their framework. I originally chose JQM hoping that their Themeroller would be great for a designer, but each new release required me to disable more of their code to quickly get a single page app working again
So how do we pick and choose? I like Rails 3 modularity and believe it should be used for inspiration. Do we need modules like Active Resource, Action Contoller, Rack middleware-compliance, etc? Do we use CommonJS/RequireJS/AMD, a nano-framework framework like Mixin, or just use conventions?
I believe development teams should be able to make choices like between Pathjs or Backbone Routers for history/routing, eco or Mustache for templates, Backbone or Spline models, Backbone Views or a binding library like Knockout, Sprockets or Brunch for asset packaging, Less or SCSS or CSS for stylesheets, etc.
And if something better comes along, taking a modular approach now should make it easier to replace a single component and its touch-points rather than being forced into an “all of nothing” decision down the line (which is almost never a good thing!).
Best of all, rather than make a huge upfront MVC framework decision you can incrementally and iteratively choose the best available modules for whatever will make your client side application standout and be incredible!
To put my money where my mouth is…I would welcome a larger community like from Backbone to reverse-takeover Knockback and make it into a standard (but separate!) Backbone Model adapter library for different binding libraries like Angular, Batman, or something new (but not in the Backbone Model/Collection core).