Modern Frontend

Most frontend books are about a framework. This one is about the browser.

Specifically, it’s about the gap between the browser most of our frontend habits were formed against — slow, inconsistent, capability-poor, hostile to applications — and the browser we actually have now, which is none of those things and hasn’t been for years. Modern frontend development sits on top of that gap without often noticing it, and a great deal of what we currently treat as essential infrastructure was built to work around constraints that have quietly disappeared. This book is an attempt to take that fact seriously, work through what changes once you do, and arrive at a different way of building applications for the web.

The path to get there is historical, then technical, then architectural. We start with how we got here: the long chain of real constraints and real solutions that produced the modern frontend stack. jQuery, Backbone, Angular, React, Next.js, Remix — all serious engineering against the platform of their day, all worth understanding on their own terms before we can honestly ask whether the same answers still fit the platform we have now. From there we move into the modern browser as a platform rather than a render target: HTML treated as an application language, CSS as a runtime, the DOM as a context tree, forms as transactions, accessibility as a contract. These chapters look like they’re about web standards, but they’re really about architecture; the standards are just where the architecture happens to live.

The third part of the book builds on top of that platform. First by hand — a small runtime, a shell, modules, boundaries, a metadata layer, native components — built piece by piece so the moving parts stay visible. Then in maintained form, a framework called Kitsune that takes the same ideas to production scale. Kitsune doesn’t appear until the final third of the book, and that’s deliberate: the point isn’t to sell you on a framework, it’s that by the time the framework arrives, you’ll already have most of the design in your head.

Who the book is for

You don’t need to be a senior engineer to follow this book, and you don’t need to be new to the field to learn from it. If your only frontend experience has been React and the meta-frameworks built around it, the early chapters will give you the vocabulary for why the stack you’ve inherited looks the way it does, and the later ones will offer a different way to think about what could come next. If you’ve been writing for the web across several eras, the goal isn’t to walk you through the history again — it’s to use the history to set up an architecture argument you may not have heard framed in quite this way. And if you mostly work in backend or native systems and the frontend has always felt like a foreign country, you may find the book unexpectedly familiar; the browser turns out to share far more with the systems you already know — boundaries, transactions, capabilities, supervisors, runtimes — than the modern frontend stack tends to advertise.

On the exercises

Most chapters end with an exercise, and they aren’t decorative. The arguments in this book are easier to make than they are to feel, and the exercises are how the arguments become real in your hands. You can read the book straight through and walk away with the shape of the ideas; if you do the exercises, you’ll walk away with the architecture itself. The code we build in the middle of the book is small on purpose — a few hundred lines, not a starter kit — because the whole point is to make the moving parts legible, not to replace your production framework. Keeping it small is the point.

A last note on vocabulary. Words like boundary, runtime, capability, protocol surface, and context tree show up in the early chapters and keep their meaning all the way through. Each gets defined on first use, then earns its weight as the book goes on. By the closing chapters they aren’t jargon — they’re the load-bearing pieces of a way of building applications that takes the modern browser at its word.