The Live Web

Ars has an interesting perspective on the future possibilities of web sockets and the real-time applications made possible by this technology. MMO is a good example domain. Lots of concurrent users need simultaneous updates with as little latency possible. I'm trying to be careful with my words here - real-time isn't exactly attainable to the same degree as Skype or WoW. At least not with the currently-available combinations of server and client technologies for the web. The potential is most certainly there, but is it real-time MMO style domains we should chasing after with web sockets?

I would argue that it might be a little premature to dive-into such problems with web sockets as your weapon. Especially since these large scale problems already have solutions implemented that work quite well. Another hurdle facing web developers and their ambition to solve big programming challenges with web sockets is lack of browser support.

Factors that work against web socket technology are also it's strength. Why not use web sockets to make the current web a little more responsive? Why not give your users a sense of liveliness when they visit your web pages? Before web sockets came along — they're only now beginning to gain populatrity in the web development community — it was painful to make even the most basic information current. We're getting closer to doing this seamlessly now. The question is, where do we start?

The Static Web
Looking in the opposite direction from that of the MMO domain, let's think about static web pages. By static web pages, I don't necessarily mean flat HTML files sitting on a server somewhere, waiting for a user agent to request a copy. The static web can just as well be dynamically-generated web pages, assembled during request time from numerous sources. The static web is only static from the user's perspective. That is, they request a page, and once it arrives, it's dead. Nothing more than a copy of the real data with no potential to evolve and keep in tune with it's origin. You could keep your browser window open for a decade and watch the DOM elements collect dust.

Thinking about web pages this way really digs at the core problem that web socket technology addresses. We want our users to receive live data. When the real data that's stored in the database changes state, we want those changes available instantaneously. That means that any active web socket connection will receive new data, instructing the DOM elements in the client's browser to rearrange themselves. Sounds great, doesn't it?

Let's imagine that we had a framework that enabled us to keep content live like this. Now, who would this web socket framework benefit? Like most content on the web, this blog for example, there isn't much to gain simply due to the nature of the data. It gets written, published, maybe updated once or twice. Other than that, my blog data becomes stale shortly after it's published. Let's not confuse staleness with usefulness. Staleness means that other components that rely on fresh, or near real-time data, can't rely on it.

So having said that, if the vast majority of static web content out there has nothing major to gain from web socket technology, what does? I'm talking, of course, outside of the MMO domain here — how do we think about data that goes on the web in terms of liveliness?

Reshaping Data
If we're going to make good use of technology that allows us to publish changes to data as they happen, we should first look at the frequency of change. That is, how often would we be pushing out updates to the web browser? If the answer lies somewhere between once every couple minutes and once per second, your data is live and should be reflected in the user experience you provide. Another way to visualize how users deal with stale data is to picture them hitting the refresh button — their lifeline for new information.

The reality is, I think, that most information available in the static web universe follows a pattern shaped by the fact that users only have a one-time view of the data. We're not designing websites with the hope that users will simply hit refresh to synchronize with reality. Sure, we've got to accommodate this behaviour as it is the expectation — users want fresh data and there is a magic button built-in to every browser that will make that happen. But is that the best we can do for folks? Or can we raise the expectation that what they're looking at is reasonably accurate?

Doing so isn't trivial because we have to rethink what changes in state mean for the application. When data gets written to the database in your typical web application, that means nothing for most users. They might get a response, telling of the newly-created entity. But what does that mean for other views of the data model? Does it impact statistical views that someone in a cave might be staring at? Absolutely. Does it mean that the application should take notice of these changes in state and make relevant users sessions aware? You bet.

On top of all this talk about real-time MMO gaming, and events that should be pushed out to user sessions in an otherwise static web application, we're one step closer to making web applications the dominant platform. Developers target specific mobile and desktop platforms for a number of reasons, one of which, it's easier to get up-to-date data into the UI. I can see the gap between the two closing in — but before that happens, we need to somehow merge the static web and the live web. There is nothing wrong with the web the way it is today for displaying certain kinds of information. But we're now able to start taking seriously the notion of real-time data in domains where timeliness matters.