I agree with the approach indicated by the title ("caution required"), but the tone of the article veers toward being alarmist.<p>Takedown articles tend to share similar characteristics. Many are on a
mission that emphasizes the
negatives of their subject, even minor ones, while overlooking the positives
and handwaving away problems with the alternatives.
They set the bar higher for the subject by finding issues that it
shares equally with its alternatives, and presenting them as damning evidence against it (since users may expect it to be better and be disappointed). The specific alternative that's
held up as superior to the subject varies from point to point--no one
alternative is actually superior in all points. They may even acknowledge that
many of their arguments are weak, but make up for it in volume.<p>In its favor compared to such articles, this one does make some attempts to be evenhanded, but they're
overpowered by the dramatic language used to make the opposing points.
(For example, the brief acknowledgement that point 1 is the "weakest argument
against WebSockets"
is surrounded by phrases like "wreak havoc",
"weird stuff will <i>definitely</i> happen", "rogue proxies will break you").<p>This article puts itself squarely in the category of "the case against".<p>A more balanced article might discuss:<p>1. The situations where you might want to avoid WebSockets (no HTTPS, IE 8 & 9 compatibility, a server platform without good support, or where they don't provide actual usability benefits).<p>2. Pitfalls that both long-polling and WebSockets share (you have to handle reconnections and synchronize state, be mindful of the open connections when reconfiguring a load balancer, account for server load, and use a server platform with good support for long connections).<p>3. Differences that can be viewed just as reasonably in WebSockets' favor, which
the article counts as negatives. Example 1: Resynchronizing state after a network interruption is necessary with both long-polling and WebSockets, though the article notes it as a WebSockets disadvantage. The reconnection process is explicit with WebSockets, but some long-polling libraries make it very easy to ignore these events, leaving the client out of sync. Example 2: WebSockets aren't limited to 6 connections, unlike long-polling, so you won't get a silent connectivity roadblock on some tabs when the user has several of them open.<p>4. Advantages unique to WebSockets: responsiveness is improved due to not needing to send HTTP headers with every request and response, and the underlying TCP connection is already warmed up; load balancing and redundancy may be simplified by no longer requiring a session affinity mechanism (because the connection itself preserves short-term state, which can be
re-established by the client transparently to the user in the rarer event of reconnection); less overhead than long-polling; a whole class of problems resulting from cookies as the sole mechanism of state transfer is avoided; the same protocol can be implemented simply and efficiently by native mobile apps.