Realtime—what is it?
Whenever there is discussion on this topic, there's always someone who asks, "What is realtime?"
The answer, as it turns out, has several layers.
On the surface, realtime is about websites which dynamically update from outside data sources without user intervention.
This sounds rather uninteresting to many, as this has been done since the days of Yahoo! Chat in 1994, but there is more to it than that.
To get into the meat of it, we need to ask, "When is realtime useful in a web application?"
Realtime data driven applications are only useful when you are aggregating data from multiple sources.
Think about it; think about a shopping cart, for example. You could make a single-page shopping-cart application that does all sorts of AJAX updates, but it's not realtime because you're the only input.
Why have the server send you data when you didn't take an action when you're a customer adding things to a shopping-cart and checking out? A dashboard where an administrator can see live stats (or aggregated and batched stat updates) as the users make purchases would certainly be realtime. The fact that there are multiple sources of data aggregated by the server-application or client-application in addition to live-updating is what makes it realtime. The administrator might be able to deliver special offers specifically to individuals or groups of people he sees making purchases to upsell them and suddenly the user side of the application is realtime as well, because an extra source of data has been added (the administrator's user-focused upsell promotions).
To qualify as realtime, it really doesn't matter what method you're using to get data to the web-client.
Websockets, long-polling, jsonp, out-of-band, timed Ajax requests, or whatever you come up with can all work fine.
However, it's certainly worth discussing best-practices, developing new techniques, and sharing our experiences with realtime, because it's hard and the results are valuable.
That's why we've put together the Realtime Conference, as a way to make these things better and form a community around many technologies.
The short answer is scaling, synchronizing, and UI.
The scaling problems with realtime, which vary depending on your approach, are unique.
If you use websockets, you're going to use more RAM on the servers (holding open each stateful connection), have to deal with reconnecting sessions, and other complexities, but it may mean your servers take less of a CPU pounding than Ajax polling, for example.
Synchronizing client state must be very methodical and architected carefully.
Client-side MVC (backbone/spine/ember.js anyone?) can help ease some of this pain, but you still have to deal with caching.
If the client can't deal well with the raw amount of data it has, it needs to be able to throw some away (treating your local copy as a cache because the server is usually the authority for your data).
Oh, and don't forget to think about what happens when the user is disconnected and takes actions during that time.
Realtime UIs that look cool may be hard to use because you are affecting the user's interface while they're potentially using it.
Take the time to think about how to get new information to a user in such a way that doesn't interrupt them, which pieces of information is actually useful, and whether you want to to strictly control user views from the server.
Realtime web applications aggregate multiple sources of data (users, servers, sensors, whatever) and present them or hint at updates to an web user. It's a subtle and hard thing to get just right, and there are many evolving approaches.
The Realtime Conference is all about exploring, discussing, and bringing minds together to evolve and create better ways to make our applications use live data to interact with our users. You should come! We've just added a few more tickets.