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:

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.

I think that Backbone gives you most of what Flight gives you but not necessarily the reverse. Backbone also has a *lot* of proven success. Not to be like “no one was ever fired for choosing X” but a proven track record is definitely worth something.

>>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.

The twitter.com front end is built entirely on flight and is purely event driven. There is no model on the client. We found it scaled beautifully without the needing to ratchet up the complexity and ramp up time for new developers is very short. We certainly didn’t have to re-implement backbone’s tools.

I must admit my wording too strong! Twitter.com is definitely a full featured app. Given your other comment I see that its more about separation of concerns. I do see how you could leave the data on the server and drive the UI views directly from calls to the backend. It would be awesome if the Flight team could document some of the best practices and tools for providing a client side data model or delegating it to the server.

BTW data shim for demo purposes only. Whether your real-life apps have models and where they live is entirely up to your dev team. twitter.com has a server-side model; tweetdeck, which is also built on flight, uses a client side model

I am coming from a lot of PhoneGap development, where long-lived disconnected state and dicey connectivity is more of an issue. Those experiences have definitely biased me towards having a more robust client side state. I can see the attractive simplicity of displays that are always driven off of network requests.

To underscore the more specific points Angus has made. We aren’t saying that Flight obviates the use of models in cases where they make sense. It just doesn’t couple itself to that idea. You are right in thinking that someone might end up building a model framework on top of Flight components. I like to see that. Like Angus says, we are less enthusiastic about client-side MVC that most, but if you want that you can have that. Think of Flight as being a framework you could build something like Backbone on top of rather than a direct peer to Backbone.

I’d have to agree with Angus here. Components consume only the data they require to work, so when we fire events they contain as little data as possible. Applying a fixed model over this would reduce flexibility and increase complexity, as well as increasing the amount of boilerplate required to get started.

I love the simplicity of Flight. So far we have not had any problems managing data, except perhaps when we’re trying to integrate our old, heavyweight data objects in to new flight components.

One thing I am curious about is restoring the state of a complicated UI. If you have a model and the model drives the UI state then you can transmit and de-serialize the user’s current state and the UI will fall into place. If the UI is always and only a stream of events and there is no model then how would you handle this?

Interesting parallel from chess transcribing comes to mind: the older pgn notation which described only the latest move (event) was replaced by the newer FEN notation (serializable) which describes full postion and player states at any given move–
where I’m headed with this is can you derive a model to serialize?

[…] Ean Schuessler talks about the “Models” in flight not being powerful enough. I gave this a long, hard thought. However, as Flight relies on events more than model data as such, data binding is completely. It is more of an event/DOM first approach; Similar to how Models are different in Angular as against Backbone. In Backbone, the Views are derived from the Models; Here, it is the other way round. […]