Sounds like Shawn Bracewell is the person to really credit — non-asynchronous XHR is unusable, and unused.
Jim's remarks here are a little over the top. At KnowNow in 2000 we were asynchronously getting data from the server and preserving document state on the client by implementing Comet in in Netscape 4 (and IE 4), by using a frameset with zero-height frames. These days long-polling frames that finish loading when there's an event are more common, but we were using endless HTML documents that would get a <script> tag added when there was an event. The <script> tag would invoke top.somethingorother(data). A second invisible frame was used to send data back to the server as HTTP POSTs.
We had a bunch of bodgy code to handle the case where you have several windows open doing Comet to the same server, ensuring you only ever have one persistent connection; otherwise the two-connections-per-server limit kicks in, and the page stops loading forever. It's more sensible to use wildcard DNS to circumvent this restriction.
XHR is a much saner way to do AJAX, and Websockets are a much saner way to do Comet, but you can do AJAX and Comet without them. XHR didn't "change everything" and "put the 'D' in DHTML". It just made it more convenient.
I wouldn't say this at all. We could have gone in a completely different direction with Javascript, even back then: spawning numerous lightweight processes running userspace code which then sit in a blocking "receive" state whenever they want to wait for the result of an XHR. In other words, Javascript could have been Erlang for the browser, instead of the odd OS7-like cooperative-multitasking abomination we have now.
(What we did get are Web Workers, which are full OS threads you can't even message if they're doing something synchronous. What's even the point of these?)
Sure, non-asynchronous XHR could have been usable. Opera at the time actually did give you multiple JS threads, but no locks or other synchronization primitives, so it was effectively unusable. We complained and, perhaps coincidentally, they "fixed" it by making it work like IE and Netscape.
Ah, the memories. I wrote the first non-KnowNow client for this data stream, at their request. For some odd reason best left buried in the sands of time, they wanted me to do it in VB6.
A comet server I work with still supports foreverframe for browsers without websockets or multipart-replace because for fast updating data, it's actually much more performant than long polling.
True. That's why polling is also supported as a fallback. Although with fast updating data, there's practically no difference between long polling and simple polling.
Jim's remarks here are a little over the top. At KnowNow in 2000 we were asynchronously getting data from the server and preserving document state on the client by implementing Comet in in Netscape 4 (and IE 4), by using a frameset with zero-height frames. These days long-polling frames that finish loading when there's an event are more common, but we were using endless HTML documents that would get a <script> tag added when there was an event. The <script> tag would invoke top.somethingorother(data). A second invisible frame was used to send data back to the server as HTTP POSTs.
We had a bunch of bodgy code to handle the case where you have several windows open doing Comet to the same server, ensuring you only ever have one persistent connection; otherwise the two-connections-per-server limit kicks in, and the page stops loading forever. It's more sensible to use wildcard DNS to circumvent this restriction.
XHR is a much saner way to do AJAX, and Websockets are a much saner way to do Comet, but you can do AJAX and Comet without them. XHR didn't "change everything" and "put the 'D' in DHTML". It just made it more convenient.