I just rolled off my last project this Wednesday. It was a great team, worked on some cutting edge technologies, mobile web, HTML5, mongo and some other fun stuff. Now that I got two "beach" days before jumping on to the next gig, I spent some time trying out Backbonejs to knockout one item from the long list of to-dos. This post is about my initial take on client side MVC, solely based on these two days with Backbonejs.
Using such events, it becomes a trivial process to keep all the views in sync with the models as they change across different actions.
Another advantage of client-side MVC is, it forces "eat your own dog food" as you are essentially creating an API on your server and using it first hand on the client side. So, if you are building multiple clients, for example, native mobile clients and browser web apps, you can leverage the same API.
I find the backbonejs MVC to be a little weird, they have Model and View, but no Controller. Instead they have a Router and a confused concept of Collection. So, for example, if you wanted to work on a resource called Vehicle, you will probably end up with the following "classes":
Vehicle model, Vehicles collection, Vehicle view, Vehicles view and Vehicle router
But as you can see here, there is no Vehicle controller. I know you can always write a controller on your own, but thats the whole point about having strong opinionated conventions.
The relation between a Collection and its Model can be confusing, specially when wiring up events. For example, a change in a model can trigger the view for the model and/or the view for its collection. The logic for handling/bubbling such events can get quite messy at times.
Summary
Client-side MVC is in its infancy, but promises a bright future
The Good
Writing "clean code" while doing Javascript can be quite a challenge. Doing MVC gets you a step closer to that by splitting responsibility among models, views and controllers. So, your Javascript code will be domain driven, instead of just a bunch of monolithic methods.
Your client-side MVC application can be very responsive, or even a "single page app". This is an advantage if your app needs some data from the server, but can leverage Javascript for most of its visual needs. For example, a real-time analytics dashboard can use client-side MVC to do most of the processing on the client side after fetching the data from the server.
Backbonejs offers event wiring API between your models and views. For example, say you have a model called Vehicle and a view called VehicleView, you can put the following code to wire up the "change" event on the model so that the view renders whenever the model is updated.
Using such events, it becomes a trivial process to keep all the views in sync with the models as they change across different actions.
Another advantage of client-side MVC is, it forces "eat your own dog food" as you are essentially creating an API on your server and using it first hand on the client side. So, if you are building multiple clients, for example, native mobile clients and browser web apps, you can leverage the same API.
The Bad
Ever since Ruby on Rails came into the game, we all became keen on having conventions. Can't speak for the rest of the client-side MVC projects, but Backbonejs definitely lacks in this regard. It doesn't default to any view template. Also, it doesn't have a default project structure. And even worse, no in-built testing recipe either. This means, you are left on your own to choose and debate about each of these, and more that just these, to find a standard set of tools for your project.Having no in-built test framework reduces the emphasis on testing, this is a Big Big lacking.
I find the backbonejs MVC to be a little weird, they have Model and View, but no Controller. Instead they have a Router and a confused concept of Collection. So, for example, if you wanted to work on a resource called Vehicle, you will probably end up with the following "classes":
Vehicle model, Vehicles collection, Vehicle view, Vehicles view and Vehicle router
But as you can see here, there is no Vehicle controller. I know you can always write a controller on your own, but thats the whole point about having strong opinionated conventions.
The relation between a Collection and its Model can be confusing, specially when wiring up events. For example, a change in a model can trigger the view for the model and/or the view for its collection. The logic for handling/bubbling such events can get quite messy at times.
