New Frontiers in the Real-Time Web

By Patrick Noonan | December 2013


Were you on Facebook in 2005? Do you remember refreshing the page to get new notifications? Or refreshing a Gmail inbox to see if anything new came in? Or your Twitter feed? These days, you'll probably only refresh the page if you're feeling particularly impatient, because those kinds of updates appear automatically the moment they occur. That's all thanks to the transformative power of WebSockets and the real-time web.

A Brief History of "Real-Time"

I remember going into chat rooms when the internet first came to my hometown in the early 90's. Chat has always been real-time, so as a concept you can see that the real-time web isn't especially "new." In terms of application development, however, chat protocols back then were very strict, and focused on establishing chat connections only. For other types of applications, there was no "standard" implementation of real-time communication. Web browsers couldn't be expected to support it by themselves, and they usually needed third-party plugins to do the trick. Think Flash and Java "applets" - remember how clunky those could be?

Real-time functionality could also be achieved (perhaps I should say mimicked) by using "asynchronous javascript" techniques - AJAX in particular. This would usually involve an open web page sending repeated requests to a server - messages to the effect of "got anything new for me yet?" If there wasn't anything new yet (and there usually wasn't) then that request was essentially a waste of server resources.

Enter the "Web Socket"

In 2011, the W3C commission changed the game by standardizing the WebSocket protocol. These days, "real-time" communication can be as simple as opening up a Web Socket with javascript:

var wsUri = "ws://";
websocket = new WebSocket(wsUri);

After that, you just need to set up a few rules to tell the page what messages to send, and how to respond to the messages it receives, and you're off and running.

Make it Compatible!

There is one drawback to the method above - it's only compatible with the most modern web browsers. For example, Internet Explorer versions 9 and below are not compatible with web sockets. Take a look at this chart to see what I mean. If you are building a real-time application for a business and you need to know it works for everyone, then you simply can't get by using vanilla WebSockets.

Thankfully there are a number of tools available that allow all browsers to support WebSockets. At ArcStone, we've zeroed in on - its ease of use and reliability have made it the the de facto industry standard.

Where Does Node.js Fit In? is based on Node.js, a server-side Javascript platform that has revolutionized web application development in the last few years. Whereas a normal server handles one process at a time, sites built on Node can easily juggle multiple processes at once. That's because Node breaks the entire server-client interaction down into discrete "events" instead of one monolithic "page." Let's make a quick comparison.

Say there are two sites - one built on Node and the other built in PHP. Each site receives three requests, X, Y, and Z, in that order. The PHP site would receive and process each request in turn. It wouldn't start processing Y until it had sent a response to X, and it wouldn't start processing Z until it had sent a response to Y. If X takes a long time, it will hold up Y and Z. In the Node site, the server would say "I've received the request for X, it's being processed. What would you like, Y? Oh look X, your response is ready now. Can I help you, Z?" Y doesn't have to wait for X to receive a response, and Z doesn't have to wait for Y. Depending on the nature of the various requests (and how long it takes to process each one), Z might get its response before X does. No single request can hold up the others.

Because Node is event-driven, it is ideally suited for real-time applications where a user clicking on a page might send multiple unrelated requests within the span of a few seconds. Or where thousands of users are making multiple requests all at the same time. There are trade-offs, though: Node doesn't have quite the same processing power per request that PHP or other backend languages offer. So if each request in your application is likely to use a high amount of server resources, Node may not be the best choice. Node and Socket are better suited for handling a high-volume of messages, when each message requires a relatively small amount of server processing power.

Is Real-Time Right for You?

That depends on what kind of application you'd like to build! Real-time applications are great for social networks and chat, or for apps that "track" sports scores, stock markets, or other news. If you'd like the application to track stock prices and calculate how that affects an individual user's retirement portfolio, you might be better off using a more traditional server-side language such as PHP. That doesn't mean you need to sacrifice that real-time feel entirely - you may have a real-time application written in Node that communicates with a more computationally intensive application written in PHP, for example. There is no shortage of options.

Topics: Digital Marketing, Design and Technology