Thanks to its chattiness, the traditional communications protocol for shuttling data around the World Wide Web is not very efficient. Now an HTML5-related standard called WebSocket could cut some of this networking overhead, speeding responsiveness in Web applications, argued a Web app expert.
"If you were not constrained by the limitations of HTTP, what sort of truly interactive Web applications would you build?" John Fallows rhetorically asked, before a theater filled with Web developers and managers attending the HTML5 Live Conference held Tuesday in New York. Fallows is the chief technology officer and co-founder of messaging software provider Kaazing.
[ Go deep into HTML5 programming in InfoWorld's "HTML5 Megaguide Deep Dive" PDF how-to report. Then understand the issues surrounding HTML5 today in InfoWorld's HTML5 Deep Dive PDF strategy report. | Learn how to secure your Web browsers in InfoWorld's "Web Browser Security Deep Dive" PDF guide. ]
The use of the W3C's (World Wide Web Consortium's) WebSocket could enable a new generation of real-time, "zero-latency" Web applications whose communications requirements would be too demanding for today's HTTP protocols, Fallows argued.
As an example of WebSocket speediness, Fallows showed off an implementation of the popular 1990s computer game Quake II, which Google engineers had ported to run entirely within a browser, using WebSocket to bridge the server and client. Running this game online would not have been possible through HTTP, he argued.
Fallows also demonstrated a simple stock ticker, in which the values of about 10 stocks were updated every second or so, showing a near-constant flow of ever-changing values.
Created in 1991, the HTTP (Hypertext Transfer Protocol) is now used for most all of the traffic on the Web. Because it was designed for document transfer, it really isn't well-suited for modern-day Web applications, Fallows argued.
HTTP's chief shortcoming is that it is half-duplex, meaning it can only communicate in one direction--either from the client to the server or from the server to the client--at a time. Users may not notice this because communication exchanges between the client and server can take just a few hundred milliseconds. But as Web applications increasingly receive and send more data, this back-and-forth communication will only add more noticeable latency to the application.