Silicon Valley Web Builder has a series of monthly panels on topics of interest to web application developers. I had the opportunity to attend a pair of events recently, once as a speaker, once as an attendee, and the contrast between the two was intriguing. The first panel in November was focused on Comet, while the most recent panel was a comparison of Ajax toolkits.
As an attendee of the Comet panel, I found the discussion interesting, but was a bit disheartening and negative. In retrospect, the negative tone reflects the pain and disappointment Comet engineers face in trying to come up with the perfect solution for low-latency data transit across the wire. Michael Carter was the lone optimist, describing the work he has done to date with Orbited, and what the HTML5 WebSocket promises to bring us in the near future. The other panelists were not as optimistic, having been burned by specifications not adopted and the ongoing frustrations with HTTP connection limits, proxy configurations, flaky internet connections, and more—all of which prevent many of the better approaches to Comet being viable.
There was also disagreement around the name Comet, what it encompasses, and whether it should be called WebSocket, Comet, Reverse Ajax, Ajax Push, etc. Alex and I think of all of this as Comet, whereas some panelists believe that WebSocket is not part of the Comet moniker, which is silly. One of the main reasons that Ajax took off is that people just agreed on the name (though I personally hated it for months), whereas in the Comet space there’s disagreement on just about everything, from the name to protocols to techniques. In my opinion, a race to standardize and simplify are essential if this fledgling set of techniques is to become approachable to a wider range of developers. An out of the box implementation with Google App Engine wouldn’t hurt either!
I’m optimistic because the work of Kris Zyp, Michael Carter, Andrew Betts, Greg Wilkins, Alessandro Alinone, and others is getting us closer to having ideal Comet solutions, but we have a lot of work to do before Comet is as approachable as Ajax.
The second panel, by contrast, was focused on Ajax toolkits. Dojo was represented by yours truly, with great representation by committers to GWT (Fred Sauer), jQuery (Yehuda Katz), MooTools (Tom Occhino), and YUI (Adam Moore), with Michael Carter moderating the panel. In contrast with the Comet panel, we had a lot of optimism and laughs, the result of several years of seeing very impressive advances in what’s possible in the browser. It’s been a great adventure from pre-Ajax to where we are today, and it showed with the sheer enthusiasm by everyone on the panel. We had our differences of opinion and some very funny moments, but what I really took away from this panel is that we’re all learning from each other, have similar goals in helping developers create amazing user experiences, and that there is tremendous interest in the great work being done in creating Ajax toolkits.
Comet toolkit developers of today remind me of DHTML toolkit developers in the pre-Ajax days: a bunch of frustrated, grizzled engineers that wanted to do more, but didn’t yet have enough code, tools, browser support, and/or momentum to get where they needed to go. Comet techniques are widely adopted in applications like the London Paper, Meebo, Gmail Chat, and Facebook Chat, as well as behind corporate firewalls in advanced financial applications, but the approach has not yet hit the developer tipping point like Ajax.