Courses / Course 08 · Web · opening stages, more coming
Build a web browser, then a UI framework
You end up withA web browser in a couple of thousand lines of Python that downloads pages over HTTP, parses HTML and CSS, lays out and draws text, follows links, submits forms and runs JavaScript; and a React-like UI library with function components, a fiber-based reconciler and hooks, set against a reactive alternative built on JavaScript proxies.
Data pulled 2026-11-08 · time estimates are editorial
Why build a browser when three companies already do? Because every web page you write runs inside one, and most front-end bugs live in the gap between what you wrote and what the browser did with it: the layout that shifts, the re-render that freezes the page. After this track, parse, style, layout and paint are code you’ve written, and a UI framework is a short program you can read.
This course is an opener. Its first two stages are published. More stages come next; see Coming next at the end.
How to read the receipts.
Points are summed across every HN submission of the same URL. For books and series on one site (Web Browser Engineering, Matt Brubeck’s series), that includes chapters submitted on their own.
“Submitted N×” means HN rediscovered it N times.
Quotes come from the highest-ranked top-level comments in those threads, and a quote is sometimes a criticism. Quotes keep the commenter’s spelling.
Steps are ordered for learning, not by points.
Times are our estimates, not the authors’. They assume evenings and weekends, and a reader who writes Python and JavaScript comfortably.
The classic long tour of a browser’s insides: the networking layer, HTML and CSS parsing (including how browsers recover from broken HTML), the render tree, layout, painting and the event loop. It reads as a map of Stage 1.
“This looks like an excellent place to link someone who knows a bit of HTML, maybe some Javascript, but is curious about “real CS stuff”.”
HN’s caveat is its age, and the page now says so itself: “This document was initially published in 2011. As such, much of this content is no longer accurate.” A newer, shorter alternative is the interactive How Browsers Work guide (302 points, 2026). “Neat, it’s like an exciting way to dive into https://browser.engineering without having anything to install.” (utopiah, 2026 · comment)
1,514 points across 32 submissions of its chapters (2020–2026) · Free online; print edition from Oxford University Press · Python · ~6–9 weeks
A basic but complete web browser in a couple of thousand lines of Python, one chapter at a time: download a page over HTTP, draw text to a window, wrap lines, build an HTML tree from imperfect markup, lay out blocks and inline text, apply CSS, handle links and the browser’s own UI, submit forms to a small web server you also write, run JavaScript that changes the DOM, and handle cookies, XSS and CSRF. Part 4 goes on to compositing, the event loop and rendering pipeline, GPU animation, accessibility, iframes and invalidation. For an opener, Parts 1–3 (chapters 1–10) are the target; Part 4 is a stage of its own.
“One great thing about this book is the ‘stuff I didn’t do’ part.”
Alternative in Rust: Matt Brubeck’s Let’s build a browser engine! (488 points across 14 submissions) builds the rendering half only, in seven parts: HTML, CSS, style, boxes, block layout and painting. “It is a bummer it ended with a to be continued that never happened, I remember checking up on it from time to time.” (codezero, 2018 · comment)
Rewrite React from scratch, following the architecture of the real code without its optimizations, in eight steps: createElement, render, concurrent mode, fibers, separate render and commit phases, reconciliation, function components and the useState hook. The code scrolls alongside the text, and the whole thing is one page.
“That is a fantastic presentation. It reminds me of the annotated source/site that backbonejs used to have, but this one is interactive.”
HN’s caveat is the format, not the content. “The animations don’t keep up when you scroll the page quickly and it really makes the whole thing a pain to glance through.” (Etheryte, 2025 · comment). Read it slowly, and type the code out rather than copying it.
Alternative: Rob Pruzan’s Implementing React from Scratch (177 points) goes further into hooks: useRef, useEffect, useMemo, useCallback and useContext, without following React’s internal architecture. The author’s reason for writing it: “Quickly realized I didn’t understand everything React was doing to allow their API.” (robpruzan, 2024 · comment)
Now argue with what you built. The Svelte author’s essay shows the work a virtual DOM does on every update that a compiler or a fine-grained reactive system can skip.
“Virtual DOM diffs do a huge amount of unneeded work because in the vast majority of cases a renderer does not need to morph between two arbitrary DOM trees, it needs to update a DOM tree according to a predefined structure, and the developer has already described this structure in their template code!”
Then build the other side:Building a Frontend Framework; Reactivity and Composability With Zero Dependencies (171 points) builds reactivity on JavaScript Proxy objects, with no virtual DOM, no dependencies and no build step. Its author turned it into a framework called Strawberry. Expect pushback on the terms: “Imperatively applying mutations to an application state inside a proxy object setter is, in fact, proactive and not reactive.” (gloosx, 2023 · comment)
Coming next
Candidates for the next stages, receipts pulled but not yet reviewed or written:
The browser at scale. Web Browser Engineering Part 4 (compositing, threads, invalidation); Lin Clark’s Inside a super fast CSS engine on Firefox’s Stylo (722 points); MDN’s Populating the page: how browsers work (280 points).
The server side. Bogdan Popa’s Web application from scratch series (381 points).
Editorial backlog
Checked against HN on 2026-11-08 (candidates_receipts.json), not used:
Kosmonaut (725 points): a browser engine in Rust. A project to read, not a tutorial.
Method
Candidates came from the 148 web-tagged stories in the 4,140-story pull, plus a web topic pull with 27 terms: 239 candidates in all (phase1-stories/data/web_candidates.json). Browser-industry news (engine bans, Chromium, Ladybird funding) and CSS frameworks made up much of the noise and were skipped by hand.
Selection. 13 resources had receipts pulled; 9 are used here, chosen by hand for followability and sequence. Points were then totalled across every submission of each URL.
Quotes come from the top five top-level comments of the two best-scoring threads per resource, in HN’s ranked order via the Firebase API. Links go to the full comment. Every ID and quote is checked with phase1-stories/scripts/check_track.py.
Content and costs were checked on 2026-11-08 on each resource’s own page: Web Browser Engineering’s table of contents and print edition, Build your own React’s eight steps, the web.dev notice on How Browsers Work, the parts of Matt Brubeck’s series, and the Proxy-based design of the Strawberry post. Time estimates are editorial, not measured.
Data:tracks/web/receipts.json (resources used) and candidates_receipts.json (all 13 checked).