# The Localhost Effect — narration script

Runtime 11:48. Timecodes are when each chapter starts; the film's animation is keyed to these cue times, so a recorded voice-over should keep each line near its timecode.

## 0:00 · A client asks, a server answers

- `0:01` The client-server model is the first pattern you must embrace to build for the web.
- `0:07` The idea is simple. A client asks. A server answers. This transaction is typically conducted over a network.
- `0:18` Let's explore the pattern now, starting with the client.

## 0:23 · Who's asking?

- `0:23` A person uses a device, a laptop, a phone, a tablet, a screen reader, to request a URL over HTTP, usually with a browser like Chrome.
- `0:37` Sometimes the browser hides inside a mobile app, as a webview. Sometimes there's no person at all, just a script.
- `0:46` With so many combinations of hardware and software, we call whatever makes the request the user-agent.
- `0:53` Fun fact: user-agent is a combination of user and agent. From the start, the web expected both people and software agents to make requests.
- `1:06` Bots, crawlers, and agents were early citizens of the web alongside human users and they had conventions for how they should behave such as respecting the robots.txt file on a site.
- `1:22` The conventions of old sadly have been lost to many of today's developers.  Right now, we can easily see both agents do real harm, like hacking attacks or mass content extraction, and do good, helping people get things done efficiently without abusing resources. The split here is not the agents; it's their operators.

## 1:46 · The localhost effect

- `1:47` The user-agent sends its HTTP request across the internet for a public site, or across a local network for an internal, intranet app.
- `1:57` That network, and its conditions, shape everything that follows.
- `2:03` Careful, here comes a classic mistake. We build and test almost entirely on our own machines.
- `2:13` On your own machine, the network disappears. Bandwidth is nearly infinite, latency is nearly zero, and the device behaves exactly as you expect.
- `2:27` Thinking your laptop and load conditions are the real world is dubbed the localhost effect.  Always guard against the tempting illusion the localhost effect presents.  Its world is an ideal world that hides much of the web's variability and hostility.
- `2:45` Remember the law: you are not the user. Your device isn't their device, and your network isn't their network.

## 2:55 · The server answers

- `2:55` Eventually the request reaches a host running a web server, such as Apache or Nginx. It speaks HTTP too, and it tries to fulfill the request.
- `3:09` Sometimes that means returning a file named by the URL: the web of documents.
- `3:16` Sometimes it means running a program and returning the result: the web of applications.
- `3:23` Real systems blur the line, but a request is generally either fetching an asset or running code.
- `3:31` Fun fact: the industry calls some hosting approach serverless. That technically makes no sense. There is always a server.
- `3:40` The term likely comes from platforms that hide the server so you can just upload a cloud function. Hiding the presence of a server doesn't make it go away, and it breeds misunderstanding.  Even worse, the convenience of not thinking about a server can also mean you give up some control, which is one of the benefits of the client-server model.
- `4:06` Finally, to complete the pattern, the response travels back, and the client uses it, often by showing an HTML page. URL, HTTP, and HTML: the three core web technologies, together in one conversation.

## 4:24 · Latency

- `4:24` Now back to the network, because it shapes the entire conversation.
- `4:30` If the user is far away, a request takes a long time to go and come back. If the network is congested, by an outage or a rush of viral traffic, it takes longer still.
- `4:44` That delay between cause and effect is latency. Gamers know it as lag, the thing we blame for our losses instead of our gameplay.
- `4:56` We measure latency in milliseconds, and we want it low and steady.
- `5:02` Fun fact: the internet and its protocols were built to route around trouble. If one path fails, packets find another. What they can't route around is distance.  Lag, so to speak, may be intrinsic and by design!
- `5:19` Some latency is physics, and no next version will fix it. Reach a server in California from Antarctica by satellite, and web apps can become unusable. Our film Engineering for the Extreme? tells that story.
- `5:36` Other latency comes from congestion, simply more traffic than capacity. Fixing that runs into economics, where profit often wins.
- `5:47` We're watching systems get worse even as technology improves, because the market lets worse cost more. There's a popular word for that: enshittification.

## 5:59 · Bandwidth

- `5:59` Bandwidth is the rate at which data moves.
- `6:03` Picture pipes. Water through a garden hose is constrained. A bigger pipe moves far more each second. A sewer main moves a torrent.
- `6:15` Networks are the same. We count bits per second: 10 Mbps, or, if you're lucky, 10 Gbps.
- `6:25` For most of the web, though, latency is the tighter limit. Unless you're sending large media like video, you don't need much bandwidth.
- `6:36` Sadly, developers waste bytes, turning a non-problem into a problem.
- `6:42` Fun fact: the median web page keeps growing, yet pages don't do much more than they used to. The bloat comes mostly from JavaScript frameworks and unoptimized media.  You can verify this fact by looking at the data collected in the HTTP Archive, which has broadly studied web characteristics for well over 10 years.   The failure to respect the web medium is sadly less of a negative opinion and more an observed fact if you bother to look or consider things from the user's perspective.
- `7:19` To help you tame resource abuse, consider measuring your page in floppy disks, about a megabyte each. Whole applications, even games, once fit on one. Your web page shouldn't come close.

## 7:35 · The Performance Law

- `7:35` So there's delivery time in theory, and delivery time in practice.
- `7:41` We influence it by how we build: how many bytes, and how they're organized. But the actual time depends on the user and the network.
- `7:52` The network, and as we'll see, the client, are simply not under our control. A perfect solution is impossible here.
- `8:02` Engineering, web or otherwise, accepts solutions within tolerances, not perfection.
- `8:10` To keep that in mind, the Professor offers a golden rule, his Performance Law: send less data, less often, from nearby, and only when needed.
- `8:23` Less data: minimize what you send, and compress what you must.
- `8:30` Less often: reuse what you've already sent, through caching or installed assets.
- `8:37` From nearby: respect latency. Work on the device, local-first, or use a content delivery network to shorten the trip.
- `8:47` Only when needed: don't fetch bytes too early, like aggressive pre-caching, or too late, when the user notices the wait.
- `8:58` So instead of uploading code and hoping, we accept the network, optimize for it, and measure. Google's RAIL model is our goal, and our film A Budget for Patience shows how to use it.

## 9:14 · Client side, server side

- `9:14` The client side has the same control problem as the network, and worse.
- `9:20` As we saw with user diversity, we can't count on the device, the display, the processor, or the connection, let alone the person's abilities and expectations.
- `9:35` You can't guarantee what happens there, and you can't truly secure what you send there. Yet that's where our content and apps must go, because it's the only place we get real responsiveness.
- `9:49` The client side: nearly impossible to control, but it's relatively quite fast.
- `9:55` The server side is the inverse. You run it, so you can control it and, hopefully, secure it. You pay for this control with speed, because every answer crosses the network.
- `10:09` On a fast, controlled network, you might build a thin client: the client only displays, and the server does everything. Today's internet doesn't let us assume that network.
- `10:23` Flip it, and you get a fat client, with most of the logic in client code, as in many single-page apps. Given how varied devices and situations are, that's often brittle. It may work for you, but make sure to measure whether it works for your users.
- `10:43` Extremes of client or server only suit the cases where security or performance outweighs everything else. Most systems are hybrids.
- `10:55` Choose the balance for your software and its users, not for the fashion of the moment.
- `11:01` Many web failures come from rebuilding the browser, or the web itself, instead of working with the medium.  The course will encourage you to often employ the design philosophy called Progressive enhancement to help mitigate many problems.

## 11:19 · Tread carefully

- `11:19` So: a client asks, a network carries, a server answers, and much of it is outside your control.
- `11:30` Beware the localhost effect. Respect latency and bandwidth. Follow the Performance Law.
- `11:37` And tread carefully with architecture until you understand your users and your problem.