Caveats? Sure, here's one: Bye-bye browser back button and with it the principle of least astonishment. It can be worked around in a dirty hackish kind of way, but it's something to be aware of and always worked around if you care about it. The easiest workaround manipulates the browser history on each update, bringing the back button back into more or less normal operation, but then the astonishment (somewhat) remains because the browser history grows and grows and pushes things the user might want to get back to right off the stack.

Howzabout a pitfall: It's asynchronous, so if the sequence of client side events matters you might be surprised every now and then. Suppose you're using (for example) a scriptaculous Sortable to permit the user to rearrange things, and you don't want to force him to poke a button to tell the server that he's done sorting so you're firing off an XMLHTTP request on every drop (via Sortable.update and Sortable.serialize). Wow, slick. BUT, it's asynchronous, so the sequence in which the user does things is not necessarily the sequence in which the server responses to those things are received by the client. You can't count on things arriving at your server-side application in the order the user did them unless you jump through some hoops on the client side to (FIFO) queue your XMLHTTP requests. Then, if the server goes away, you probably need something on the client side to restore the client to the last known good state. Hello, Astonishment :(

You might give a look at HTML::Prototype and/or HTML::Prototype::Effects (scriptaculous "embedded" in Perl).