Oliver is linking to an article from Adaptive Path, which has been kicked around the web quite a few time recently. Some comments:
Firstly, Tao doesn't like the kind of "this is the future of the web" vibe weaved through this article. Yet another "standard" that is going to change the world. People, this stuff has been out for ages! To say that it is now "mature" and "stable" is non-sense. It has been the same way for many years now. Tao has been part of several projects were XMLHTTPRequest or something close to it (using a java-applet to basically do with XMLHTTPRequest now does) was used, dating back to 1999. This statement is not here to impress, just to show that to cry Revolution! about it now is silly.
Secondly, the author misses a very key point: XMLHTTPRequest (XHR) is nice, but as soon as you want to do anything beyond the most trivial things it gets hard. Really hard. This is because HTML simply isn't a good way to preserve state. Yet when you get all your data and updates from the server in the background using XHR and then rendering the page using that information, that is exactly what you are doing: storing application state in HTML.
Sure you can keep lots of things around as JavaScript objects, but that too gets really messy, really fast. The possibility of getting "out-of-sync" with the state of the server is suddenly looming very large, as basically you are trying to keep both the client and the server on the same page all the time.
On top of this, there is debugging to be considered. Instead of merely checking the HTML of a rendered page, you need to check with a DOM inspector (if you browser has a good that is!) to see what the state of your DOM tree is like. Then you have to check a javascript debugger to see what the client-side version of the current application state is, then you need to verify the XML you created and then you can see if there is a problem on the server side.
All of that is fine for relatively simple things, but as anyone who has ever build a LARGE web-application with these techniques knows: things get really complex and hairy, really quickly.
What is needed is some kind of standard in Javascript that can be used to simplify these things. Perhaps something that allows you to define a mapping between a (set of) XML elements in the XHR document and an element in the HTML. Preferably with the ability to plug in some kind of logic in the middle to translate between them if needed. This will go some way, but not all the way by far.
Tao does agree with the author that developers need to start thinking in a different way. But that has no so much to do with what is possible, but rather what most web developers are and are not capable of doing.
The problems ARE technical. They may not be insurmountable, but they are there and they are big.
