Comet: It’s Ajax for “Push” (Podcast)

Alex Russell has coined a term for a flavour of Ajax that’s been getting more attention of late. Comet describes applications where the server keeps pushing – or streaming – data to the client, instead of having the browser keep polling the server for fresh content. Alex identifies several buzzworthy examples:

This is an important article because it captures a growing trend in Ajax, a trend I had in mind when I said we expect to hear more about “Push and the Two-Way Web” in the next twelve months, on the occasion of Ajax’s birthday. There will, of course, be people saying “there’s nothing new here”, and that’s presumably all too obvious to Alex himself, who has worked with these ideas for a long time. But as with Ajax, it’s the power of a name. I don’t think these ideas can adequately be described as Ajax, because Ajax changes a lot about the browser whereas Comet fundamentally changes the nature of browser-server communication. I see Comet as part of the overall Ajax trend, complementary to the UI aspects of Ajax.

People may also say there are existing names like “Push”. True, but they have baggage – I think it’s useful to have a name for this architectural pattern in light of the relationship to Ajax.

Anyways, I wanted to expand on some of the thoughts in the article and after the recent Basics of Ajax Podcast, I’m in the mood for more audio rambling. So here’s a 56-minute discussion about Comet and the general trend of push and streaming within Ajax.

Shownotes…

It's the Duplex, Stupid!
Push or Pull - it doesn't matter so much. What's critical here
is the focus on the two-way web.

Benefits of Polling
- Browser memory
- Can run on any standard server; Comet requires suitable
server
- Can upload at the same time
- Can run on - with Comet, XHR and IFrame won't always reflect
changes while the connection's open
- Being more standard, works with existing infrastructure.
Comet is vulnerable to middle-men dropping the connection.
- Simpler architecture - only the browser's in control
- Easier to test
- More familiar architecture
- Less programming effort - with Comet, must watch for changes
on the stream
- More efficient for infrequently accessed data
- Leverages caching

now, typing document.getElementById() every time is a big pain 🙂 Which is why I choose to use prototype.js (http://prototype.conio.net) to abstract a lot of the browser differences. prototype.js includes an alias to document.getElementById (with a couple of extra features) you can call via $()

I’m guessing this relates to the recent Basics 3 of 3 podcast (I did two this week, bit confusing after 100+ days off ne).

I think I agree with you. In all the code examples, I use $() myself, convention yanked straight from prototype.js. I’d only use clickme.onclick if clickme was a JS variable, that’s probably what I meant on the podcast, which just goes to show why code snippets don’t make for very good podcast content :-).

G’Day

Welcome to Michael Mahemoff's blog, soapboxing on software and the web since 2004. I'm presently using HTML5 and the web to make podcasts easier to share, play, and discover at Player FM. I've previously worked at Google and Osmosoft, and built the Ajax Patterns wiki and corresponding book, "Ajax Design Patterns" (O'Reilly 2006).
For avoidance of doubt, I'm not a female, nor ever have been to my knowledge. The title of this blog alludes to English As She Is Spoke, a book so profoundly flawed it reminded me of the maturity of the software industry when this blog began in 2004. I believe the industry has become more sophisticated since then, particularly the importance of UX.
Follow @mahemoff