My field-experience with helper modules like these has been mixed.   They sound helpful, and I am quite sure that they are, in appropriate circumstances, but I consistently find that, if I start out with one of them, I do not finish with any of them.   (Let me stress that this is meant as no slight whatsoever either against these packages, nor against their authors!)

Usually, I find that I must knuckle-down and write JavaScript code, using some existing framework or another (Prototype, ExtJS, pick-one...) to do the necessary browser-specific heavy lifting on the client side ... which is now the side where everything that the end-user sees now takes place.   The user is no longer talking to “your Perl program,” running on a server someplace.   Instead, the user is talking to a JavaScript program running on his or her browser, and it is talking to your Perl program.   (Naturally, a CPAN module designed for use with the client-side framework that I have selected is used to decode the request and to encode the response.)   The unfortunate consequence of this, is that I am now writing and maintaining two programs, but c’est la guerre.

Again to my way of thinking, the client is not “telling the server to call this-or-that Perl module.”   The client is “making a request,” and really doesn’t know or care how the server carries out that request.   This is the approach, and the mind-set, that works best for me.

Session-cookies are, of course, fundamental to all HTTP protocols, so every incoming AJAX request will be accompanied by such a cookie (or, equivalently, by an authentication string which your client is obliged to keep and to send with every request).   Your server-side code has to validate this string with every request, and then use it to retrieve session-state data from the server-side store that you have made for that purpose.