One of the main ideas behind Ajax is that you want to minimize page loads, because they take too long, and the user does not really want to see the whole screen repainted just because one little thing changes. So instead of requesting another web page when an event handler fires, an Ajax site sends a request to the server either delivering or asking for some small piece of information. The ability to do this has been around, it just took a while for people to figure out how to use it effectively. The way this actually works is that the browser (in some event handler, usually) determines that it needs web server activity. This can be a "get" (a request that does not change the state of the server, but simply returns information) or a "post" (that does change server state). It is not strictly required that these requests be used, but it is considered good practice. The actual name of the type of messages sent to the server is XmlHttpRequest (sometimes abbreviated to XHR) but you don't need to know this to understand how it works. The XHR has been around since about 1999.
So in our example, the client (browser) sends a request to the server that says: Get me all the models for brand "Ford." How does it do this? Basically, it just issues a request for what looks like a web page but isn't. So the URL for the page might look like http://mysite.com/getmodels.php?brand=ford when it arrives at the web server. Doesn't this just load another web page from what the server delivers? Well, probably not. If the response does not contain any HTML, the browser will not consider it a web page load and will not try to load it into a DOM tree. The current web page stays loaded. For some browsers, this works best if the server returns a header that tells the browser what kind of page it is. So if the header says "This is XML," then the browser knows it isn't to be loaded. The browser will simply check to see if someone is waiting for the packet that just arrived from the server, and will call a function to report the arrival.
"Wait!" you may be saying, "How does the browser know? Is this an event listener?" Well, sort of. It's better to think of it as a registered callback function. When you write the code that sends the request in JavaScript, you tell the browser what function to call when the data arrives. Of course, there are issues if you are working asynchronously and have more than one request pending, but it's generally easy to work around these problems.
It's interesting to note that these server side scripts (often written in the language PHP) are usually tiny. They can do all sorts of things like access a database, and can even be used to produce an entire new web page. But in Ajax, they often just find the answer, put it in whatever form the client program expects, and effectively write it out using a print function. Whatever they "emit" gets sent back to the client, which then takes over and does something with the data - in the callback. Most of the code in many Ajax systems is written in JavaScript and runs on the client. This helps keep the server from getting too overloaded, since it has less work to do.
Nextinsert content here