Question: Compare use of Flight over javascript pub/sub plugin?

[Michael Woytowitz]

I am evaluating Twitter Flight for a new single page web app I am designing.

I have used the pub/sub pattern on previous SPA projects. For this I used very lightweight and simple pub/sub plugin.
https://gist.github.com/cowboy/661855

1. How does using the DOM events for pub/sub vs straight JavaScript compare in terms of performance?
   
   
2. Are there other advantages to using Flight over a simple pub/sub plugin?
   
   
3. Are there performance penalties incurred by needing to bubble events to the Window object.?
   
   
4. Finally, Are there any improvements to be had if I restrict my target browsers to ECMAScript 5 and above?

Thank you in advance,

~Michael

[Cary FitzHugh]

I ended up using flight for mainly pubsub.

I found flight wrapped components nicely, and the mixins were quite handy.  

I never have had a single concern about event performance of either type in a user-based webapp.

I never bubbled to the window. I just attached everything to body, and pub/subbed to that.  Maybe they do bubble up higher than that, but again, never had a single issue to go rooting around to find out.

Thanks

Cary

[Tom Ashworth]

Hey Michael,

1. Using the DOM (well, jQuery's events) is slower than a dedicated pub/sub module due to the way it simulates bubbling. It's not *slow* per se, but you'll notice if you do a lot of triggering at page initialisation as it can block render.

2. Unless you explicitly want the bubbling properties that any event triggered in Flight will have, there's no obvious advantage. I'm talking specifically about 'data' events here: obviously DOM events have to bubble and you will have no problems using Flight's event API to react to DOM events.

3. See above :) That said, if you're happy to do it, using a single node as a 'bus' isn't a bad option (I'd recommend document over document.body as there will be less bubbling).

4. Flight requires an es5-shim (Object.keys, Array.forEach etc) so the obvious advantage would be the performance gain from the native implementations of these functions. That said, the shims are pretty fast — so it depends on your use-case!

My recommendation: use the pub/sub for 'data' events and Flight's API for DOM events and anything you explicitly want to bubble.

Hope that helps!

--

Tom

[Michael Woytowitz]

Tom,

Thank you for the quick response,

In the documentation it implies using ui/.....  and data/.... to namespace events for ui and data. 
So if I interpret your post correctly, however, I should only use flight for UI events and a native javascript pub/sub library for data events?

Is Flight using jQuery eventing under the covers to simulate DOM events?

[Giuseppe Gurgone]

Is Flight using jQuery eventing under the covers to simulate DOM events?

Yes 

[Tom Ashworth]

Oops, realised I didn't reply-all. Copying what I send to Michael in here:

You're right — the ui/data namespace is conventional wisdom for Flight, but in TweetDeck we've found we don't use the bubbling properties of data* events enough so there's a plan to replace them (well, the events used for passing data around) with some kind of observable stream, FRP–style. That'll be open-source when it's ready, so maybe something to look out for!

I'd say yeah, using a raw pub/sub library could be beneficial for throwing data around.

And yes, Flight uses relies on jQuery for events binding and triggering. This is something we want to change in future (remove the dependency), but for now it's mandatory.

--

Tom

[Giuseppe Gurgone]

Cool!

Michael maybe you can write something like that for flight? :)

[Michael Woytowitz]

Hi Tom, Giuseppe,

By FRP you mean Functional reactive programming correct?

https://gist.github.com/staltz/868e7e9bc2a7b8c1f754

 

 I think the challenge is to not use a separate event bus API for the data vs UI events.  I wonder if one could simply make the event specification more rich and add ability to specify event types as either "data" or "ui" and then through a common API provide bubbling (dom attached) events for UI as well as non-attached "global" events for data.

When we implemented this in our application using a simple pub/sub library all events (messages) were global and all components could subscribe to different message (by name) as required.  Of course, all our subscribe handlers were simply callbacks - not a sophisticated as an observable stream.

For now, I would think attaching the global data events to the body tag should work enough for a prototype.  I'll poke around in the source code to get a better feel how Flight's eventing is implemented and then can post some more specific questions.

Thank you for all your responses,

Michael