AJAX Fundamentals - ALL IN - 2026

A quick intro to this section

Broadly speaking, HTML and CSS are used to build STATIC sites. But in this day and age, this does not cut it. We need to build dynamic sites, and this is beyond the scope of HTML and CSS.

This is where JavaScript comes into the picture - and AJAX for that matter!

When a web page talks to a server, there are certain rules that they need to follow. These rules are governed by the HTTP protocol.

This protocol is pretty fundamental to the functioning of the internet because it is what is used to fetch web pages and many other resources. When you send a message using HTTP it is called a request. When you send a request you should expect a response. Browsers get the HTML of web pages by sending requests to specific locations on the internet and rendering the responses they get.

HTTP, or Hypertext Transfer Protocol, is the set of rules for transferring files over the web. It is a client-server protocol, which means that one computer (the client) requests a file from another computer (the server). The server then sends the file back to the client.

In the previous lecture I mentioned that the 2 most important things about knowing about HTTP is: 

1. that a URI is required. This makes sense right, because the browser needs to know where to send the request to.

2. sometimes data is attached to the HTTP request, but not always.

In this lecture I want to discuss the URI in a little more detail. I also want you to know that the HTTP protocol is not the only protocol. There are others, like FTP and mailto.

Starting out as a developer can be overwhelming.

One of the questions you may be having is why do ports even exist? Well, remember that ports are simply a standard number assigned to each application over internet just to identify the service being requested for. Each operating system vendor has to keep these port in mind when designing their OS.

Up until this point, we've looked at HTTP and that it is used to transfer data between a browser and a web server.

But how exactly do you, as a developer, place data into the HTTP request? 

Great question - let me answer it.

In the previous lecture we have seen how to use Links to send an HTTP request.

But there are other methods too.

Sending HTTP requests are crucial for any dynamic website. We've already looked at 2 ways this can be done in the browser - by using Links and Forms.

In this lecture I want to discuss using Cookies. It is a little advanced, but don't worry about the code. Just concentrate on the concept.

We all make mistakes, including myself.

You've come a long way already. We've seen how browsers can send an HTTP request using Links, Forms and Cookies.

But up until now, we have not spoken about AJAX, have we? 

That is about to change.

Feel free to skip this section.

HTTP was developed by Timothy Berners-Lee in 1989 as a communication standard for the World Wide Web. In other words, it is the language that allows browsers and servers to speak to each other. HTTP allows the exchange of information between a client computer and a local or remote web server. In this process, a client sends a text-based request to a server by calling a method like GET or POST. In response, the server sends a resource like an HTML page back to the client.

HTTP is an application protocol that has been the standard for communication on the World Wide Web since it was invented in 1989. From the release of HTTP/1.1 in 1997 until recently, there have been few revisions to the protocol.

That is, until 2015 came along.

HTTP/2 began as the SPDY protocol, developed primarily at Google with the intention of reducing web page load latency by using techniques such as compression, multiplexing, and prioritization.

HTTP/1.1 and HTTP/2 share the same formats / semantics. This was done so that the requests and responses traveling between the server and client in both protocols reach their destinations as traditionally formatted messages (i.e. with headers and bodies, using familiar methods like GET and POST).

But while HTTP/1.1 transfers these in boring old plain-text messages, HTTP/2 encodes these into binary, allowing for a different delivery model. At a very high level, this allows HTTP/2 to encode requests/responses and cut them up into smaller packets of information, which is very powerful.

HTTP/2 is a major revision of the HTTP network protocol used by the World Wide Web. You know this. But let's quickly recap a few key points before moving on.

Finally, some time for me to answer some common Questions you may have about HTTP/2.

I've spoken a little about HTTP/2 but this section would not be complete if I did not mention the latest HTTP advancement.

That is, HTTP/3.

A quick intro to this section

Synchronous tasks are performed one at a time and only when one is completed, the following code is unblocked. In other words, you need to wait for a task to finish to move to the next one. In asynchronous operations, on the other hand, you can move to another task before the previous one finishes. Pretty powerful right? 

It can be confusing when first starting out to understand how AJAX fits into the whole picture.

After all, isn't JavaScript a single-threaded language? This means that it has to run code synchronously right? Wrong.

Let's find out why.

Synchronous code is also called “blocking” because it halts all other code execution until all resources are available. In this lecture I want to show you that by default, JavaScript is a single threaded blocking language.

Synchronous code is code that executes in a sequential order. This means that each line of code is executed one at a time, in the order that it is written. Synchronous code is typically used in applications where it is important to ensure that the code is executed in a specific order.

Asynchronous (async) programming lets you execute a block of code without stopping (or blocking) the entire thread where the action is being executed.

This is huge.

It means you can have a single-threaded program (like JavaScript), where one thread can run concurrent tasks.

As you probably know very well by now, the internet is made up of a bunch of interconnected computers called servers.

When you are surfing the web and navigating between web pages, what you are really doing is telling your browser to request information from any of these servers. It kinda looks as follows: your browser sends a request, waits awkwardly for the server to respond to the request, and (once the server responds) processes the request. All of this communication is made possible because of something known as the HTTP protocol.

The HTTP protocol provides a common language that allows your browser and a bunch of other things to communicate with all the servers that make up the internet.

This back and forth (between the browser and server) happens a bunch of times, and all of this is fully supported in JavaScript! This ability to asynchronously request and process data from a server without requiring a page navigation/reload has a term.

That term is Ajax (or AJAX if you want to shout).

Asynchronous JavaScript and XML (AJAX) refers to how a browser speaks and communicates with a server. By combining JavaScript code and other technologies like the DOM, web pages appear more responsive since small packets of data are exchanged with the server and web pages are not reloaded each time that a user makes an input change.

And this is the power of AJAX - that it enables a web application user to interact with a web page without the interruption of constant web page reloading.

In this lecture we will visualize what a typical HTTP request looks like, versus an AJAX request.

You can view AJAX as being an engine or 'block of code' that sits in between the browser and server. This engine or block of code deals with the request and receiving the response. This has a huge benefit because now the browser is non-blocking. 

AJAX is a powerful language. You use AJAX with JavaScript, but this is not the only way you can use it. If you don't like JavaScript, there are plenty of third party libraries that implement AJAX behind the scenes.

In this course we will use plain vanilla JavaScript to use AJAX because I believe in learning the fundamentals before moving onto third party libraries.

The Extensible Markup Language (XML) is a simple text-based format for representing structured information.

What kind of information can you store in XML? 

Tons. Things like documents, data, configuration, books, transactions, invoices, and much more. It was derived from an older standard format called SGML (ISO 8879), in order to be more suitable for Web use.

But how exactly does XML differ from HTML and how do you write XML?  

An XML file is an extensible markup language file, and it is used to structure data for storage and transport. In an XML file, there are both tags and text. The tags provide the structure to the data.

In this example I want to show you that in order to parse XML data you need to: 

1. retrieve the XML data

2. create a tree-like model of the data. This is known as the XML DOM

3. you do #2 by using the DOMParser() method

In the previous lecture we managed to parse our XML file to display the TYPE of animal on our HTML page.

I want you to try and do the same for the SOUND attribute, and in this lecture I'll show you my solution.

JSON is a modern alternative to using XML.

JSON stands for JavaScript Object Notation.

I'm sure you've noticed that JavaScript is in the name, right? Let's see what this means.

A brief summary of why JSON and XML were introduced.

The power of JSON is that most programming languages (such as PHP, JavaScript, etc.) have methods to work with JSON data. Because AJAX uses JavaScript, we will be looking at the JSON.parse() method to see how to covert a JSON data object into JavaScript.

Enjoy.

This lecture will get practical because I want to show you how to structure the same data using JSON and XML so you can see the differences with your own eyes.

Working with JSON can be a little daunting. Don't worry, I got you covered.

In the previous lecture we saw a simple example of structuring data using JSON and XML.

This will summarize some similarities and differences between the two approaches.

You'll hear many developers say that JSON is always better than XML.

But is this realllly true? 

Really? 

Let's find out.

Sometimes we learn so much we get lost. In this lecture let's summarize what we've learnt so far.

I love my summaries, so sit back and see just how much you've learnt in this section.

A quick intro to this section

In this lecture I want you to code up your first AJAX example using the XMLHttpRequest() with me. That's right - we're getting our hands dirty by diving into the deep end.

Don't worry about the structure of the code or what the methods mean.

We will cover all aspects of the code in upcoming lectures.

For now, all I want to show you is how we make an AJAX call so then you'll have context for the upcoming lectures.

I can't wait.

I want to talk about what a constructor function is. But before I do, let me prove to you that the XMLHttpRequest object is a constructor function.

With the constructor function notation you create an object that can be instantiated into multiple instances (with the new keyword), while the literal notation delivers a single object, like a singleton.

In this lecture I want to show you the difference between creating an object literal vs using a constructor function

New keyword in JavaScript is used to create an instance of an object that has a constructor function.

If you're anything like me, you love seeing what happens if you go against the grain.

So, lets create a constructor function but this time, lets NOT use the new keyword and see what happens.

The new. target pseudo-property lets you detect whether a function or constructor was called using the new operator. In constructors and functions invoked using the new operator, new. target returns a reference to the constructor or function.

Do you recall seeing a custom error message when we tried to invoke the XMLHttpRequest() object? How did they do this? 

In this lecture I'll show you how to use the new.target property to display a custom error message if the user does not call your function with the new keyword.

Pretty cool, huh? 

I'll be honest. I have simplified the meaning of the constructor function just a little. In reality it is also a singleton and it allows us to clearly define private and public variables.

A short introduction to this section

AJAX has humble beginnings. This means it is not the same today as it was back in the day.

Today, we can use the newer Fetch API to make an AJAX call.

So then, if we have the newer Fetch API, why do we need to learn about the original XHR object? 

Great question. Let me answer that for you.

For the first time in this course, I want to teach you about how to set up an AJAX request.

We care about the readyState property in AJAX, which returns the (loading) status of the current HTTP request. The readyState property is read-only, which means you can't manipulate or change its value.

When the value of this property changes, a readystatechange event fires on the document object.

I want to show you an example of how you can physically see the readyState property value in the console.

The onreadystatechange event is triggered every time the readyState changes. This is useful because the readyState property holds the status of the XMLHttpRequest. So usually, we want to execute our AJAX business logic only when the readyState value is 4 - i.e. when the server has finished sending us a response.

An important part when dealing with response data is getting the actual data right? You can do this by inspecting the ResponseText property. It retrieves the response from the server as text. This property is read-only.

A quick step back

The status code is issued by a server response. It is a 3-digit integer where the first digit defines the class of response and the last two digits do not have any categorization role.

HTTP status codes are found in the HTTP header. While status codes are returned every single time your browser requests a web page or resource, most of the time you don't see them.

It can be quite confusing when first starting out what the differences are between readyState and the status properties of the AJAX object.

Don't worry, here's a quick analogy that will drive the point home. 

We have seen that when dealing with an AJAX response, it is not enough that we only listen for when the readyState is equal to 4 - i.e. when the response has been fully downloaded.

This is because we may still have an HTTP error that we need to deal with.

So, in this lecture I want to combine checking for both the readyState and the status code of a request, before we run our main business logic.

The onreadystatechange is a property on the XHR object and is supported in all browsers. Since then, a number of additional event handlers were implemented in various browsers.

One of these event handlers is the onload event.

I want to show you about a property that is unique to the XHR object - the responseType property.

It is a value value that returns the data type of the response. We do this to improve security.

It also lets the author change the response type to one "arraybuffer", "blob", "document", "json", or "text".

If an empty string is set as the value of responseType, it is assumed as type "text".

While handling an asynchronous request, the value of responseText always has the current content received from the server, even if it's incomplete because the data has not been completely received yet.

Let's look at the onerror event on the XHR object - this is a function called when an XMLHttpRequest transaction fails due to an error.

Warning: this is not the same as the Global browser onerror event.

The progress event is fired periodically when a request receives more data. I want to take this time to show you how to keep track of download progress. It's pretty cool.

I want to show you how to monitor upload progress. What is cool about the upload property is that it is unique to the XHR object. This is not available on the newer fetch() API and in fact, it is easier to display upload progress using the XHR object compared to the fetch API.

Let's get into this.

I want to set up 3 buttons, each that make a different XHR request.

In this lecture lets start coding up our solution.

I am going to be building modular code, which will hopefully give you an understanding how JavaScript and AJAX can work so nicely together.

Whew. You've done a lot, and we're almost finished with our challenge.

In this lecture let's finish off our file so that everything is working as expected.

Up until this point, we have only seen examples of using a GET request to a server. 

However, you are now becoming a pro.

You are now ready to start coding a POST request. The HTTP POST request is used to create or post or add a resource on the server. Typically, it will add a new resource to the server. In this example, let's submit some form elements (username and comments) to a PHP server.

Before your operating system can execute PHP code, it needs the correct software. In other words, you need to make sure that your machine has PHP code installed in order for you to execute PHP code. This lecture explains how you can do that.

This lecture we'll finish off our example of creating a PHP server, listening for an incoming POST request, taking the form variables and sending something back to the browser.

Yes, this is perhaps too advanced for this course. So don't worry if you don't fully understand how to write PHP.

I want you to understand the logic.

I'll try keep it as simple and intuitive as I can.

A quick intro to this section

Up until this point we've been talking about the original XHR object which uses the XMLHttpRequest() interface.

But now its time to get serious.

Now we're going to discuss the modern approach to submitting an AJAX request, using the fetch() API. This allows you to submit a request to a server asynchronously, similar to the XHR object.

But there's a big difference.

Fetch uses the concept of Promises.

Fetch is a lot easier to use.

Fetch is easier to read.

Fetch is just ... well ... better.

Fetch uses the power of JavaScript Promises.

The JavaScript Promise object is used for asynchronous tasks. It represents a value which may be available now, or in the future, or never.

Promises are relatively simple to understand, once you understand the basics.

Fetch uses the power of Promises, and we know that Promises are asynchronous.

This by implication means that Fetch is asynchronous.

But before i explain exactly what this means, let me take a step back and remind you the differences between synchronous vs asynchronous.

In this lecture I want to create our very first Promise.

Promises can be in one of three states, at any given time.

The fetch() API gives us a handy way to catch errors.

If a promise rejects, or if any of the then() statements throw an error, the JavaScript engine will look for a catch() block and execute the callback function we define within it.

Let me show you.

Fetch uses the concept of promises, and as we've seen it is not always easy to extract the data from a promise.

Let me explain how .then() and .catch() fit into the entire picture.

When you use fetch(), a callback function is called once a clearly defined operation has been performed. We've used callbacks before in this course when using the XHR object. Remember, event handlers are a good example of a type of callback function.

We know that JavaScript is a synchronous single-threaded language.

Firstly, what does it mean that JavaScript is synchronous, and secondly what does it mean that it is only single-threaded? 

And even a harder question - if JavaScript is truly synchronous and single-threaded, how then can it use the fetch() API to run asynchronous tasks? 

An event loop is something that pulls stuff out of the queue and places it onto the function execution stack whenever the function stack becomes empty. The event loop is the secret by which JavaScript gives us an illusion of being multithreaded even though it is single-threaded.

When we make a fetch() request to a server, we don't simply receive back the required data in one chunk in the data format we require.

What? 

Why? 

Take a step back.

Remember the power of asynchronous requests is that we can let the AJAX engine do all the work in the background while the browser is not blocked for the user. And what's even cooler is that using fetch() allows us to received data back from the server in chunks. In reality this gives us a lot of power as developers, because if we want to (we don't have to) we can extract smaller pieces of data as they arrive from the server rather than wait until the entire stream is downloaded.

Let me not get ahead of myself.

All I want to show you here is that Fetch returns us a promise.

We have already seen that the original AJAX object was the XMLHttpRequest() object.

But this object was pretty tedious right.

That's why jQuery came along and tried to make our lives easier.

Then we had the WHATWG group that created the Fetch standard.

We are getting more and more advanced.

So before you get lost, take a step back and let's review the fetch API.

As we've seen, fetch() returns a promise.

When the promise resolves, what do we get? 

Answer: we get the Response object. The Response Object contains a lot of useful information like the status code, and headers of the HTTP request.

But if you open this Response object up, and try and look for the body of the response data, you don't see the JSON data we're after.

Weird right? 

Readable Streams are bytes of data.

Pretty useless for us, right? 

So then, how do we go about working with Readable Streams? Can you use the JSON.parse() method that we saw a few sections back? 

As we've seen, the fetch API returns us a Response object.

If we try and access the data / body of the response, we get a Readable Stream.

Luckily for us, the Fetch Standard has created a method that waits for this stream to be fully received, and then it will parse this stream into a JavaScript object - something we can work with.

This method is called the json() method.

Now its time to put our knowledge to the test, and use the json() method to see the results of our AJAX request.

Let's put all of your knowledge to the test and request a joke JSON data object from an external website using the fetch() API.

Have fun.

I want to finish off this section looking at what we've learnt so far.

Specifically, I want you to code up an AJAX call using the XHR object and the newer Fetch API.

I will drag the cart before the horse a little, by showing you what ASYNC and AWAIT are, but please don't worry if you don't fully understand what these keywords do. I have an entire section on this later.

In this lecture lets complete the code for our first button - that is, creating our XHR AJAX request to fetch JSON data.

I want to use the fetch() API to make a AJAX call to a server.

I want to then show you how to work with data received from a server. In this example, lets use the toUpperCase() method given to us by JavaScript to convert our joke string all into upper case.

Let's finish off our section by completing a fetch request to fetch JSON data. I will show you how to use the fetch API with the new async/await keywords.

One of my students asked me to give an example of looping through an array to display results.

If you're anywhere close to my age, you would remember back in the old days, when wanting to watch a video online, you would have to wait until the entire file was downloaded into your computer's memory before you could watch it.

But with the introduction of Streaming, this all changes.

That's why I'm so excited about this section.

Working with streaming data is an advanced concept, but that does not stop me does it? I want to give you a high level understanding on how streams work.

I hope you enjoy this section.

This is a bonus section, in the sense that it really is advanced.

Streams are pretty powerful. The Streams API allows JavaScript to access streams of data received over the network in chunks, and process them as desired by the developer.

Let me be clear - you don't have to know about Streams in order to be a great AJAX developer.

But I want you to become a Grandmaster in AJAX.

And this means you should have a high level understanding on what streams are all about.

Okay, so we know that the fetch API returns a ReadableStream object that can be found on the body property.

You know this.

But the million dollar question is: "How do we extract the bytes from the readable stream and actually read the data in a meaningful way?"

Great question.

In this lecture we will see how you can get a reader (via the getReader() method) and then use the .read() method to actually read the chunks in real time.

Enjoy!

As always, there is more than one way to achieve the same thing when it comes to coding.

In the previous lecture we saw how to read chunks of data once the Promise has been resolved.

But what about if you want to read chunks gradually and convert them to text in real time? 

Lets do this!

If you really want to get advanced, then you need to know that it is possible to write your own custom stream.

I love taking a step back, so in this lecture let me summarize what we've covered in this section.