Modern Full-Stack Development

 A Quick Detour: AJAX
AJAX is a technique that came to life, so to speak, at the hands of one Jesse James Garrett 
in an essay he wrote in February 2005. There, he coined the term AJAX, which stands 
for Asynchronous JavaScript and XML. The interesting thing about AJAX, though, is 
that it doesn’t have to be asynchronous (but virtually always is), doesn’t have to involve 
JavaScript (but virtually always does), and doesn’t need to use XML at all (but probably 
doesn’t 99+% of the time).
AJAX is, at its core, an exceedingly simple and, by no stretch of the imagination, 
original concept: it is not necessary to refresh the entire contents of a web page for 
each user interaction, or each “event,” if you will. When the user clicks a button, it is no 
longer necessary to ask the server to render an entirely new page, as is the case with the 
“classic” Web. Instead, you can define regions on the page to be updated and have much 
more fine-grained control over user event handling as a result. No longer are you limited 
to simply submitting a form to a server for processing or navigating to an entirely new 
page when a link is clicked.
The interesting thing about AJAX is that it is in no way, shape, or form new, and it 
actually wasn’t even when Mr. Garrett coined the term. A decade ago, when AJAX was 
still somewhat new, I liked to say that you could always tell who has done AJAX before 
and who hadn’t because those who had are mad that it was a big deal and they didn’t get 
credit for “inventing” it themselves!
Nowadays, the term AJAX isn’t used as much as before. People tend to talk about 
“out-of-band requests” or simply “asynchronous requests” or, indeed, simply “server 
requests” because it’s pretty much the de facto way of communicating with a server on 
the Web when you aren’t refreshing the entire page.
At its core, AJAX works because of something invented originally by Microsoft: the 
XMLHttpRequest object. This is a JavaScript object that allows you to write code like this:
let req;
Chapter 9   Delivering the gooDs: MailBag, the Client

---

239
let which;
function retrieveURL(url) {
  if (window.XMLHttpRequest) {
    req = new XMLHttpRequest();
    req.onreadystatechange = processStateChange;
    try {
      req.open("GET", url, true);
    } catch (e) {
      alert(e);
    }
    req.send(null);
  } else if (window.ActiveXObject) {
    req = new ActiveXObject("Microsoft.XMLHTTP");
    if (req) {
      req.onreadystatechange = processStateChange;
      req.open("GET", url, true);
      req.send();
    }
  }
}
function processStateChange() {
  if (req.readyState == 4) {
    if (req.status == 200) {
      document.getElementById("urlContent").innerHTML = req.responseText;
    } else {
      alert("Problem: " + req.statusText);
    }
  }
}
Even if this is your first time seeing such code, I bet you can understand it without 
much trouble. In short, you create an XMLHttpRequest object (branching based on 
Chapter 9   Delivering the gooDs: MailBag, the Client

---

240
whether the object exists or not, because for a while, not all browsers exposed the 
object in the same way). You then hook a callback function up to it that will be called 
whenever the state of the object changes (e.g., when it connects to the server or when 
the response comes back – the object has an entire lifecycle you can hook into). You 
give it the URL to connect to, optionally tell it about any data you’re sending (in this 
case, there is none), and finally, send the request. The callback function will be called, 
multiple times, in fact, based on the lifecycle events provided. We only care about the 
readyState 4, which is what occurs when a response comes back. Then, assuming we 
got an HTTP 200 back, we take the responseText, which is what the server sent, and 
insert it into a DOM node, presumably a 

, or do whatever else we want with it. 
That’s it, that’s all there is to it.
Nowadays, you wouldn’t even write that most likely, and instead, you’d use the 
newer Fetch API. Although not quite ubiquitous across all browsers, it’s not supported by 
the majority, so now you can write code like this:
const response = await fetch(url);
Yep, that’s much better, isn’t it?
However, aside from the browser having to support this API, it also must support 
async/await, as you can see. If you want to reach the widest audience possible, but you 
don’t want to write all the XMLHttpRequest code as in the preceding text, you’ll probably 
want to use a capable library that abstracts all of this away from you (and, most likely, 
provides many other benefits). For MailBag, that’s exactly what we’re going to do!