What Actually Happens When You Click a Link - Part 3

In Part 1, your browser sent a request. In Part 2, the server received it, matched it to the right code, queried the database, and ran your logic. Now the server has its answer ready. It needs to send it back.

What the Server Sends Back

The server can send back a few different things, but the most common is an HTML file. This file contains the structure and content of the webpage: the headings, paragraphs, images, links, everything the page is made of. Along with the HTML, the server often sends CSS files (which style the page) and JavaScript files (which add interactivity). It might also send images, fonts, or other resources the page needs to display correctly.

There are also cases where the server sends back just data, in a format called JSON. This usually happens when the browser is asking for data to update part of the page without reloading the whole thing, like when you click a button that shows more comments without navigating to a new page. It also happens when another service, like a mobile app, is asking the server for data. But for now, let's focus on the most common case: the server sends back HTML, CSS, and JavaScript.

The Three Ingredients of Every Webpage

Think of a webpage like a house.

HTML is the structure. The walls, the rooms, the doors. It defines where everything goes: headings, paragraphs, images, buttons, links. Without HTML, there's nothing on the page. It's the skeleton that holds everything together.

CSS is the design. The paint colors, the furniture layout, the lighting. It tells the browser how things should look, what colors to use, how big the text should be, how much space goes between elements, and how the layout adapts depending on whether you're on a phone or a laptop. Same house, different interior design.

JavaScript is the electricity. It makes things work. With JavaScript, you can click buttons that do things, fill out forms that validate your input, and see parts of the page update without reloading. It can also talk back to the server to fetch new data or send information, like when a chat message appears in real time without you refreshing the page.

The server sends all three because they work together. HTML provides the structure, CSS makes it look good, and JavaScript makes it interactive. Take one away and the experience breaks down. A house with no walls, no paint, or no electricity isn't much of a house.

How the Server Tells You What Happened

Along with the response itself, the server sends back a status code, a short number that tells the browser how things went. You don't need to memorize these, but knowing the categories helps.

200 means "here you go." Everything worked. The server found what you asked for and is sending it back. This is what happens most of the time, and you never notice it because things just work.

404 means "I can't find that." The URL doesn't match anything the server knows about. You've seen this one. Every "Page Not Found" error you've ever hit is a 404. The server looked, but there was nothing there.

500 means "something broke on my end." The server tried to process your request, but something went wrong in the code. This is a server-side problem, not yours. When you see one of these as a developer, it means something in your code needs fixing.

The Browser Takes Over

Once the response arrives, the server's job is done. Now it's the browser's turn.

The browser reads the HTML and builds an internal structure of the page, a kind of map of every element and how they're nested inside each other. Then it reads the CSS and applies the styles: colors, sizes, spacing, layout. Then it runs the JavaScript to wire up all the interactive behavior.

The browser also notices if the HTML or CSS references additional resources, like images or fonts, and fetches those too. Each one is its own mini request-response cycle, happening in the background.

Once all of that is done, you see the fully rendered page on your screen. The whole process takes a fraction of a second. You just see a page appear. But under the hood, the browser just assembled an entire house from a set of blueprints, paint samples, and wiring diagrams.

Here's the important distinction. The server sends the ingredients, the browser assembles the meal. The server is responsible for the backend work, processing the request, running logic, querying data, and packaging up the response. The browser is responsible for the frontend work, taking that response and turning it into something visual you can interact with.

The Full Cycle, Start to Finish

Let's walk through the whole thing one more time with a concrete example.

You're logged into an app and you click a link that says "Dashboard."

Your browser sends a request to the server: "Give me the dashboard page." That request includes your login cookie so the server knows who you are.

The server receives the request. It checks its routing: /dashboard matches the dashboard code. It runs that code, which checks that you're logged in and queries the database for your specific data, your stats, your recent activity, whatever the dashboard shows.

The server takes all of that, builds an HTML page with CSS and JavaScript, and sends it back with a 200 status code. Everything worked.

Your browser receives the response. It reads the HTML, applies the CSS, runs the JavaScript, fetches any images, and renders the page.

You see your dashboard. The whole thing took less than a second. Done.

You Already Knew This

Here's the thing. You've been doing this every single time you use Claude.

You type a prompt. That's a request. It travels to a server. The server processes it, runs its logic, and sends back a response. Your screen displays the result.

The web works the exact same way. The only difference is that now, you're going to build the thing on the other end. Not the browser. Not the internet. The server, the logic, the responses. That's your app.

What This Means for What You're About to Build

This is the mental model that Claude Code assumes you have. And now you have it.

When you tell Claude Code "add a route that returns a dashboard," you're describing this exact cycle. You're saying: "when someone sends a request to /dashboard, run this code, get this data, and send back this page." Every feature you build, every page, every form, every button, follows this same pattern. Request comes in, your code runs, response goes out.

You don't need to memorize every detail. You just need to know the shape of the cycle. And now you do, not because you studied computer science, but because you've been living it every time you use AI.

Every web app on earth follows this cycle. Next, we'll zoom into the map and figure out which parts are "frontend" and which are "backend." But the cycle itself? You've got that.