I'm thinking of writing a realtime web app that would need to be able to push messages to the browser. When I first read about Comet, people seemed to consider it a brittle and immature approach due to weak browser support. Today, it seems to be an established and practical technique. But as far as I know, browers don't support the basic methods (long polling, iframes and script tags) any better now than they did in '06 when the idea first became popular.
Of course, it's difficult to manage all of those connections on the server side, but Comet frameworks solve that problem (and it was doable even back in '06 with something like Twisted). So what's the deal: are there any deal-breaking problems with Comet support in browsers, or were the people back then just wrong?
Also: I recently read a ~2010 blog post summarizing the state of Comet technology, covering each method in detail. It made it sound like none of the methods were really viable. The post was very persuasive, which is why I'm still edgy about Comet. The only thing I can remember about the blog is that it had a dark background (brown or black). Has anyone else seen that post? I'd really like to read it again.
I would argue that comet is very viable right now, every browser supports long polling so you have a common fallback that will still work, and there are methods in each browser that will be more performant than long polling.
You just don't see it very often because its quite a big undertaking to support the different methods in each browser, google and facebook have the resources to do it, but your average joe web dev. would be wasting a lot of time for very little gain. There are only so many applications where you really need the real time communication comet provides.
I think now with frameworks like APE and cometD that give you the backend and the client side utilities you are seeing more people able to take on the complicated tasks. It can't be immature anyway, comet is just a technique that uses existing capabilities in a very novel way.