Static vs. dynamic

Confused about what people mean when they talk about "static" websites vs. "dynamic" websites? Let's try this:

A static website is a vending machine.

A dynamic website is a restaurant.

1. How you get your food (the pageview)

When you look at a URL, like http://www.nytimes.com/meals/dinner.html, you are sending a request out into the ether:

"Hey, nytimes.com, send me back the content located at /meals/dinner.html"

Somewhere there is an actual computer that takes in that request and sends back some content (or an error message, if there's a problem with the request). This is what people talk about when they talk about web servers: computers that wait for requests and then serve you what you ask for.

A server might be a plain old computer like the one on your desk, or it might be a rented computer in a giant data center that looks like something from WarGames. It doesn't really matter.

2. The vending machine (static sites)

When people talk about a static server, they are talking about a server set up like a vending machine. When you ask for a URL, like http://www.nytimes.com/cheetos.html, there is an actual file already on that computer called cheetos.html, and all it has to do is send you a copy of that file. Talking about "flat files" refers to the same thing: having actual files that match the URLs people might request.

You punch E6, you get the Cheetos that are already in the machine, packaged, ready to eat.

Like a vending machine, a static server can be:

Simple - There's only one thing you can do with a vending machine. A static server has to find the file you asked for, and send back a copy. It doesn't have to do anything else. As a result, it's pretty robust. There aren't a lot of things that can go wrong. No kitchen fires, no flaky employees. Static servers rarely break.
Fast - The file's already made. You get your order right away. Static servers are very fast. Fewer long spinning wheels waiting for content to be rendered and databases to do databasey things.
Cheap - Servers cost money. For both static and dynamic servers, the cost is pretty low these days unless you're the New York Times. But serving files statically is especially cheap, thanks to services like Amazon S3. You can serve a million pageviews for pocket change.
Harder to restock - Let's say the Cheetos are tainted, and you need to replace them. This is a pain in the ass, because you have to go around to all these vending machines and restock the Cheetos. Similarly, if something changes on your elections site, making that change can be more complex and/or time-consuming on a static site, especially if it affects lots of different files. You have to replace them all. In a restaurant, if there's a problem with your tomatoes, you get some new tomatoes in the kitchen and you're good. You only have to fix the problem in one central place.
Impersonal - A vending machine has no idea who you are. It gives everyone the same food. If you want to serve people different content based on user input, this can be harder to do on a static site. In a restaurant, you can adjust each preparation for that customer because it's made-to-order. Hold the mayo, medium rare, whatever you want. You can still personalize things on a static server, but it's more challenging.

3. The restaurant (dynamic sites)

When people talk about a dynamic server, they are talking about a server set up like a restaurant. The food is made-to-order. The kitchen has ingredients, and the cooks assemble those ingredients into the finished product only AFTER someone orders that dish.

In this version, if you ask for a URL, like http://www.nytimes.com/crabcakes.html, crabcakes.html doesn't exist yet. There is no such file. It's just a menu item. The server waits for your request, and when the request comes in, it uses ingredients (e.g. templates, a database, the Twitter API) and a "recipe" to create that page on the spot, just for you.

When people talk about the "back end" or "server side," they are talking about the kitchen: the stuff that a server does when it gets a new request.

Like a restaurant, a dynamic server can be:

More personalized - Because content is being created dynamically, in response to requests, you have an opportunity to craft each one for that user. It's easier to send each person content specific to them: their location, their user account, their form input.
Easier to change the menu - When you need to change something that affects lots of web content, it can be easier to do this on a dynamic server. You typically only have to make the change in a central place, like your database or your template. If your site is static, you need a way to update every affected file, which is certainly possible but requires a more elaborate process and, if enough files are involved, a significant amount of time.
More expensive - Dynamic servers aren't that expensive these days (see above, re: cost), thanks to things like Amazon EC2. But they're still significantly more expensive than static hosting for a comparable amount of traffic.
More complex - Restaurant kitchens are frenetic, chaotic places, full of stuff that can break. There are many more ways for dynamic servers to crash or fail insidiously.
Slower - It takes longer to get your dinner when it has to be made on-the-fly. Similarly, it can be slower to serve a piece of content dynamically rather than using a static file. The server has more work to do before it can send it back.
Easier to overwhelm - We've all been at a busy restaurant during the dinner rush, when the kitchen gets overwhelmed and the service slows to a crawl. Dynamic servers are vulnerable to heavy loads, when lots of people are all trying to get content at the same time (think election night, or big sporting events). When you have lots of users all demanding content at the same time, serving content gets slower and slower, until the server crashes entirely. This is how many denial-of-service attacks work. They intentionally make a site too popular, flooding it with requests for content, until it buckles under the sheer volume of simultaneous requests.

4. Prep cooks (a little bit of both)

In the real world, most servers mix these two approaches. A restaurant doesn't wait until you order your fries to buy the potatoes. They have prep cooks organizing, chopping, and staging ingredients ahead of time to minimize how much of the process is dynamic.

When you load an image from a dynamic server, it probably isn't drawing that image for you, farm-to-table, pixel-by-pixel. That image is probably just an actual file that already sits on the server.

Part of managing dynamic servers is about having a good mise en place: figuring out what needs to be prepared at the last minute, and getting the rest ready ahead of time.

Some caveats

Like all analogies, this one is limited. I don't mean to suggest, for example, that content from a static server is stale and low-quality, or that dynamic servers are extravagant things.

There is also the question of caching, which doesn't have a great food prep analog. Dynamic servers can use various kinds of caching to serve pre-cooked content but update it dynamically.

There are not many absolutes. Most things that are easier on dynamic servers, like personalization and updating content in a central place, are possible on a static server. It just tends to be trickier. You have to figure out workarounds to make things seem dynamic, and have systems in place to regenerate your files in bulk when you need to make updates. Similarly, while dynamic servers tend to be more complex and easier to break, it doesn't mean they necessarily are. You can create extremely fast and robust dynamic servers that will stand up to any amount of traffic. It just tends to be trickier. You have to have the sysadmin savvy to use the right tools and employ the right strategies.