Opening a page and pressing a button can both change what appears on screen, but they need not involve the same work. Opening a page may ask a server for a document. A button may change an existing document entirely inside the browser. A second button may ask the server for more data and then update only part of that document. Understanding these differences makes it possible to explain a web application before choosing a framework.
We will follow a small reading-list page through its initial load and a local interaction. The aim is to identify the resource being requested, the program responsible for each change, and the lifetime of the resulting state.
1. A web application has cooperating parts
Definition
Client, server and resource
A client initiates a request for a service. In our examples, the browser acts as the client. A server accepts requests and produces responses. A resource is something identified by a URL, such as an HTML document, an image, a stylesheet or a collection of data.
Client and server describe roles. They do not require two particular kinds of physical computer. A laptop can run a browser and a local web-server process at the same time. The browser still requests resources; the server process still handles those requests.
A server also need not send a file already present on disk. It can construct a response by running a program. For example, a reading-list service might select available books and generate HTML, or return a JSON representation that browser JavaScript uses to update a list. In both cases there is a request, a response and a representation of a resource.
The word web describes the communication and document environment. The Internet is the underlying network infrastructure; HTTP is one application protocol using that infrastructure. A web application can also operate on a private network or through a local server on the same machine.
2. Read a URL as a structured address
Consider this illustrative address:
https://reading.example.test/shelf/books?topic=web#practice
| Part | Value | Role |
|---|---|---|
| Scheme | https | Selects HTTPS, HTTP carried over an encrypted connection. |
| Host | reading.example.test | Identifies the server name. |
| Path | /shelf/books | Identifies a resource within that server's URL space. |
| Query | topic=web | Supplies additional request parameters. |
| Fragment | practice | Identifies a part of the returned resource for client-side navigation. |
For an ordinary HTTP request, the fragment is not sent to the server. The browser can use it after obtaining the document, for example to scroll to an element whose id is practice. A path can be handled by an application route; it does not prove that a matching file exists on the server's disk.
The scheme also determines a default port: HTTPS normally uses 443 and HTTP normally uses 80. An explicit port, such as http://localhost:8080/, selects another port. localhost refers to the machine on which the browser is running; it is useful when a server is running there for development.
Worked example
Resolve related resources
Suppose the current document URL is https://reading.example.test/shelf/index.html and it has no base element.
theme.cssresolves to/shelf/theme.csson the same host./assets/book.svgresolves from the root of that host to/assets/book.svg.../about.htmlresolves to/about.html.#practicekeeps the document location and selects itspracticefragment.
The leading slash changes where path resolution begins. Moving an HTML file into another directory can therefore change relative links while root-relative links keep their path within the same host.
Checkpoint
Which part reaches the server?
Compare /shelf/books?topic=html#examples and /shelf/books?topic=css#examples. Which part lets the server distinguish the requests? Would changing only #examples to #exercises send that new fragment to the server?
Solution · Compare query and fragment
The queries differ: topic=html and topic=css. The server can use those query values when preparing its response. A fragment is not part of the HTTP request target. Changing only the fragment of the same document normally performs navigation within that document, without requesting a new document from the server.
3. Follow one document request
Entering an HTTPS address starts several tasks. The browser identifies the host, obtains its network address as needed and establishes a connection. HTTP then provides the request/response conversation. Some work can be reused from earlier visits or caches, so this is a conceptual trace rather than a promise that every visit repeats every step.
Browser Server
| |
|--- request the /shelf/index.html resource ->|
| | choose or generate content
|<-- status, headers and HTML body -----------|
| |
| parse HTML |
|--- request a referenced stylesheet -------->|
|<-- stylesheet response ---------------------|
| build the displayed page |
A request includes a method, a target and headers; some methods also carry a body. A response includes a status, headers and usually a body. The following is a simplified HTTP/1.1-style illustration:
Worked example
Read one HTML request and its response
Suppose the browser requests /shelf/index.html from reading.example.test, and the server returns the document successfully without a redirect. Read the request first, then determine what the browser can learn from the response.
GET /shelf/index.html HTTP/1.1
Host: reading.example.test
Accept: text/html
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
<!doctype html>
<html lang="en">
<head><title>Reading shelf</title></head>
<body><h1>Reading shelf</h1></body>
</html>
The blank line separates headers from the body. Content-Type identifies the representation's media type, so the recipient can interpret the body appropriately. HTTP/2 and HTTP/3 encode messages differently, but retain methods, statuses, headers and response data as concepts.
GET identifies the retrieval operation, the path identifies the requested resource, and Host identifies the server name. The response's 200 reports success, while its content type tells the browser to interpret the body as UTF-8 HTML. Parsing that body gives a page headed “Reading shelf”. The request describes what was asked for; the response supplies the outcome and representation.
An HTML document can refer to CSS, JavaScript, fonts and images. The page visible to the reader is assembled from those resources, not necessarily from one response. Requests can overlap, and cached resources can be reused. Conversely, one failed image request does not imply that the HTML request failed.
| Status | What it tells us | Useful next observation |
|---|---|---|
200 | The request succeeded. | Inspect the content type and returned content. |
404 | The requested resource was not found. | Check the exact path, spelling and relative-link resolution. |
500 | The server encountered an error handling the request. | Inspect the server-side failure when working on that server. |
These statuses report different outcomes. Changing a CSS color does not repair an incorrect resource path; fixing a path does not repair a server program that fails while generating a response.
4. Separate structure, presentation and behavior
HTML, CSS and JavaScript cooperate, but they answer different questions.
| Technology | Main responsibility | Reading-list example |
|---|---|---|
| HTML | Gives content its structure and meaning. | A heading, a list of books and a button. |
| CSS | Controls presentation and layout. | Spacing, colors, a readable line length and responsive columns. |
| JavaScript | Runs program logic and responds to events. | Count button presses or update a list after receiving data. |
HTML is a markup language: its elements describe a document. CSS supplies presentation rules. JavaScript executes instructions and can change the browser's document representation, the Document Object Model (DOM). A framework still operates within this environment; learning the underlying roles helps explain what the framework produces.
The browser runs client-side JavaScript. A server may also run JavaScript, for example with Node.js, but that is a different execution environment. A server script cannot change an already displayed page merely by changing one of its own variables. It must communicate a result that the browser can use, through a response or another supported communication mechanism.
5. A complete local interaction
Worked example
Trace a counter across clicks and reloads
Save the following standalone document as reading-counter.html and open it in a browser. Its count lives in the current document's JavaScript state. The button does not make a network request.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Reading counter</title>
<style>
body { max-width: 38rem; margin: 2rem auto; padding: 0 1rem; }
button { font: inherit; padding: 0.5rem 1rem; }
</style>
</head>
<body>
<main>
<h1>Reading counter</h1>
<p>Pages recorded: <output id="count" aria-live="polite">0</output></p>
<button id="record" type="button">Record one page</button>
</main>
<script>
let count = 0;
const display = document.querySelector("#count");
const button = document.querySelector("#record");
button.addEventListener("click", () => {
count = count + 1;
display.textContent = String(count);
});
</script>
</body>
</html>
The elements precede the script, so they exist when querySelector runs. The selectors #count and #record match the corresponding IDs. The handler is registered once and runs when a click occurs. textContent changes the output's text; it does not add HTML markup.
Let be the count after clicks. The initial condition is , and each click applies
The output is a view of that state. The program first changes count, then updates the displayed text. If the second instruction were removed, the variable would still change but the reader would continue seeing the old value.
| Action | JavaScript state | Output text | Server request caused by the handler |
|---|---|---|---|
| Initial document | count = 0 | 0 | None |
| First click | count = 1 | 1 | None |
| Second click | count = 2 | 2 | None |
| Reload the document | count = 0 again | 0 | The handler itself still sends none. |
Reloading creates a new document and reruns its initialization. A browser may read the file again or load a server-hosted copy, depending on how it was opened. In either case, this program does not save the previous count. Keeping a value across reloads requires a persistence mechanism; sharing it across devices requires an appropriate shared service and communication.
Common mistake
A changing screen does not prove a server was contacted
The visible output can change because a browser handler changed the DOM. That observation alone does not show that data was sent or saved. Identify the code path or inspect the network activity before concluding that a server participated.
Checkpoint
Predict the counter before trying it
Click three times, reload, and click once. What value is shown at each stage? What changes if display.textContent = String(count) is removed?
Solution · Trace initialization and updates
Three clicks show 3. Reload initializes a fresh count to 0 and the document displays 0. One further click shows 1. Without the textContent assignment, the in-memory count changes on clicks but the displayed text stays 0. The model value and its visible representation are separate objects that the program must keep consistent.
6. Diagnose by observing the responsible layer
Browser developer tools let you test the explanation rather than infer everything from appearance.
- In the document inspector, find the output element. Click the button and observe its text node change.
- In the Network panel, inspect the initial document request when the page is hosted by a local server. Compare its response with the referenced resource requests.
- Clear the network log, then press the counter button. The supplied handler causes no request.
- Reload and compare the original response or file contents with the live DOM. A script can change the DOM after the original source has been loaded.
When a page looks wrong, ask a precise question: was the resource obtained, was the document structured correctly, did a style rule apply, or did a handler update the intended state and element? Each question points toward different evidence.
Exercises
1. Locate the work
For each action, identify the main responsible layer: HTML, CSS, browser JavaScript, or a server program. Explain your choice.
- A book title is marked as a heading.
- Two columns become one on a narrow screen.
- A click increments the local reading counter.
- A service returns only books matching a query parameter.
Solution · Solution 1: Responsibilities
- HTML marks the content's role with a heading element.
- CSS describes how the layout responds to available space.
- Browser JavaScript handles the event, updates a variable and changes the DOM.
- A server program interprets the requested query and prepares the matching representation. Browser JavaScript may display its result, but it does not perform the server's selection merely by receiving it.
2. Count resources under explicit assumptions
A document refers to one stylesheet, one script and two distinct images. Assume an empty cache, no redirects, no additional resources referenced by those files, and a successful request for each resource. How many resource requests are needed, including the document? Does that imply they must all run one after another?
Solution · Solution 2: Count requests without assuming timing
There are requests: the document and four referenced resources. The count does not establish their timing. Once the browser discovers dependencies, it can request some resources concurrently; it need not finish each request before starting the next one.
3. Explain a reload
A learner presses the counter button five times, closes the tab and opens the same page again. They expect 5 but see 0. Is the click handler necessarily broken? State what evidence in the program explains the result.
Solution · Solution 3: Lifetime of state
The handler can be correct. let count = 0 initializes state for each new document, and there is no storage or server communication in the handler. Closing the document ends that instance's state. A new load starts another instance at zero. Correct local updates and persistent storage are different requirements.
4. Resolve a changed directory
An HTML file moves from /shelf/index.html to /courses/web/index.html. Without a base element, compare where theme.css and /assets/book.svg resolve before and after the move.
Solution · Solution 4: Relative and root-relative paths
theme.css changes from /shelf/theme.css to /courses/web/theme.css, because it is relative to the document's directory. /assets/book.svg remains that path on the same host, because its leading slash resolves from the host root. Moving the document does not automatically move either resource.
Continue with semantic HTML documents to make the structure and meaning of a page explicit.