(For more resources related to this topic, see here.)

Simplicity

First and foremost, Flight is simple. Most frameworks provide layouts, data models, and utilities that tend to produce big and confusing APIs. Learning curves are steep.

In contrast, you’ll probably only use 10 Flight methods ever, and three of those are almost identical.

All components and mixins follow the same simple format. Once you’ve learned one, you’ve learned them all.

Simplicity means fast ramp-up times for new developers who should be able to come to understand individual components quickly.

Efficient complexity management

In most frameworks, the complexity of the code increases almost exponentially with the number of features. Dependency diagrams often look like a set of trees, each with branches and roots intermingling to create a dense thicket of connections. A simple change in one place could easily create an unforeseen error in another or a chain of failures that could easily take down the whole application.

Flight applications are instead built up from reliable, reusable artifacts known as components. Each component knows nothing of the rest of the application, it simply listens for and triggers events. Components behave like cells in an organism. They have well-defined input and output, are exhaustively testable, and are loosely coupled.

A component’s cellular nature means that introducing more components has almost no effect on the overall complexity of the code, unlike traditional architectures. The structure remains flat, without any spaghetti code.

This is particularly important in large applications. Complexity management is important in any application, but when you’re dealing with hundreds or thousands of components, you need to know that they aren’t going to have unforeseen knock-on effects.

This flat, cellular structure also makes Flight well-suited to large projects with large or remote development teams. Each developer can work on an independent component, without first having to understand the architecture of the entire application.

Reusability

Flight components have well-defined interfaces and are loosely coupled, making it easy to reuse them within an application, and even across different applications.

This separates Flight from other frameworks such as Backbone or AngularJS, where functionality is buried inside layers of complexity and is usually impossible to extract.

Not only does this make it easier and faster to build complex applications in Flight but it also offers developers the opportunity to give back to the community.

There are already a lot of useful Flight components and mixins being open sourced. Try searching for “flight-” on Bower or GitHub, or check out the list at http://flight-components.jit.su/.

Twitter has already been taking advantage of this reusability factor within the company, sharing components such as Typeahead (Twitter’s search autocomplete) between Twitter.com and TweetDeck, something which would have been unimaginable a year ago.

Agnostic architecture

Flight has agnostic architecture. For example, it doesn’t matter which templating system is used, or even if one is used at all. Server-side, client-side, or plain old static HTML are all the same to Flight.

Flight does not impose a data model, so any method of data storage and processing can be used behind the scenes.

This gives the developer freedom to change all aspects of the stack without affecting the UI and the ability to introduce Flight to an existing application without conflict.

Improved Performance

Performance is about a lot more than how fast the code executes, or how efficient it is with memory. Time to first load is a very important factor. When a user loads a web page, the request must be processed, data must be gathered, and a response will be sent. The response is then rendered by the client. Server-side processing and data gathering is fast. Latency and interpretation makes rendering slow.

One of the largest factors in response and rendering speed is the sheer amount of code being sent over the wire. The more code required to render a page, the slower the rendering will be. Most modern JavaScript frameworks use deferred loading (for example, via RequireJS) to reduce the amount of code sent in the first response. However, all this code is needed to be able to render a page, because layout and templating systems only exist on the client.

Flight’s architecture allows templates to be compiled and rendered on the server, so the first response is a fully-formed web page. Flight components can then be attached to existing DOM nodes and determine their state from the HTML, rather than having to request data over XMLHttpRequest (XHR) and generate the HTML themselves.

Well-organized freedom

Back in the good old days of JavaScript development, it was all a bit of a free for all. Everyone had their own way of doing things. Code was idiosyncratic rather than idiomatic. In a lot of ways, this was a pain, that is, it was hard to onboard new developers and still harder to keep a codebase consistent and well-organized.

On the other hand, there was very little boilerplate code and it was possible to get things done without having to first read lengthy documentation on a big API.

jQuery built on this ideal, reduced the amount of boilerplate code required. It made JavaScript code easier to read and write, while not imposing any particular requirements in terms of architecture.

What jQuery failed to do (and was never intended to do) was provide an application-level structure. It remained all too easy for code to become a spaghetti mess of callbacks and anonymous functions.

Flight solves this problem by providing much needed structure while maintaining a simple, architecture-agnostic approach. Its API empowers developers, helping them to create elegant and well-ordered code, while retaining a sense of freedom.

Put simply, it’s a joy to use.

Summary

The Flight API is small and should be familiar to any jQuery user, producing a shallow learning-curve. The atomic nature of components makes them reliable and reusable, and creates truly scalable applications, while its agnostic architecture allows developers to use any technology stack and even introduce Flight into existing applications.

Resources for Article:

Further resources on this subject:

• Integrating Twitter and YouTube with MediaWiki [Article]
• Integrating Twitter with Magento [Article]
• Drupal Web Services: Twitter and Drupal [Article]