I’m still chewing it up - I mean, I’m still working on making my own opinion on Twitter Flight. It’s … different, it’s interesting, but there are few aspects of it I find very controversial. Unfortunately, the last 2 months of 2013 will most likely be insanely busy, so I don’t believe I’ll have any change to build something big enough to validate my (“could be”) pre-mature opinions. Well, I’m going to write a post anyway, maybe in few months I’ll re-visit it to find my past opinions wrong and unjust. No risk, no fun.
Back to business: Twitter Flight (http://twitter.github.io/flight/) is “an event-driven web framework” - at least that’s they way its introduced by its creators - engineers from Twitter. It doesn’t mimic any of most renown frameworks / libraries used to create web apps (Backbone, Angular, Ember, etc.) - it’s completely different.
The Foundation
Flight was built, because Twitter engineers were struggling with the complexity of dashboard-like web applications that consistent of several components that interacted with each other in a complex way - that was also a root cause of performance issues. Unfortunately traditional interactions (JavaScript function calls, binding by using CSS selectors) cause tight component coupling and that doesn’t really help with isolated testing, keeping the complexity (and overall technical debt) under control.
The best way to decouple components is to shift the paradigm to event-driven one and that’s how Twitter Flight works (https://blog.twitter.com/2013/flight-at-tweetdeck). There are two types of components - UI ones (reponsible for presentation) and Data ones (reponsible for pink unicorns, erm, I mean - for data handling) - all the components interoperate via events.
For instance:
- if you change the input field value on the web page (in UI component), it doesn’t bother with what happens with the data afterwards - your UI component just sends a meaningful event ("field has been updated") and other components that have registers their handlers for this particular event, do whatever is necessary (data component will update the data by POST), another UI component will update the summary section beneath, etc.
- once new data is read from the server. data component doesn’t care where it’s presented and in which way, it just broadcast a suitable event ("new value of field has been read") and each components that’s interested in that particular quantum of data (has registered earlier to handle this) will get informed.
This way each component operates as independently as possible - it doesn’t break that easily if another component breaks. And you can easily test each component (for instance - using dedicated Jasmine-Flight library) separately.
But, but, but …
The idea is awesome. It sounds like integrating web widgets with JavaScript event “message bus” :) However, Twitter guys are very (maybe too much) persistent in their decoupling crusade: that’s why they treat UI & data components separately - and that means no traditional two-way binding (which is “a bread & butter” of user-facing applications).
In general - yea, they are right: this way, view is really decoupled from the model (if you stick to traditional lingo - actually that’s something Twitter peeps discourage you from), but what’s the price? Twitter (as a web page) has very limited number of interactions: there aren’t many forms user can input his data into, so I can imagine replacing tradtional data-binding with full duplex event communication. But will that work for more complex application? I have my doubts (obviously related to the increasing complexity of development - number of events will skyrocket).
So, this is it?
Obviously, Flight is not only about events. Components as a way of encapsulating goodies seem to make sense, there are also mixins you can utilize to re-use functionality between components - easy to use and not over-technicized too. Nice integration with require.js (to manage the dependencies) is welcome as well. What I really enjoyed was Advance API - the way to execute your own function before, after or as a wrapper around any other function: it’s concise, simple and very useful.
And … that’s pretty much all. Twitter Flight toolset is extremely simple - all the mechanisms mentioned above are enough to build an event-based, decoupled application using the approach suggested by Twitter engineers. Does it mean it’s easy to create applications with Flight then? I wouldn’t say that - Twitter Flight is a perfect example of "easy to learn, hard to master" libraries / frameworks -> Flight applications have a very flat structure of many peer components and the more of them, the more of events - it’s not that easy to keep that in order, especially if you really want to have an ergonomic UI. Event the simplest interactions (like two-way binding) have to be code using event exchange - they may be really burdensome as well.
Make your own opinion
Start with the official website (http://twitter.github.io/flight/), go through the source code, try an example or two. If you want a more detailed tutorial - there’s already a book about Twitter Flight (http://www.packtpub.com/getting-started-with-twitter-flight/book) - it has it’s flaws (https://www.goodreads.com/review/show/748371285), but for now you won’t find anything better on that anyway.
Even if you won’t like Flight - it’s interesting enough to at least try and make your own opinion - and that’s my recommendation.