CSE 134B

A “for Programmers” series

The Browser for Programmers

You have written HTML, styled it with CSS, scripted it with JavaScript. This series is about the program that runs all of it. Not how to use the browser — how the browser works, told the way a computer scientist would want to hear it: as a system with subsystems, processes, a scheduler, a memory model, an I/O layer, and a security boundary around untrusted code.

The thesis

A browser is usually introduced as a thing that turns a URL into a picture. That is true, and it is the least interesting thing about it. The fetch-to-screen story treats the browser as a pipe. It is not a pipe. It is an operating system — arguably the operating system most people actually use, sitting on top of the one they think they use.

Hold the analogy up to the light and it stops being an analogy. An operating system schedules work on a limited number of threads; the browser has an event loop. An OS isolates processes so one program cannot read another's memory; the browser isolates origins and, since 2018, runs each site in its own sandboxed process. An OS exposes hardware through a syscall interface; the browser exposes the network, the GPU, the camera, the filesystem, and the clipboard through APIs gated by a permission model. An OS runs untrusted programs without letting them take over the machine; that is the browser's entire job, executed billions of times a day on code it downloaded from strangers a few milliseconds ago.

The browser is the operating system of the web. Every other web technology is a program running on it.

That framing is the spine of the whole series. It is what turns a list of pipeline stages into a mental model you can reason with — the difference between memorizing that “CSS is render-blocking” and understanding which scheduler made that decision and why.

Who this is for

CS students and working programmers who already know the three authoring languages and want the platform underneath them. It assumes you are comfortable with the ideas in The Web for Programmers (client–server, DNS, HTTP, the developer–user gap) and the HTML and CSS for Programmers series. Where those series taught you to author for the platform, this one dissects the runtime that consumes what you author.

The running example: Demo Company

Abstraction is where browser explanations go to die. So the series is anchored to one deliberately small site — democompany.com — a set of pages each engineered to add exactly one new thing to the conversation and to print its own list of HTTP requests on the page. You can open the network panel and watch every claim in these modules happen in real time.

The pages fall into two arcs, and the series follows both:

The cast comes along

The Web for Programmers introduced a cast — the people and programs on the other end of every request: the blind user, the distant user on a thin connection, the privacy-conscious user, the aging user, the indexing bot, the taking bot, the abusing bot, the autonomous agent, the abusing human. They return here because the browser is where the abstract claim “your users are diverse” becomes concrete engineering. Every cast member is, in effect, running a different machine: a different render engine, a different process budget, a different network, a different threat posture. Site Isolation protects the privacy-conscious user; the event loop's frame budget is what the aging user on old hardware feels; the security model is the only thing standing between everyone and the abusing human.

The nine modules

The arc mirrors the structure of a browser itself: load it, view it, run it, then everything modern bolted on top.

Loading
  1. 01The browser as operating system

    The thesis in full. The component architecture — UI shell, browser engine, render engine, networking, JS engine, storage — mapped onto OS subsystems. Multiprocess design and Site Isolation as real memory protection between untrusted programs.

  2. 02From URL to first byte

    What happens between pressing Enter and the first packet of HTML arriving: URL parsing, scheme dispatch, DNS, the connection, TLS, the request and response. The browser as I/O manager. Demo Company's minimal request set.

Viewing
  1. 03Parsing HTML into the DOM

    Lexer and parser theory, why HTML is not a context-free grammar, why browsers ship a custom error-tolerant parser, and how a byte stream becomes the DOM — the tree everything downstream reads and mutates.

  2. 04The resource model

    A page is a dependency tree, not a file. The preload scanner, the request waterfall, render-blocking versus async versus deferred, the CSSOM. Demo Company's resource arc, page by page.

  3. 05Style, layout, paint, composite

    The pixel pipeline as it actually runs in 2026: computed style, layout, paint, and the compositor pushing layers to the GPU. Why transform is cheap and width is not.

Running
  1. 06The JavaScript engine and the event loop

    JavaScript as the browser's userland runtime. One thread, two queues, a frame budget. Tasks, microtasks, requestAnimationFrame, and the scheduler that decides when your code runs and when the page gets to paint.

  2. 07The security model

    The same-origin policy as a permission boundary, the sandbox, CORS, cookies, CSP, mixed content. Demo Company's threat arc in full: the tracker, the malicious script, the cross-origin everything.

  3. 08State, storage, and caching

    The browser as a filesystem and a persistence layer: cookies, Web Storage, IndexedDB, the HTTP cache, and the service worker as a programmable proxy. Plus the hardest problem in the building — cache invalidation.

Modern
  1. 09The browser as a platform

    DevTools as the browser observing itself, extensions, the capability and permissions model, PWAs, and the web-versus-native gap. Where the platform is going, and the handoff back to authoring.

How to read it

In order, with Demo Company open in one window and DevTools in another. Each module assumes the previous one. The reward for reading linearly is that the OS metaphor compounds: by Module 6 the event loop is not a new idea but the scheduler you already met in Module 1, now in detail.