What Is Asynchronous Javascript

The first time this really clicked for me was standing at a fast food counter, watching the cashier stare at the grill, waiting on one burger, while six people fumed in line behind me.

JavaScript runs into that same problem constantly, and it solves it by handing you a buzzer instead of making you stand there.

Blocking the Line

Most of the code you write runs the way that frozen cashier does. Line one finishes, then line two starts, then line three, in the exact order you wrote them. That's called synchronous code, and most of the time it's exactly what you want.

Run this and the alert box does to your page exactly what that frozen cashier does to the line. Nothing responds, not a scroll, not a click, until someone dismisses it.

Only then does 'Order handed over' print. Each line waited for the one above it, and the alert happened to be a line that takes a while to finish because a human has to act on it first.

Now imagine every slow order at that counter worked like this. A request that takes five seconds would freeze the entire line, and everyone behind it, for five seconds straight.

That is the exact problem asynchronous code exists to solve.

Getting a Buzzer Instead

Here's the same counter, but this time you get handed a buzzer instead of being told to wait.

Read that top to bottom and you'd guess the buzzer message prints third. It doesn't.

Hit Run on the editor above and watch the real order: everything prints immediately except the buzzer message, which lands three seconds later. setTimeout starts the kitchen working on its own and hands you a buzzer, a function to run once that work is done, but it never makes you stand there for it.

You sit down immediately. That's the whole trick: non-blocking. The kitchen keeps working on your one order while you go do something else, and the buzzer interrupts you later, whenever the food is actually ready. That function you handed to setTimeout, the one that only fires once the buzzer goes off, has a name: a callback. Edit the delay above or add your own console.log lines and run it again to see the order shift.

ExpandTwo timelines side by side: synchronous code where an alert blocks every following line, versus asynchronous code where a setTimeout timer runs elsewhere while the rest of the script keeps executing immediately.

That's really the whole definition. Asynchronous just means the kitchen keeps cooking without you standing at the counter for it. Something starts now, gets worked on elsewhere, and only reaches you later, through that callback.

A Buzzer Alone Doesn't Make It Async

Here's where I got tripped up. setTimeout hands you a callback. So does the array filter method, when you use it to check a menu for anything under fifty dollars.

Flipping through a menu for anything under fifty dollars isn't something you need a buzzer for. You do it yourself, instantly, at the table. filter runs its callback the moment you call it, top to bottom, right now.

But nothing about this code is asynchronous, even though it uses a callback in the exact same sense setTimeout does.

Only a specific handful of things actually hand you a buzzer instead of doing the work on the spot: timers, network requests, hardware and location lookups, and loading files or media. Everything else, no matter how much it resembles those, just does the work immediately.

Take asking the browser where the user actually is. That takes a moment, the device has to go check with GPS or the network, the same way a host has to walk off and check on your table instead of just knowing offhand.

'Checking on your table...' prints first, immediately. The coordinates print later, once the device has actually worked out where it is. The callback passed to getCurrentPosition isn't what makes this asynchronous. The lookup itself, happening off somewhere else while you wait, is. The callback is just how you find out once it's done.

So don't ask whether something takes a callback, plenty of things do that never leave your hands. Ask whether real work is happening somewhere else while you wait: a timer counting down, a device figuring out where it is, a request crossing the network to another server entirely. If yes, you've been handed a buzzer. If not, no buzzer was ever needed, because nothing was asynchronous to begin with.

Calling the Supplier

The most common reason to write asynchronous code in a real app is this exact situation, aimed at a server instead of a kitchen. That pattern has a name: AJAX.

Picture a currency app that shows today's exchange rate. That number changes by the minute, so the app can't just hardcode it. It has to ask a server for the current rate, after the page has already loaded, the same way a restaurant that's run out of an ingredient mid-shift phones a supplier instead of grinding to a halt.

Your JavaScript, running in the browser (in web terms, the "client"), sends a request out to that server. The server sends a response back with the data, and your page updates without a full reload.

The counter keeps taking other orders the entire time that request is out. Only the callback tied to "the response arrived" runs once the data actually lands. Some requests just ask the supplier what they have, a GET. Others send the supplier something, a POST, which is a topic worth its own post.

What the Supplier's Order Line Actually Is

That server your app is talking to almost always exposes something called an API, short for Application Programming Interface.

Strip the acronym away and an API is just a way for one piece of software to ask another for something, without either one needing to know how the other actually works inside. That covers a lot of ground.

• The DOM is an API. It's the counter's own internal ordering system, how your JavaScript talks to the HTML on the page.
• A class with public methods is an API. It's an ordering system you built yourself, in your own code.
• A weather service running on a remote server is an API too. It's a completely separate business, reachable over the network, that only answers the specific questions its order line supports.

That last kind, living on someone else's server and reachable over the internet, is usually just called "an API" or "a web API" in casual conversation. You could build your own (that's backend development, servers and databases and all), or use ones other people already built and expose for free or for a fee. Weather data, shipping rates, maps, sending a text message, there's a supplier out there for almost everything, and stitching a handful of them together is most of what "building a modern web app" means in practice.

Order Slips: Why Every API Speaks JSON Now

The name AJAX stands for Asynchronous JavaScript And XML, and that X is basically a fossil at this point. Almost nothing uses XML as a data format anymore, the name just stuck around because it got popular before that shift happened.

What replaced it is JSON, and the reason is almost embarrassingly simple: JSON is just a JavaScript object turned into a string. It's an order slip every supplier can read without translating it first, cheap to send across a network and trivial to turn back into a real object once it lands in your code.

Once you have the vocabulary from this post, the next step is placing an actual call to a supplier with fetch and watching a real JSON response come back, which is where this starts feeling like a real app instead of a diagram.

The Essentials

1. Synchronous code makes every line wait for the one before it to finish, the same way a frozen cashier backs up an entire line, until one slow line freezes everything behind it.
2. Asynchronous code hands a task off to happen elsewhere (a timer, a location lookup, a network request) and hands you a buzzer instead of making you wait, so the rest of the script runs immediately.
3. A callback on its own does not mean you were handed a buzzer. filter's callback runs instantly, right where you are; setTimeout's callback only runs once the timer actually buzzes. The same logic rules out plain click listeners waiting for a click, too. What decides it is whether real work is happening somewhere else while you wait.
4. AJAX is the buzzer idea aimed at a server: a request goes out to a supplier you don't control, the counter keeps running, and a callback fires once the response actually arrives.
5. An API is the ordering system one piece of software exposes so another can ask it for something. A "web API" specifically lives on someone else's server, reachable over the internet.
6. JSON replaced XML as the standard order slip format because it's just a JavaScript object turned into a string, cheap to send and instant to read back.