Response to UI Technology Paradigm Shift by Paul Hammant

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.

When we spoke, Paul quite rightly raised the key risk today being that the number of frameworks is likely to continue to grow and each one may end up taking the best features from the others while reimplementing them in their own way causing further fragmentation. 
 
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!)
I believe we need to step back a little further and look at what is going on and what we need.
 
What’s going on? Well, innovation obviously! We are in the middle of a (client side) Javascript and Coffeescript Renaissance and we’re lucky enough to be standing on the shoulders of giants while applying new techniques to make even more interactive client side applications (and HTML5/CSS3 isn’t so bad either!).

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? 

Maybe we just need to agree on the components for a good client side app and allow for different configurable distributions like Brunch?

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). 
Alternatively, split Backbone into 3 modules: 1) Routing (Routers/History), 2) ORM (Models/Collections), and 3) Controller (View). Then, request proposals from the community for a replacement for the Controller (View) module (or even consider deprecating it) because with all of the recent innovations in the MVC space, there are already much better ways to do it.
Tear down these walls!