"Always" is a dangerous word. I'd argue that polling is better for simple applications where latency and scalability aren't an issue. "Comet" adds a layer of complexity where it might not be necessary. Premature optimization... you know the rest.
Comet is only better if you have an app that sends significantly more data to users than it receives. If you're constantly sending data to the server, or only send responses based on user input, then comet is the wrong choice.
Comet is better than polling only if the benefits outweigh the opportunity cost. For almost all situations, the greatest upside is improving user experience.
Is Comet the best thing you can do, right now, to improve your user experience? If so, great! But I highly doubt that.
> Since that interview, Comet Daily has started publishing an article every day. This is a great step forward. Now we need to post every relevant article to Hacker News, Programming Reddit, Slashdot, and any other news site where emerging technologies can gain high exposure.
Sorry, but even with the graphs, I'm not seeing how 1000 users continuously connected for an hour doesn't translate into a lot more server load that 1000 users polling for an hour every 10 seconds or so.
It requires negligible (no?) traffic to keep a TCP socket 'continuously connected' when data is not being sent. (The only resource cost is the state at both endpoints remembering the socket exists.) OTOH, every 'poll' involves a lot of socket and HTTP request/response overhead traffic -- even if there's no update necessary.
Still, this article overclaims the comet case. Polling is often easier to understand/implement/debug. It requires less server-side state and may be less likely to hit practical server-side implementation limits.
I've always heard of comet explained in terms of building chat clients and the like but I think it's mains application is to make AJAX polling redundant
