The DOM model is exactly the same one you get when you open tools button in your browser and see DOM Inspector.  What you see there, you can read and change in javascript.  This is the same "DOM" that you may be aware of as a key concept in XML processing.   DOM provides means of setting and changing attributes and of detaching, adding, and creating new elements (nodes) in the object hierarchy.   In essence a web browser is an XML parser (admittedly with some other things added in!) and this is just treating the things you see on the page as parts of an XML document with the added "magic" that when you remove something from the tree, it disappears from the page and when you add something, it appears (often moving other elements of the page to accommodate what you've added).  

XMLHttpRequest is the part which allows asynchronous happenings.  The part I didn't know about until recently though evidently it's been around for nearly a decade.   This object has means of building whatever you might need to present to a web server - cookies and form parameters, anything you might be sending from a form or a complex url, and get the results back into your javascript program.   And as your program can continue until the results come back, not necessarily waiting, your javascript can do many things and deal with the results queued as they arrive.

Javascript itself is a far more powerful language than I originally expected it to be.  There is an adequate if not extensive set of built in features and functions.   That it is a prototyping language rather than a class based language takes some getting used to - not least because all of the books and tutorials are downright wrong in explaining how to build an OO equivalent class capable of inheritance (by assigning [including functions] to the prototype of the class name, NOT the constructor).

Being interested in learning new things, the power of javascript, with its built in access to the DOM and the request object has parochially thrilled me.  I'm hooked.

The weak link of course, is the browser.  Each browser supports different invocations of the AJAX objects and different levels of support for DOM elements.  IE in particular is notorious for requiring DOMParser and XMLHttpRequest to be invoked explicitly as ActiveX objects, Microsoft refusing even the trivial courtesy of building wrappers in the javascript namespace so that they can be invoked with "new" as in the Firefox.  

This mishmash of supported features in different essentially means that the bulk of most AJAX libraries is a scaffolding of trivial conditionals holding together multiple but even more trivial but differing setting, retrieval and invocation of attributes and methods.  The sheer number of AJAX libraries tells me that, whenever possible, I'm better off developing my own conventions and standard objects and functions in javascript.    The horror of cross browser support tells me that whenever I can get away with it I should will develop only for Firefox - and ideally only the intersection of Firefox and w3c recommendations.  So far I've only written two AJAX apps at work and as they were both internal maintenance apps I haven't gotten fired for var req = new XMLHttpRequest; if(!req){alert("This application requires Firefox 1.5 or better browser!); throw "Bad, bad  Browser!"; }.  Obviously I couldn't do this for a "production" environment where users may have various browsers and an unwillingness to upgrade for my application.   But I suspect a lot of programmers will write for a single browser's API for their own purposes ... and publish it.   And sooner or later it will be obvious that one browser has "won".

This is an unstable situation.  If I am like other programmers there is a lot of frustration over not having a TRUE universal lightweight API for user interaction.  But Firefox is available -free, in all senses - for virtually all platforms now, and is the most w3c compliant browser.

AJAX is truly a mess right now, but it's a beginning of something good.  We have returned from whence we came.   Client-server returns.  

I have a hazy vision of all graphical desktops dying, being replaced, by an interface - perhaps even a low level interface to the video card drivers - which does nothing but run an (or multiple) instance of a web browser.  And ALl the presentation libraries replaced by built in web servers.  There's a long way to go and a host of protocols to be fought over before such can come to pass, but I suspect that in the long term, it will.