Since then I’ve been thinking a lot about client-side MVC. Rather than simply mentioning frameworks like Backbone.js as part of regular roundup style posts, I thought it might be useful to dig a little deeper into the client-side MVC phenomenon.
The Elephant in the Room
We’re stuck with the term “MVC”. It’s not an accurate way to describe what frameworks like Backbone.js do, but to avoid confusing matters I’ll stick with it for now. Some libraries and frameworks seek to differentiate themselves by using more accurate terms like MVVM (Model-View-View Model).
Terminology aside, most client-side developers are probably in a position where they think they need something like Backbone.js, but aren’t entirely sure what it does, how it does it, and what else is out there. Furthermore, is it worth investing time learning Backbone.js only for someone to replace it with something more cutting edge? The field is definitely changing fast – as single page applications are now commonplace, their associated techniques are cropping up on traditional websites. It’s clear that client-side development requires more investment in the architectural side of development. Organising code with mature techniques lifted from the classic Design Patterns: Elements of Reusable Object-Oriented Software is just the beginning.
The choice of frameworks is bewildering. TodoMVC provides implementations of a to-do app in more frameworks than anyone has time to learn. Choosing the right framework for a given project is only the start of the problem, however. The real issue is learning how to use the framework correctly. It’s very easy to write “anti-patterns” with something like Backbone.js, and quickly get into a spaghetti code mess.
Choosing the right framework and using it well comes down to knowing what you need. If you’re in the position of thinking you might need a client-side MVC framework, but you’re not sure why, then my advice is to get your hands dirty. Take a look at how these frameworks are built, and what they provide. Eventually you’ll see similarities between them, and see how to apply their features to your own projects.
Forget Models and Controllers
Forget terms like models and controllers for a moment, and consider these frameworks at a higher level.
Knockout: Uses data bindings to automatically update the interface based on changes to data. Doesn’t provide client-side routing or data synchronisation with a server.
These two frameworks are very different: Knockout focuses on automatic data binding to keep the UI in sync, and offers tools to write reusable view-oriented code to do this. Conversely, Backbone.js requires the user to manually wire up events between the interface and data, and instead makes it easier to integrate with RESTful services and create modern single page application using the routing API.
If I was writing a single page application backed by a RESTful service, I may opt for Backbone.js. However, if I was writing a more traditional web app with complex data-driven templates, then Knockout might be a better fit.
So, Which MVC Framework Should I Use?
Set aside hyperbole and stop worrying about which framework implements MVC correctly. Instead, look at each framework in relation to your project and requirements at a high level.
In the upcoming weeks I plan to further demystify MVC frameworks by exploring the patterns and anti-patterns. I’d also like to look at some of these frameworks in more depth in some upcoming code review style posts.