9 ms·

Flight: A lightweight, component-based JavaScript framework from Twitter

236 points by uggedal 14y ago

bvcqw 14y ago
Why not just use Angular?
- bwilliams 14y ago
  Why not just use Ember?
  - felipesabino 14y ago
    There is a very nice thread on Quora comparing both Angula and Ember. One of Ember creators also participate with good insights http://www.quora.com/Ember-js/Which-one-of-angular-js-and-ember-js-is-the-better-choice http://www.quora.com/Ember-js/Which-one-of-angular-js-and-em...
- danso 14y ago
  Because it will "just fit" with corresponding Bootstrap assets, I'm assuming... I don't know if it does that now, but I'm assuming both frameworks will eventually share the same conventions and opinions so that developers can use them in tandem without too many extra ateps
  - georgemcbay 14y ago
    Both of the Bootstrap developers left Twitter a few months ago and AFAIK they are still the ones developing Bootstrap. While it is possible that they are collaborating with the current-Twitter developers working on this thing, it doesn't seem like much of a sure thing.
- jlogsdon 14y ago
  Because not everyone wants to define application behavior in markup.
  - aidos 14y ago
    I might be misunderstanding you but Angular behaviour isn't defined in markup. The views are, as well they should be, but they're just representations of the model behind the scenes.
    - jlogsdon 14y ago
      http://angularjs.org/#todo-html http://angularjs.org/#todo-html This just does not jive with me. My template knows that submission should be handled by `addTodo()`? Or even worse, looping. I want all of my logic to live in code, not some abstract framework specific attributes that don't add much in the way of clarity (context switching between template and view just to follow the workflow, for example). I use (and love) Backbone because the DOM is considered a pure presentation layer, nothing else. Any behavior, logic, whatever that the code controls is defined only in the code.
      - aidos 14y ago
        To each his own. I don't think it's that big of a deal either way. You don't actually have to do it that way in angular if you don't want to. You can put it all in code instead. The framework specific attributes you're looking at aren't exactly framework specific, they're kinda application specific (just happens they ship with the framework). You can write your own ones to move any of that stuff into code instead of markup. I personally think that loops should be in markup - I happen to prefer templating systems with less restrictions.
      - ahoge 14y ago
        >My template knows that submission should be handled by `addTodo()`? Or even worse, looping. Most template engines support loops. Would be very weird without that capability, really. Also, you have to add hooks to buttons and the like somehow. There isn't much of a difference between adding a class like "js-addWhatever" or using Angular's in-your-face approach.
        TheZenPsycho 14y ago
- ww520 14y ago
  Different purpose. This is for building reusable UI widget components.
- hueyp 14y ago
  > It's agnostic to ... if you render your HTML on the client or the server I love Angular, but if you are rendering server side HTML (either as partials, or bootstrapping a page) it is currently lacking.
  - bvcqw 14y ago
    Flight is rendered server side? I must have missed that. Okay, in that case I can see a need here.
    - jlogsdon 14y ago
      Flight doesn't care where things are rendered. > It's agnostic to how requests are routed, which templating language you use or even if you render your HTML on the client or the server.
- taligent 14y ago
  Why not just use KnockoutJS?
  - aymeric 14y ago
    You can end up with a hard to maintain code with knockout.js if you don't structure it well. I found https://github.com/danderson00/knockout.composite https://github.com/danderson00/knockout.composite recently that seems to adopt a similar philosophy (pubsub) to what Flight does while keeping the benefit of knockout.
    - WickyNilliams 14y ago
      I've used this knockout extension to great success [1]. It's intuitive, it leverages knockout's internal pubsub, and fits in with the KO ethos. It can be used to synchronise observables across models (which is awesome as it's events without overhead), or as a general purpose event system. Ryan is one of the core contributors to knockout, by the way, so you can be assured of its quality. [1] http://www.knockmeout.net/2012/05/using-ko-native-pubsub.html http://www.knockmeout.net/2012/05/using-ko-native-pubsub.htm...
  - Guillaume86 14y ago
    IMO the real question is why use KO when you know Angular? (except perhaps for the lib size) Really, I was using KO and it was really nice at the time but since I've tried angularJS I don't see a reason to go back to KO. Two way binding without ko.observable/ko.observableArray/ko.computed, just plain js objects is really a big win.
- zachrose 14y ago
  Why use anything when you could just hire a web developer?
karl_nerd 14y ago
What I think is interesting to see, is that the patterns from Nicholas zakas' "scalable Javascript architecture" spreads into new frameworks. Enforcing components w/o return values, communicating via pub/sub is also seen in aura.js and backbone marionette. I think this thinking will lead to more stable, easy to change js apps. Exciting!
dmragone 14y ago
Recently I discussed with colleagues why Ruby on Rails succeeded where no Python framework did. One hypothesis put forward was that there was 1 popular Ruby framework (Rails), but many popular Python frameworks. I wonder if it will be the same for JavaScript front-end frameworks, with no one gaining the greatest mindshare. Not necessarily make any claims about what's preferable (one framework to rule them all vs many competing options) - though I'm certainly curious about that as well for the front-end frameworks.
- vincentperes 14y ago
  Javascript front-end framework are really new (3 years old) compare to web frameworks. The need is also quite different. There was a need for a Javascript framework and we can say that jQuery won the battle. We will have to wait few more years to see most of the web app running with a Javascript front-end framework, then you will maybe have a winner!
  - sasasaasas 14y ago
    sddsdsdsds sasasaasas
  - sasasaasas 14y ago
    assasasasasasasa
- lucian1900 14y ago
  For JavaScript, it doesn't matter. It is privileged by being the only thing that runs in browsers.
  - ahoge 14y ago
    There are a alternatives: https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang... I, for one, really like Dart. It's very nice to use.
- d23 14y ago
scottrblock 14y ago
I've played around with most of the JavaScript MV(whatever)'s and I'm just not sure about this. "Flight is organized around the existing DOM model with functionality mapped directly to DOM nodes" It seems the point of using backbone or which ever other framework (I'm partial to Angular so far), is to decouple from the DOM, so that if and when your markup changes, your JavaScript doesn't. This doesn't seem any better than well written jQuery. Am I missing something?
- pfraze 14y ago
  It looks like the concerns are different between Backbone and Flight. Flight is for building UI components, not client views. I think it might be akin to jquery widget plugins, but with more structure to make it easier and potentially more extensible (eg the mixins). So yeah, in this case I think they were right to ride on DOM events.
dos1 14y ago
>When you create a component you don't get a handle to it. Consequently, components cannot be referenced by other components and cannot become properties of the global object tree. This is by design. Components do not engage each other directly; instead, they broadcast their actions as events which are subscribed to by other components. This is a maintainability nightmare. I've gone down this route on hand rolled JS frameworks before and it leads to untold headaches. Sometimes a little coupling is the right solution. Many times it is better for components to have knowledge of their environment. In most applications (other than iGoogle maybe) one thing on a page depends on another. I feel it's far better to explicitly call out those dependencies by having a reference to the other components and directly invoking methods on them with known arguments of a known type. Edit: Also, what kind of memory allocation implications are there with event subscriptions and no references to the components themselves?
- danso 14y ago
  Er...why is this broadcast model a maintainability nightmare compared to coupling components to their environment and to other components? I guess maybe it's too much abstraction for a website in which you know most components won't be reused...but then you wouldn't be Flight's intended audience.
  - dos1 14y ago
    So a component subscribes to some event somewhere. Who's triggering the event? When you're debugging in Firebug or someplace, what does your call stack look like? How hard is it to find the source of the event? All you know is it bubbled up from somewhere. Say I want to add a component to a page. Which events do I need to trigger to make it do the kind of things I want? What do I need to pass as a payload to those events? How do I know if there's a consumer for my event or not? If there isn't a consumer that's probably an issue. The eventing bus adds an additional layer of indirection. If your app can be truly decoupled, then this would be great. But I just don't see that use case being very common. I have never worked on an application where the broadcast model was more benefit than pain in the long run.
glymor 14y ago
This looks like Twitter's version of Web Components? You might have heard of it shadow DOM etc. Basically the idea is to be able to add GUI components eg <progressbar> that are as integrated as the native ones are. https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/... https://plus.google.com/103330502635338602217/posts https://plus.google.com/103330502635338602217/posts Mozilla's X-Tags implementation seems closer to the goal though: http://www.x-tags.org/ http://www.x-tags.org/ IIRC it can do this because it's using Object.observable internally to detect DOM changes. ie with X-tags you don't need the javascript definition part, just: <x-map data-key="39d2b66f0d5d49dbb52a5b7ad87aea9b"></x-map>.
- cristiantincu 14y ago
  Web Components is the storm that will wipe away all these frameworks: Backbone, Ember, Angular, Knockout, etc. Unfortunately, we’ll have to stick around with them for the following couple of years, probably, as for now, most of the Web Components APIs are available only in Chrome Canary and Firefox dev builds. Monkey-patching (AKA “shimming”) to the rescue… In my opinion, the more certain nowadays libs resemble the Web Components specs, the more clear the developers’ choice towards those libs should be.
vicapow 14y ago
why not just use component? http://github.com/component/component http://github.com/component/component
- jongleberry 14y ago
  agreed. the problem with these AMD frameworks is that the asynchronous nature and deeply nested callbacks are almost completely unnecessary because you end up concatenating/minifying the assets before production anyways. You end up with unreadable files. With synchronous CommonJS frameworks, most of this nesting is eliminated.
  - reissbaker 14y ago
    With AMD you generally only have one (in a rare case, two) levels of indentation added on top. I much prefer CommonJS too, but deep nesting's not really a fair accusation.
    - jongleberry 14y ago
      true. i'm being a little sarcastic, but 1-2 levels of _unnecessary_ indentation bothers me when it's easily avoidable.
      - reissbaker 14y ago
        Fair enough. Aesthetic reasons aren't the worst ones in the world. It's also just so... Yeesh. Complicated, in comparison.
  - slurgfest 14y ago
    Do you find that this is a big deal in practice, or does it just feel messy to you?
    - jongleberry 14y ago
      it's more like it's unnecessarily messy, which bothers me. if it was necessary, then it wouldn't bother me. and it's not just the nesting that is messy, the whole `define` stuff going on is messy.
benregenspan 14y ago
Why not just use Flash?
- gummydude 14y ago
  welcome to 2013
WayneDB 14y ago
How can anyone build a serious front-end without proper keyboard support? Every single one of these new-fangled web UI kits is missing this important feature and if you're going to do it at all, it really does need to be a core consideration. This is my biggest complaint about most web apps and the number one reason that I think web apps are perceived to be less powerful. Give me a break web devs! (Or, should I say browser makers?) Let's get serious already!! (Also if we're talking browser manufacturers, I'd really, really like to see a completely separate abstraction for apps than documents. C'mon man!! We've been inventing the same thing for 20 years, let's get it right for once :)
weareconvo 14y ago
Seeing as how Bootstrap fails at even the most elementary of tasks (using absolute instead of relative values for positioning, for example, screws everything up when the user's zoom is anything other than 100%, among many, many, many other flaws), anybody who uses this framework is a competitor I am... not worried about.
deleted 14y ago
[deleted]
Kiro 14y ago
I've read the page two times now and still don't understand what it does. Can someone explain?
agilord 14y ago
This is a really great concept, that enables client applications on a different scale (and reduces their complexity very much). Thanks Twitter team! A big advantage over web components (or angular, or others) is that this is much more lightweight, less polluted and has a better separation of concerns. (On the other hand, web components will be a great deal for browser-app shops developing for third parties).

236 points by uggedal 14y ago

bvcqw 14y ago

Why not just use Angular?

bwilliams 14y ago
Why not just use Ember?
- felipesabino 14y ago
  There is a very nice thread on Quora comparing both Angula and Ember. One of Ember creators also participate with good insights http://www.quora.com/Ember-js/Which-one-of-angular-js-and-ember-js-is-the-better-choice http://www.quora.com/Ember-js/Which-one-of-angular-js-and-em...
danso 14y ago
Because it will "just fit" with corresponding Bootstrap assets, I'm assuming... I don't know if it does that now, but I'm assuming both frameworks will eventually share the same conventions and opinions so that developers can use them in tandem without too many extra ateps
- georgemcbay 14y ago
  Both of the Bootstrap developers left Twitter a few months ago and AFAIK they are still the ones developing Bootstrap. While it is possible that they are collaborating with the current-Twitter developers working on this thing, it doesn't seem like much of a sure thing.
jlogsdon 14y ago
Because not everyone wants to define application behavior in markup.
- aidos 14y ago
  I might be misunderstanding you but Angular behaviour isn't defined in markup. The views are, as well they should be, but they're just representations of the model behind the scenes.
  - jlogsdon 14y ago
    http://angularjs.org/#todo-html http://angularjs.org/#todo-html This just does not jive with me. My template knows that submission should be handled by `addTodo()`? Or even worse, looping. I want all of my logic to live in code, not some abstract framework specific attributes that don't add much in the way of clarity (context switching between template and view just to follow the workflow, for example). I use (and love) Backbone because the DOM is considered a pure presentation layer, nothing else. Any behavior, logic, whatever that the code controls is defined only in the code.
    - aidos 14y ago
      To each his own. I don't think it's that big of a deal either way. You don't actually have to do it that way in angular if you don't want to. You can put it all in code instead. The framework specific attributes you're looking at aren't exactly framework specific, they're kinda application specific (just happens they ship with the framework). You can write your own ones to move any of that stuff into code instead of markup. I personally think that loops should be in markup - I happen to prefer templating systems with less restrictions.
    - ahoge 14y ago
      >My template knows that submission should be handled by `addTodo()`? Or even worse, looping. Most template engines support loops. Would be very weird without that capability, really. Also, you have to add hooks to buttons and the like somehow. There isn't much of a difference between adding a class like "js-addWhatever" or using Angular's in-your-face approach.
      - TheZenPsycho 14y ago
ww520 14y ago
Different purpose. This is for building reusable UI widget components.
hueyp 14y ago
> It's agnostic to ... if you render your HTML on the client or the server I love Angular, but if you are rendering server side HTML (either as partials, or bootstrapping a page) it is currently lacking.
- bvcqw 14y ago
  Flight is rendered server side? I must have missed that. Okay, in that case I can see a need here.
  - jlogsdon 14y ago
    Flight doesn't care where things are rendered. > It's agnostic to how requests are routed, which templating language you use or even if you render your HTML on the client or the server.
taligent 14y ago
Why not just use KnockoutJS?
- aymeric 14y ago
  You can end up with a hard to maintain code with knockout.js if you don't structure it well. I found https://github.com/danderson00/knockout.composite https://github.com/danderson00/knockout.composite recently that seems to adopt a similar philosophy (pubsub) to what Flight does while keeping the benefit of knockout.
  - WickyNilliams 14y ago
    I've used this knockout extension to great success [1]. It's intuitive, it leverages knockout's internal pubsub, and fits in with the KO ethos. It can be used to synchronise observables across models (which is awesome as it's events without overhead), or as a general purpose event system. Ryan is one of the core contributors to knockout, by the way, so you can be assured of its quality. [1] http://www.knockmeout.net/2012/05/using-ko-native-pubsub.html http://www.knockmeout.net/2012/05/using-ko-native-pubsub.htm...
- Guillaume86 14y ago
  IMO the real question is why use KO when you know Angular? (except perhaps for the lib size) Really, I was using KO and it was really nice at the time but since I've tried angularJS I don't see a reason to go back to KO. Two way binding without ko.observable/ko.observableArray/ko.computed, just plain js objects is really a big win.
zachrose 14y ago
Why use anything when you could just hire a web developer?

karl_nerd 14y ago

What I think is interesting to see, is that the patterns from Nicholas zakas' "scalable Javascript architecture" spreads into new frameworks. Enforcing components w/o return values, communicating via pub/sub is also seen in aura.js and backbone marionette. I think this thinking will lead to more stable, easy to change js apps. Exciting!

dmragone 14y ago

Recently I discussed with colleagues why Ruby on Rails succeeded where no Python framework did. One hypothesis put forward was that there was 1 popular Ruby framework (Rails), but many popular Python frameworks. I wonder if it will be the same for JavaScript front-end frameworks, with no one gaining the greatest mindshare. Not necessarily make any claims about what's preferable (one framework to rule them all vs many competing options) - though I'm certainly curious about that as well for the front-end frameworks.

vincentperes 14y ago
Javascript front-end framework are really new (3 years old) compare to web frameworks. The need is also quite different. There was a need for a Javascript framework and we can say that jQuery won the battle. We will have to wait few more years to see most of the web app running with a Javascript front-end framework, then you will maybe have a winner!
- sasasaasas 14y ago
  sddsdsdsds sasasaasas
- sasasaasas 14y ago
  assasasasasasasa
lucian1900 14y ago
For JavaScript, it doesn't matter. It is privileged by being the only thing that runs in browsers.
- ahoge 14y ago
  There are a alternatives: https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang... I, for one, really like Dart. It's very nice to use.
d23 14y ago

scottrblock 14y ago

I've played around with most of the JavaScript MV(whatever)'s and I'm just not sure about this. "Flight is organized around the existing DOM model with functionality mapped directly to DOM nodes" It seems the point of using backbone or which ever other framework (I'm partial to Angular so far), is to decouple from the DOM, so that if and when your markup changes, your JavaScript doesn't. This doesn't seem any better than well written jQuery. Am I missing something?

pfraze 14y ago
It looks like the concerns are different between Backbone and Flight. Flight is for building UI components, not client views. I think it might be akin to jquery widget plugins, but with more structure to make it easier and potentially more extensible (eg the mixins). So yeah, in this case I think they were right to ride on DOM events.

dos1 14y ago

>When you create a component you don't get a handle to it. Consequently, components cannot be referenced by other components and cannot become properties of the global object tree. This is by design. Components do not engage each other directly; instead, they broadcast their actions as events which are subscribed to by other components. This is a maintainability nightmare. I've gone down this route on hand rolled JS frameworks before and it leads to untold headaches. Sometimes a little coupling is the right solution. Many times it is better for components to have knowledge of their environment. In most applications (other than iGoogle maybe) one thing on a page depends on another. I feel it's far better to explicitly call out those dependencies by having a reference to the other components and directly invoking methods on them with known arguments of a known type. Edit: Also, what kind of memory allocation implications are there with event subscriptions and no references to the components themselves?

danso 14y ago
Er...why is this broadcast model a maintainability nightmare compared to coupling components to their environment and to other components? I guess maybe it's too much abstraction for a website in which you know most components won't be reused...but then you wouldn't be Flight's intended audience.
- dos1 14y ago
  So a component subscribes to some event somewhere. Who's triggering the event? When you're debugging in Firebug or someplace, what does your call stack look like? How hard is it to find the source of the event? All you know is it bubbled up from somewhere. Say I want to add a component to a page. Which events do I need to trigger to make it do the kind of things I want? What do I need to pass as a payload to those events? How do I know if there's a consumer for my event or not? If there isn't a consumer that's probably an issue. The eventing bus adds an additional layer of indirection. If your app can be truly decoupled, then this would be great. But I just don't see that use case being very common. I have never worked on an application where the broadcast model was more benefit than pain in the long run.

glymor 14y ago

This looks like Twitter's version of Web Components? You might have heard of it shadow DOM etc. Basically the idea is to be able to add GUI components eg <progressbar> that are as integrated as the native ones are. https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/... https://plus.google.com/103330502635338602217/posts https://plus.google.com/103330502635338602217/posts Mozilla's X-Tags implementation seems closer to the goal though: http://www.x-tags.org/ http://www.x-tags.org/ IIRC it can do this because it's using Object.observable internally to detect DOM changes. ie with X-tags you don't need the javascript definition part, just: <x-map data-key="39d2b66f0d5d49dbb52a5b7ad87aea9b"></x-map>.

cristiantincu 14y ago
Web Components is the storm that will wipe away all these frameworks: Backbone, Ember, Angular, Knockout, etc. Unfortunately, we’ll have to stick around with them for the following couple of years, probably, as for now, most of the Web Components APIs are available only in Chrome Canary and Firefox dev builds. Monkey-patching (AKA “shimming”) to the rescue… In my opinion, the more certain nowadays libs resemble the Web Components specs, the more clear the developers’ choice towards those libs should be.

vicapow 14y ago

why not just use component? http://github.com/component/component http://github.com/component/component

jongleberry 14y ago
agreed. the problem with these AMD frameworks is that the asynchronous nature and deeply nested callbacks are almost completely unnecessary because you end up concatenating/minifying the assets before production anyways. You end up with unreadable files. With synchronous CommonJS frameworks, most of this nesting is eliminated.
- reissbaker 14y ago
  With AMD you generally only have one (in a rare case, two) levels of indentation added on top. I much prefer CommonJS too, but deep nesting's not really a fair accusation.
  - jongleberry 14y ago
    true. i'm being a little sarcastic, but 1-2 levels of _unnecessary_ indentation bothers me when it's easily avoidable.
    - reissbaker 14y ago
      Fair enough. Aesthetic reasons aren't the worst ones in the world. It's also just so... Yeesh. Complicated, in comparison.
- slurgfest 14y ago
  Do you find that this is a big deal in practice, or does it just feel messy to you?
  - jongleberry 14y ago
    it's more like it's unnecessarily messy, which bothers me. if it was necessary, then it wouldn't bother me. and it's not just the nesting that is messy, the whole `define` stuff going on is messy.

benregenspan 14y ago

Why not just use Flash?

gummydude 14y ago
welcome to 2013

WayneDB 14y ago

How can anyone build a serious front-end without proper keyboard support? Every single one of these new-fangled web UI kits is missing this important feature and if you're going to do it at all, it really does need to be a core consideration. This is my biggest complaint about most web apps and the number one reason that I think web apps are perceived to be less powerful. Give me a break web devs! (Or, should I say browser makers?) Let's get serious already!! (Also if we're talking browser manufacturers, I'd really, really like to see a completely separate abstraction for apps than documents. C'mon man!! We've been inventing the same thing for 20 years, let's get it right for once :)

weareconvo 14y ago

Seeing as how Bootstrap fails at even the most elementary of tasks (using absolute instead of relative values for positioning, for example, screws everything up when the user's zoom is anything other than 100%, among many, many, many other flaws), anybody who uses this framework is a competitor I am... not worried about.

deleted 14y ago

[deleted]

Kiro 14y ago

I've read the page two times now and still don't understand what it does. Can someone explain?

agilord 14y ago

This is a really great concept, that enables client applications on a different scale (and reduces their complexity very much). Thanks Twitter team! A big advantage over web components (or angular, or others) is that this is much more lightweight, less polluted and has a better separation of concerns. (On the other hand, web components will be a great deal for browser-app shops developing for third parties).