Twitter’s Flight JS Framework: First thoughts and comparison with Backbone

posted in: Javascript | 5


Twitter released earlier today a new JS framework called Flight. You can check it out at Github

After reading the documentation, downloading it, and trying it for a while, I’ve my first thoughts.

Basically, what this framework provides is a way to create components. Each component is then “binded” or “assigned” to a certain node in the DOM element. This node can be a div, span, table, button or any other HTML element. That component will take care of all of the actions regarding it’s elements. It could be change one element’s color, adding another text, handling a button click or receiving custom events. Each component can trigger and “listen to” custom events or DOM events. This is the only way components can communicate with each other, as they’ll never know another component. It’s a 100% decoupled. I think this sums up what the new framework is about.

Now, some comments about this implementation:

I love and hate an event model at the same time. In one way, it’s 100% decoupled with actually rules, as you can reutilize each component wherever you want. However, working with events make it almost impossible to debug your code. You see tons of events “flying” around, with no easy way of knowing who, when, where and why each event was launched. It can be debugged, but it can be painful at first. So, it’s a tough call, but I actually still like events. I think that a way to debug this events easily should be added somehow.

Each of this components reminds me to Backbone’s View object. Backbone is a very well known MVP for JavaScript. In backbone each view is binded to an element as well, which can be received as a parameter, and then you can hook to both dom events and custom events. However, Backbone also has a Router (to handle URL changes via HTML5′s pushState or #!), models (Which can call your RestAPI easily) and that’s it.

However, in Backbone, one View can have a nested view or a list of nested views inside. So, imagine that you have an ul which is a Component or view. And, you want to dinamically add a lot of Li’s with some configuration. I haven’t found a way of having a Component “know” its child components in Flight. I know that that’s part of the architecture of no component knows another one, but I think that for child components, they should make an exception. I don’t think that a parent with its child should communicate via events. So, I do like that of Backbone and not on Flight.

What does Flight do really well? In my opinion 2 things.

1) Mixins. I love Flight’s mixins. You can create some “common” behaviour that can then be easily added to any component. So, let’s assume that all your components need to turn red if an event coolEvent is triggered. Instead of coding this in every Component, we just create a mixin that does it, and add this mixin to every component. This is awesome and makes you follow DRY (Don’t repeat yourself). Backbone should definitely add this!

2) Component’s lifecycle. When a certain Component is to be removed or changed from the DOM, it’s important to remove and clear certain JS variables so as not to have Memory Leaks. Flight allows us to do this with some cool hooks, but backbone doesn’t. I think that every JS frameworks should have a tearDown for objects. Open any webpage and leave it open for 1 hour and you’ll see that it consumes a bunch of memory. Every website has memory leaks. Yes, even Facebook! hahaah

So, will I use Flight? If I’m having some Rest API and then the Website, the answer is NO. Backbone has almost everything that Flight has, an even more. I thought that Backbone was lightweight but Flight is even more!

I hope you liked the quick review :) See yaa!

Share!Share on FacebookTweet about this on TwitterShare on RedditShare on Google+Share on LinkedInBuffer this pageEmail this to someoneFlattr the author
  • Tom Hamshere

    Regarding the idea of events being difficult to debug – I’ve found the exact opposite with Flight. Debugging is much easier with Flight than with traditional deep-linked namespaces and stack traces, as you’re only ever one step away from the source. The trick is naming the events well so that you know exactly where they are coming from.

    Figuring out which component fired event is pretty easy, as you can see which element is was fired on. UI components fire events on their root DOM node, while data components fire on the document. Data events should be unique to their component – only one data component will fire a specific kind of event.

    100% decoupling is fantastic as it allows you to create truly independent modules, the interfaces of which can be completely and independently tested. In fact, there’s no such thing as parent and child. If you find you need to communicate between a parent component and a child component, you probably want to make one of them a mixin.

    • mgonto


      I’ll check that about events to see where they are triggered. I’ll give it another try.

      I agree that decoupling is fantastic. That happens with most event driven frameworks, where events are the only way to communicate. But sometimes, it does make it harder (at least in my opinion) to code some things that are not necesarily 100% decoupled.

      I agree that in idea it’s perfect. You think as every piece of DOM or component as a reutilizable widget that can be tied to any element containing inside the things you need. But reality, is that most of the time you don’t actually need a widget to be reutilized somewhere else. I don’t say that we must write coupled code, but that the idealized version of decoupliing isn’t in my opinion the best always. We need to do a trade off between what we really need, and making it extensible for a possible feature in the future.

      Anyway, I do like Flight. You just gotta find the right tool, for the right project. For example, in TweetDeck case (the most promoted one to use Flight JS), I think it makes a lot of sense. Mostly everything are widgets that can be put whereever you want and can be moved. That goes fantastically with the components idea. However, in order to comunicate to the REST api of Twitter, you must’ve used another framework or coded something yourself because Flight doesn’t provide that. I think that still no framework is perfect, but we’re getting there :)

      Thanks for the opinion!

      • Tom Hamshere

        Currently on TweetDeck Flight data components reference old data modules which make ajax calls to the API. The plan is to replace the old modules with smaller Flight components, using mixins to manage the Ajax. uses a data mixin to make API calls already. Data components mixin a ‘withData’ mixin which provides methods such as ‘get’ to which is passed a url, some parameters and a callback. The ajax calls are made using jQuery’s ajax utilities.

        I’m not sure why you might think creating reusable code might have a downside. Flight is by its very nature reusable – it doesn’t take any extra effort to make it so.

  • finestglasses j.

    Uncover awesome kids glasses marked down prices. Preserve 70% with regards to RX glasses along with components for kids together with overnight S&L.

  • rstehwien

    How does Flight compare to ReactJS + Flux?