Browser Wars: Websockets vs. AJAX

This is the first in a series of articles on Building Realtime HTML5 Apps. I recently created a new framework called, and I wanted to share my thoughts and ideas on building realtime web applications.

This series is going to be less of a how-to guide, and more of a 30,000 foot view of the realtime web and the potential for the next generation of web applications.

A Brief History of Websockets

Websockets is a new standard from 2011, that hopes to bring realtime (technically, “near-realtime”) communication to the web.

Websockets provide full-duplex communication channels over a single TCP connection.

As of this writing, every major browser supports Websockets, except for Android. And thanks to some great open source libraries like, there are transparent fallback mechanisms for older browsers, like AJAX long-polling and Flash.

The fact that a Websocket is a fully bi-directional communication channel between the browser and server immediately opens up some very interesting opportunities for web applications. Because the connection is persistent, the server can now initiate communication with the browser. The server can send alerts, updates, notifications. This adds a whole new dimension to the types of applications that can be constructed.

Outside the scope of browser-based applications, Websockets are a boon to the Internet of Things. End devices attached to the Internet now have a way of maintaining bi-directional communication channels to the their command and control servers, whether this is a thermometer that’s part of a connected home experience, or a fleet of nodecopters terrorizing an apartment.

The future is bright for Websockets technology, but the question remains, will it become the dominant mechanism for transporting data across the Internet? Will it replace AJAX?

The Story of AJAX

The story of AJAX is more of a traditional web story, an accidental invention that has been used/abused beyond it’s original conception.

AJAX gives web browsers the ability to fetch data from the server without refreshing the entire page. It had its beginnings back in 1999 as a proprietary extension to Internet Explorer 5. Mozilla, following Internet Explorer’s lead, created a similar API for their browser, which soon made AJAX a de facto standard.

As web applications have moved from the server to the browser, AJAX has become the primary transport mechanism for data. This concept has been pushed further by browser-based application frameworks like Backbone and Angular which rely heavily on AJAX for data communication.

Beyond the AJAX technology itself, a standardization has emerged in the industry around REST as the primary architectural style for developing browser-based applications (and web-based APIs). REST is based almost entirely on the semantics of the web, and it has helped usher in the resurgence of parts of the Web standard that had largely been abandoned or forgotten, for example the use of HTTP verbs PUT, PATCH, and DELETE.

“Live” Applications, “Hot” Data

Largely, I think the question of Websockets vs. AJAX comes down to what types of applications and user interfaces we will be building in the future.

Most web applications currently operate by simply responding to user interaction. You click a button, called “Next”, and this causes the browser to fetch the next data set, and then render that to the page. This is great, but it’s still a very limiting model.

Websockets have the potential to not only connect end users to the server, but also to each other, the Cloud, and the entire Internet of Things in ways not thought of before. As time goes on, the applications we build will literally come “alive” with data, and that connection via Websockets back to the server will help provide a stable platform for an endless array of interesting interactions.

The idea of having “hot” data streaming in and out of the browser will become the “norm” instead of the exception. Developers will be able to construct Gmail and Facebook-like functionality without a billion dollar investment. Thanks to open web standards, the power of Websockets will truly help bring application development to the next level.

The Myth of the Request/Response Cycle

The request/response cycle that we are so heavily reliant on in the web development world is largely a myth. In reality, the browser and the server are two asynchronous nodes in a network. A request does not guarantee a response.

In point of fact, the entire AJAX protocol could be built using Websockets technology. This makes Websockets a literal superset of AJAX. So it makes sense that we might abandon a limiting technology for a broader technology.

Embracing Bi-Directional Communication

I think that while REST/AJAX has served the web community well, it is probably time to start looking ahead to the future. And while it might be tempting at first to try to fit Websockets into the REST architecture that we are all so familiar with, I think that ultimately this will prove to be limiting. I think the best approach is to embrace realtime communication as a new development paradigm, and see what interesting ideas and patterns we can come up with based on this new concept.

I’m excited to post my first article on LosTechies! I know I am in the company of some truly incredible individuals, and much thanks to Chris for posting for me.

Also, when it comes out, checkout the next article in this series, Building Realtime HTML5 Apps!

Brad is a badass JavaScript coder who enjoys building cool stuff and long walks on the beach. As the Founder/CTO at TechPines, he has worked with large companies and startups to build cutting-edge applications based on HTML5 and Node.js. He is the creator of, a realtime HTML5 framework, and is the author of Embracing Disruption: A Cloud Revolution Manifesto.

About Chris Missal

Oh hey, I'm a Senior Consultant for Headspring in Austin, TX. I've been working in software professionally since 2006 and I really, really love it. I'm mostly in the Microsoft world, but enjoy building computer things of all sorts (to be vague). When I'm not slinging code, I'm probably out and about slinging discs, bowling balls, or good beer with great friends.
This entry was posted in HTML5, JavaScript. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • tyroneavnit

    Very very interesting article. Sorry if I missed it, but what browsers does your library support? Fallback to browsers that don’t support WebSockets?

    • techpines

      The library I wrote,, isn’t actually built directly against WebSockets, it’s built against, which is a Websockets wrapper. And has a number of fallback mechanisms, including XHR/JSONP long polling and Flash.

  • xwz86

    I’ve been using sockets for realtime connections inside the browser (using flash – it has 99,9% avalability) since 2007. What are the news here? Why do people suddenly think that something like Socket inside a browser is news?

    • techpines

      You’re right, realtime communication itself is old news, and in point of fact, a lot of “new” web technologies have been around in one form or another for a very long time.

      The “big news” is that the Web is an open platform that touches billions of devices. It also has the largest developer base on the planet. So when technologies make it to the Web that are “new” to the Web. It tends to be a big deal.

  • Gekkor McFadden

    The web socket provides an interesting new attack vector. Quite likely, server can better attack client PCs and client PCs can better attack server.

    • techpines

      Yes, it’s definitely another attack vector. Websockets can be run over SSL, and the spec already has CORS built-in, so just like any other technology it’s on the developer to properly authenticate end-users.

  • Geoff Gerrietts

    WebSockets are great, and I agree that we-the-developers are very likely to use more and more of them as time goes on. I think your key insight — that WebSockets provide a lot more flexibility and power than AJAX and request/response — is absolutely on point.

    But keep in mind that WebSockets have a very different server-side profile than request/response or AJAX. A WebSocket is a stateful, open connection between client and server; that’s true of Socket.IO’s Flash fallback, too, though admittedly the fallback to polling is just AJAX. A key part of WWW systems architecture has historically been a stateless, transient connection, which meant that a single server could manage much higher client load than traditional client/server models, because the per-client demand on the server only lasted as long as it took to generate a response.

    Technologies are emerging that permit large numbers of simultaneously-connected clients, but even so, it’s currently a profound challenge to significantly scale up persistently-connected applications, and those applications have a much different load profile than we have been led to expect out of web applications to date.

    • techpines

      I completely agree, and I hope to address some of those concerns in one of the upcoming articles. There are real life practical problems with scaling a web sockets based application. The problems are solvable, but in these early stages, there are not as many supporting technologies so it’s a little like the wild, wild west.

      To your comment on transient connections being easier on server load, I think that this is where things get a little less clear. Sure the connection is transient, but we’re making tons of them to mimic a persistent connection, plus most applications maintain state in the form of a session. Everything changes so rapidly, the computing power of servers, the speed of the network, the technology stacks, that what made sense from an engineering standpoint back in the ’90′s may be less relevant today. My opinion is that the tradeoff of server load for functionality is probably workable (engineering required) based on where we’re at currently. I think the bigger problem is the ecosystem to support the persistent connection paradigm, which you made a great point on.

  • Matt

    Great article, looking forward to reading the next pieces too! However, I was hoping you could give some insight into Server Sent Events? I did a project a while back using WebSockets, but I always thought SSE would have been the better option and it looks to be very easy to setup/implement.

    With all the talk about WebSockets, it seems this particular piece of technology goes unnoticed, or perhaps it has limitations/drawbacks I’m not aware of?


  • João Parreira

    Great article Chris. WebSockets are definitely changing the web development landscape. If any of you guys out there want to take full advantage of WebSockets (and several fallbacks when they are not available) without the pain of managing and scaling servers, you might want to checkout the Cloud Messaging Service. More info at

    • I can only take credit for posting this. My friend Brad was the one who wrote it, I just wanted to share his ideas with all the Los Techies readers! :)

      • João Parreira

        I stand corrected. Great job Brad.

  • Guest

    > Outside the scope of browser-based applications, Websockets are a boon to the Internet of Things. End devices attached to the Internet now have a way of maintaining bi-directional communication channels to the their command and control servers,

    I’m confused — why would these Internet of Things applications (such as your thermostat) be running in a browser at all, and therefore need WebSockets? We have plain ol’ TCP over standard/BSD sockets just like we’ve had for decades.

    What would probably be useful is if the WebSockets protocol/libs on the client and server could transition automatically between using AJAX/long-polling, etc., and a socket requiring a persistent endpoint on the server so that the latter is only used during periods of high application demand, and do this so that it’s transparent to the application writer (other than allowing the specification of hints/heuristics) – so as you throttle up you get sockets, and if you become idle or throttle down you get something that doesn’t tax the server.