DevelopmentSubsection
Frontend
The code that runs in somebody else’s browser, on hardware you did not choose, over a network you cannot rely on. Five topics: the platform itself, the language it runs, and the three frameworks that solved the same problem — keeping a screen in step with data — in three genuinely different ways. Each framework page is about its update model rather than its syntax, because that is what you actually have to reason about when something renders twice.
What is inside
Every page in this group, with what each one covers.
- HTML & CSSThe cascade, specificity and the box model — the three things that explain almost every layout that will not behave.CascadeLayout
- JavaScriptOne thread, an event loop and a queue: why nothing blocks, and why "asynchronous" is not the same as "parallel".Event loopSingle thread
- ReactRender and commit as two separate phases, and why almost every React bug is a misunderstanding of which one you are in.Render / commitHooks
- VueReactivity that tracks dependencies for you: what is actually observed, and what silently is not.ReactivityProxies
- AngularChange detection from zones to signals, with OnPush now the default — the most explicit of the three, and the most predictable once understood.Change detectionDI
Where to start
- Starting frontendHTML and CSS, then JavaScript. Every framework here assumes both, and the event loop explains more bugs than any of them.
- Choosing a frameworkRead all three update models rather than the feature lists — that difference is what you live with daily.
- Something renders twiceYour framework’s page, specifically its update phase diagram. Double renders are almost always a phase misunderstanding.
Elsewhere in the section
- DevelopmentSoftware development is the work of deciding where the boundaries in a system go, what runs on each side of them, and what moving one of those boundaries will cost once the code is live. This section covers 30 topics — architecture, the browser, seven backend languages, four mobile platforms, language models and the databases underneath all of it. Every page turns on the constraint that actually separates the options, rather than on the API surface.
- MobileFive ways to put software on a phone, each defined by the hard limit its platform imposes rather than by its API surface. Battery, memory pressure, a lifecycle that can kill your process at any moment, and a store that decides when your fix ships. Those constraints are what differ between the five, and they are what should decide the choice — the language rarely does.
- ArchitectureWhere to put the boundaries, and what each boundary costs. Four topics: the two shapes a system can take, the migration between them that most teams attempt at the wrong moment, and the contract that makes any boundary usable by somebody else. The recurring theme is that a boundary is not free — it buys independence and charges you in latency, debugging and operational surface.
Found this useful?
Share it with someone who is working on the same problem.