How do web apps work?

Every business runs on web apps. Checking a bank balance, ordering lunch, logging into your CRM: it's the same idea underneath, over and over.

Most executives have never seen what's actually happening when they click a button. That's fine. You don't need to write code to run a company. But the ideas underneath a web app are not complicated, and once you've seen them, a lot of confusing conversations with your dev team get a lot easier to follow.

I'm going to show you the whole loop with things you can edit yourself, right on this page. It takes a few minutes. We'll build up from a plain page to a program that reads and writes a real database.

A browser asked a server for a file. The server sent back some text. The browser drew this. That's the whole loop, before we add anything to it.

Nothing fancy happened there. A file went from a server to a browser, and the browser turned it into something you could read. Now let's look at what that file actually contained.

HTML is plain text with tags around it. A tag says what a piece of text is: a heading, a paragraph, a link. Try changing the tag, the words, or the inline style on the left, and watch the right side update as you type.

That's the same page from the last section, edited live. Scroll back up after you change it and you'll see it changed there too. A web page is just text, and tags are just instructions for how to draw that text.

Typing HTML by hand works for a page that never changes. Most pages need to change, so instead of typing the HTML, we write a program that builds it.

Here, a small program written in Ruby builds the HTML instead of a person typing it. Anything wrapped in #{…} gets filled in the moment the page is built, in this case, the current time. Press Run and watch the timestamp move.

The timestamp only moves when you press Run. That's the real difference between a static file and a program: a static file always says the same thing, but a program rebuilds the page fresh every time someone asks for it. That's what "the server" is doing every time you load a page: running a small program like this one, right now, just for you.

But that program only knew one blog post, hardcoded right into the Ruby. A real site has thousands of posts. It needs somewhere to keep them.

Same idea as an Excel tab: rows and columns. The difference is the rules. Every row has exactly the same columns, in the same order, with the same type of value in each one. No stray notes in a random cell, no merged headers, no second table hiding underneath the first. Click into a cell below and change it.

This is the posts table. Every cell you just edited is live for the rest of this page, the same way a real database keeps whatever the last write left behind. Every user account, every order, every blog post on every site you've ever used is just rows like these, in a table like this one.

Now let's connect the two ideas: a program that writes HTML, and a table that holds the facts.

The address bar says which row you want. Ruby reads that number, pulls the matching row out of the table, and drops its values into the HTML. One template, one row per page, thousands of pages. Change the number at the end of the URL below to 1, 2, or 3, then press Run.

Same code, different row, different page. If you edited the table a few sections back, your edit shows up here too, because it's reading the same table. That's a web app: a program, a database, and a template, wired together so one piece of code can serve every row.

So far, data has moved one direction only: database, then code, then HTML, then browser. A form sends it the other way.

You type into a form and press Save. The browser sends what you typed back to the server, and the server writes it into a row. Nothing changes in the table until you press Save. Try it below.

That's the missing half of the loop. A browser doesn't just receive pages, it can send data back, and a program on the other end decides what to do with it: usually, write it into a row.

Put the last few sections together and you have the shape of nearly every web app in existence. A browser asks for a page. Code builds an HTML page, usually by reading a row out of a database. The browser draws that page. If there's a form on it, the browser can send data back the other way, and the code writes it into the database.

Everything else in a real app (logins, search, payments, permissions) is this same loop, repeated, with more rules attached at each step. Once you can trace a single click through those four moves, most conversations with your engineering team get a lot easier to follow.