Twitter Flight vs BackboneJS

This blog post started out as a private email but I’ve seen a few other articles tackling the same topic. I thought I might fish some good feedback out of the ether if I made it more public.

I’m involved with an effort to improve the JavaScript UI for the Eucalyptus Cloud Management product. Lately we have been examining whether Twitter Flight or BackboneJS represents a better way forward. Flight provides very good infrastructure for managing events. Perhaps somewhat questionably, they extend this excellence into an argument that there is no need to manage the model or the flow of data back and forth to the server. From the Flight site:

While some web frameworks encourage developers to arrange their code around a prescribed model layer, Flight is organized around the existing DOM model with functionality mapped directly to DOM nodes.

Not only does this obviate the need for additional data structures that will inevitably influence the broader architecture, but by mapping our functionality directly onto the native web we get to take advantage of native features.

I don’t know whether they are trying to say that the need for models is “obviated” entirely or merely that it can be decoupled from the view event management framework. Even if they believe its the former their own code speaks to it being the latter. When you examine the Flight demo mail app you find an anemic sort of model infrastructure managing “contacts” and “mail” with plain-jane collections of objects:

You can then see those collections being used to populate views:

This is really very similar to Backbone except with far less power and utility. In Backbone, there are tools for paging large data sets, synchronization of collections with the server, transparently storing data and a lot more. If you aren’t familiar, glance over the capabilities it provides here:

If you wanted to extend Twitter’s demo mail app into something full-featured like Zimbra or RoundCube then it doesn’t take much imagination to see yourself, piece by piece, re-implementing the tools that Backbone already provides.

There is no doubt that Flight is innovating in the view space. They also seem to have added some real value managing the UI view lifecycle and tearing down resources. I must admit that I am attracted to the picture they are painting. At the same time, I am sure that a UI event infrastructure does not an application make. Any serious effort is going to find itself in need of a robust infrastructure for managing the movement of data between the client and server. I would love to see a fusion of Flight’s events with Backbone’s models. This kind of decoupling and “small sharp tools” is the stuff that developer dreams are made of.