Asynchronous JavaScript — Part 6

In part 5, we looked at how Chrome’s V8 engine executes code. We used Chrome’s debugging tools to trace JavaScript’s execution order. Debugging tools tools are exceptionally powerful ways to reason about asynchronous code and will make you more productive. In this part, we will use our knowledge to solve real world asynchronous problems, such as pulling data from servers.

Pulling Data from Servers

Let’s begin by solving a real world problem using asynchronous JavaScript.

One problem that many developers face is pulling data from a server. Let’s use an extreme example to illustrate a major problem with using synchronous JavaScript to get data.

Imagine you are using your all-singing, all-dancing web-app from within the country Yemen. Yemen has an average internet speed of less than 1mbps according to my superficial critical analysis. Now, further imagine that your web-app needs to download a relatively small data-set of approximately 30MB. Plugging these numbers into an online calculator, it would take 240 seconds for that relatively small data-set to download. Figure 1.

Figure 1 — Download time for slow internet.

This is the Achilles heel of synchronous JavaScript. The user has no option but to wait 240 seconds before doing anything else. The web-app is completely blocking and non interactive during the download. This is a common example of an awful user experience and should be avoided at all costs!

240 seconds seems like an extreme example, but many usability studies show that mere seconds without an interactive experience causes users to go elsewhere. Remember, every second is critical to the success of your application. Time is not just about performance — time is also critical for a great user experience.

Remember — make your apps responsive. Do not frustrate your users and never make them wait!

Think about this. How many times have you got frustrated with those apps that freeze while the page renders? I would imagine such experiences are deeply engrained into your lives at this point, given the sheer number of blocking sites that continue to plague the internet with awful user experiences.

Unfortunately, these blocking sites are the norm rather than the exception. To reduce the likelihood of producing a blocking site, we can make use of the Fetch web-api.

Asynchronously Fetching Data with the Fetch API

The fetch api fetches resources from the web. When a HTTP client such as a web-browser makes a HTTP request — the target of that request is known as a “resource”.

We get or modify resources on the web using a URI or uniform resource identifier. This URI, which you will typically see as the address in your web browser, identifies logical or physical resources.

Let’s look at fetch in action. We will use fetch to fetch posts from a remote server that is setup to respond to HTTP requests.

Open up Chrome and type about:blank into the address bar to get a minimal html page. Figure 2. Copy the code from Figure 2 into the console of the developer tools and hit enter.

Figure 2 — a basic get request using fetch

fetch() will then make a request to http://jsonplaceholder.typicode.com/posts which returns a promise. If the request completes, the promise is fulfilled with the Response object. If the request fails the promise is rejected. In this instance, we can see that the promise was fulfilled and returned an array of objects representing unique posts. Figure 3.

Figure 3 — Asynchronously fetching data using the fetch api

If you open up the network tab from within the developer tools you can gather rich information about the request and response objects. Figure 4.

Figure 4 — Accessing the HTTP information from a GET request.

Congratulations. You have made your first asynchronous request for a resource on the internet.