by Anthony Shull
Before Ajax came into popular use users could only load new information into a page if they refreshed the entire page. That was a waste of time and bandwidth as every page load would have to include a lot of redundant information (the header, footer, and navigation) that wasn’t unique to the request. From the user’s perspective, it was a jolting experience which was very far from a desktop application. Ajax gave us developers the ability to communicate with the server without having to reload redundant information. It saved a lot of unnecessary bandwidth usage and gave applications a more desktop-like feel. The term Rich Internet Application was coined to describe this new breed of user experience.
Google Calendar is a perfect example of an Ajax application. But, Ajax had one glaring problem. You could send a request to a server, get information back, and then update a page with that new information, but that communication had to be instigated by the client. The server couldn’t send information that wasn’t requested of it. That doesn’t sound like much of a problem, but there are many applications where the server needs to communicate information without it being requested–scores for a football game, stock prices, chat messages, etc. Almost immediately after Ajax came into the spotlight developers started tackling this problem with complicated workarounds which all fall under the umbrella term Comet.
Most implementations involve the use of long-polling which, in a nutshell, means that you send an Ajax request to the server. It is not returned until the server has something new to communicate. Another request is then sent back to the server to again wait for any new information. That’s how Facebook’s chat works. Unfortunately, Comet techniques require developers to use web technologies in a way they were never intended to be used. They are difficult to implement and hard to understand. Furthermore, because they don’t follow a standard, browser support is very spotty. But, HTML5 WebSockets correct that.
WebSockets allow for bi-directional communication between a server and a client meaning they can be in constant communication in real-time. No page loads or Ajax requests are necessary. Data only gets sent when it needs to be. Because it’s a standard it promises to be more robust and simpler to implement than Comet or Ajax.
WebSockets will definitely revolutionize the way we think about internet applications. It will take some time, however. Currently, only Chrome and Safari support WebSockets. But, Firefox is adding support in Firefox 4 and Opera will as well with Opera 10.7. It is still unclear whether or not the upcoming Internet Explorer 9 will also support them. Until support is more ubiquitous socket.io bridges the gap between Comet and WebSockets. If a user’s browser supports WebSockets, those will be used; if not, socket.io falls back to Ajax or even Flash Sockets. Most importantly, it wraps these differences in a common API so that developers only have to program one application that can be used by anyone. So, though the next major development in web communication is a little ways off we can start preparing for it today.
Anthony Shull will be teaching CE 9555 Digital Short Course – Adobe Flash Fundamentals, CE 2416 Server-Side Web Development with PHP + MySQL and CE 2413 Web Design II during the spring 2011 Continuing Education semester.
Keep an eye out for an interview with Anthony later this month!