Write highly decoupled Webapps using Twitter Flight

Twitter recently open-sourced their webapp framework called Flight. I was starting on this webapp, and thought that I would give it a go. I have only worked on it for the last two-three weeks; it has left a very lasting impression on me though.

A different take from conventional MV* frameworks

The primary idea behind Flight is to divide the app into a number of “components”, which will interact with each other through events, and ideally, should be able to function independently. Flight also offers “mixins”, which can extend a component by adding more properties to it. The number of MVC/MV*  frameworks in JS has grown exponentially of late; Flight offers a very fresh way of looking at modern webapps. Steven Sanderson offers a very nice perspective on the various MV* frameworks around in his blog. Despite their differences, one common thing about all of these is that they impose their own structure on your code; some do this more than others. Flight is different in the sense that beyond the component definition, it gives a lot of flexibility to the user to use whatever he/she wishes to plug into the code without much of a pain. Flight is also inherently modular;  this leads to code getting very organized without any effort at all. It is also strongly in accordance with the DRY philosophy; Flight components can be attached to multiple DOM elements, Flight mixins can be added to multiple components, A single Flight component can have multiple mixins added to it.

How I used Flight

A little bit of a background about my app stack: It is a single page app. The various libraries I have used are:

1. Require JS and AMD for loading modules:
2. FlatIron Director for Routing: I wrote a hack over the original code to implement AMD
3. Flight
4. Bootstrap & a few of the Bootstrap Plugins
5. JQuery
6. Lo-Dash: Functionality of Underscore, but faster
7. A bunch of JQuery plugins here and there
8. Coffee Script and SASS

I call each single-page state as a “module”. Each module uses whatever components it needs. In the last two-three weeks, I have developed a solid structure through which I am using my components; I have been able to roll out code quicker than I have ever done. The file structure for each component looks like:

|–  model.js

|–  operations.js

|–  view.js

|–  templates

|– —  template1.txt

|– —  template2.txt

Here, model.js is the primary component file. operations.js and view.js are invoked as mixins into model.js. The idea behind this is to keep model.js clean; All my dirty work happens in operations.js (Various operations)  and view.js (All the DOM manipulation, templates are also loaded here). By defining further dependencies in operations.js and view.js, I can use any third part library that I wish to, and it will seamlessly integrate with my component. For example, I have not defined explicitly what engine I am going to use for templating; I could easily add whatever I am comfortable with without compromising on the overall structure.

Some Talking Points:

• Do have a look at this account by Tom Hamshere on using Flight in refactoring TweetDeck. The post has a lot of insights on using Flight. I had a few nice discussions with Tom about Flight, and they have only strengthened my liking for Flight. 
• 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.
• Martin Gontovnikas also talks about the Model-View part as in the above point. He also mentions the lack of a Router. This, I feel is the essence of Flight really; It is not a full framework that will impose itself on you. It allows you to use whatever components you want to for the app; I, for instance have used FlatIron Director; I could have used Crossroads, or even the Backbone Router; that remains my call.
• By dividing the app into a number of components, it makes it easier to test each component separately. Be careful about selecting your tester though; It should be able to support DOM events.
• Flight is a relatively new framework, and there could probably be better ways to use it. If you have used Flight, and have some nice suggestions, do let me know. Also, I could share some of my code structure, if you would wish me to. Please feel free to give in feedback