Mental models

What a web app actually is

Strip everything away. A web app is one or more files that show up in a browser when someone visits a URL. Those files mostly come from another computer over the internet. The browser knows how to read them and turn them into the thing you see and click.

That's it. Twitter is that. Gmail is that. Stripe's dashboard is that. The differences are in scale and interactivity, not in the basic shape.

Client and server

Every web app involves at least two computers. Yours, and someone else's. Yours is called the client. Theirs is called the server. They have a conversation: you ask for things, the server answers.

The client side is your browser, running on your laptop or phone. It's where the page is rendered, where you click, where animations happen. The server side is a computer somewhere else (in a data center, usually) that holds the data, runs the business logic, and hands files and answers back.

Frontend and backend

Now the words you actually hear engineers say. The frontend is everything the user sees and touches — the visible half, all client-side. The backend is the engine room — APIs, databases, business logic, integrations — all server-side.

"Frontend engineer" and "backend engineer" are job titles. "Full-stack engineer" is one who does both. None of them is a different species; they just live in different parts of the same machine.

The request / response loop

The web is a conversation. Every interaction is a request from the client and a response from the server. You click a link → request. Server thinks → response. Browser renders → done.

A request carries: a URL, a method (GET to read, POST to create, etc.), some headers, and sometimes a body. A response carries: a status code (200 = OK, 404 = not found, 500 = server crashed), some headers, and a body — usually HTML or JSON.

What happens when you type a URL

This is the famous "deep dive" interview question. Here it is in seven steps you can hold in your head:

1. The browser parses the URL

   It splits https://tasklane.com/inbox into a protocol (https), a host (tasklane.com), and a path (/inbox).

2. DNS resolves the host to an IP address

   DNS is the internet's phone book. It turns a name like tasklane.com into a number like 104.21.32.18 — the actual address of a server.

3. The browser opens a secure connection

   An HTTPS handshake — the browser and server agree on encryption keys. This is what the padlock icon means.

4. The browser sends the request

   "GET /inbox" + a bundle of headers (your browser, your language, cookies if any).

5. The server responds with HTML

   Either pre-built or generated on the spot. Either way, what comes back is a chunk of HTML plus a bag of follow-up resources to fetch (CSS, JS, images, fonts).

6. The browser renders the page

   Parses the HTML into a tree, applies the CSS for layout, runs the JavaScript. You see things appear.

7. JavaScript takes over for interactivity

   From here, every click, every input, every scroll might trigger more requests in the background — but the page itself doesn't necessarily reload.

You don't need to memorize this. You need to know the shape so when something breaks at step 4, you have language for what broke.

Static vs. dynamic

Two flavors of how the server hands you HTML:

Static

The HTML files are pre-built and just sit on disk. The server hands them out as-is. Fast, cheap, simple. Good for: blogs, docs, marketing pages, reference sites — anything that doesn't change per user. This very site is static.

Dynamic

The server builds the HTML (or the JSON) for each request, often by talking to a database. Slower, more flexible. Good for: dashboards, social feeds, anything personalized.

Modern frameworks like Next.js blur this — some pages static, some dynamic, in the same app. But the distinction is foundational: does this page change per user, per minute, per anything? If no, it can be static. If yes, it has to be dynamic.

The browser as a runtime

Last mental model. The browser isn't a passive document viewer; it's a full programming environment. It runs JavaScript. It has APIs for storage, networking, audio, video, the camera, the GPU, geolocation, payments. A modern web app is a serious application running inside another application.

This is why people talk about "the platform." When someone says "the platform supports it," they usually mean "all major browsers expose this API." When something doesn't work in Safari, the joke is half-true: Safari is to the web what Internet Explorer used to be — the browser that lags behind on supporting newer features.

Wrap-up