Outline

Planning material — won’t ship. This whole /planning/ group is scaffolding for the rewrite. It will be removed before the book is published.

The hook (the major framing — leads the book)

The next decade of interfaces won’t be hand-authored. They’ll be dynamic, personalized, generated by AI on demand, and they’ll have to run anywhere — from a phone to a watch to a TV to whatever comes next. They’ll ride on the operating system underneath the web — the browser engine and its native APIs — because shipping a framework runtime per AI-generated card is untenable.

Modern Frontend is a book about that operating system: how it became one underneath us while the industry was busy building abstraction layers on top, why those layers feel like magic until you look under the hood, and how to build software that takes the platform seriously again — for today’s products and for the AI-generated interfaces of the next decade. Kitsune is the maintained example of the architecture that falls out.

The book is also a love letter to the internet, and a transmission of the contextual depth that lets developers wield AI with judgment instead of being confined to docs-following.

This hook leads. It opens the introduction. It’s the reason the book exists now. The historical chapters earn their keep by giving the reader the contextual depth they need to see the opportunities the future opens up — not as nostalgia, but as preparation.

The book as an invitation

Underneath the hook and underneath the architecture argument, the book carries a third commitment: it’s an invitation to invention.

Frontend has always been a field of invention. Every generation of the platform — Berners-Lee at CERN, Andreessen and Mosaic, Eich’s ten-day language, the IE6 era’s hard lessons, the Ajax breakthrough, jQuery’s compatibility miracle, the structure libraries’ search for discipline, MVC frameworks, React, the meta-framework era, the platform’s quiet resurgence — was shaped by people who were often the absolute best at what they did, doing world-class engineering at the edge of what was possible. They unlocked enormous value for the economy and for humanity. They’re the masters this book honors.

We’ve now gone through a generation of bootcamps, hobbyists, and (most recently) AI-assisted “vibe coding.” None of these have given the next generation the contextual depth that the previous generation took for granted. And that depth is exactly what makes the next round of invention possible. A developer with depth can use AI to create things that don’t exist yet. A developer without depth can use AI to make more of what already exists.

The closing question the book wants the reader to sit with: are we satisfied that this is it? Is this the last web? Or is there still room for invention and creation in the next decade — invention shaped by AI, by new platform capabilities, by readers like you who have done the work to see the field whole?

The book is an invitation to join that long conversation about invention. Every named figure in the historical chapters is part of the conversation. Kitsune is one entrant in it. The reader, by the end, has the depth to be another.

The reader

A wide span of frontend experience:

• React-only readers get a vocabulary for why the stack they inherited looks the way it does, and a different way to think about what comes next.
• Multi-era frontend veterans get a rephrasing of the history they lived into an architecture argument they may not have heard framed this way.
• Backend or native engineers who avoid the frontend find a familiar set of patterns (boundaries, transactions, capabilities, supervisors) on a platform they didn’t realize they already understood.

The shape

Three movements across seven parts (currently — see proposed new chapters below):

1. History. Why each layer of the modern frontend stack was built, who built it, what it was solving for.
2. The platform we have now. The modern browser as application substrate, treated as architecture rather than reference material.
3. A way to build on it. A small runtime by hand, web-native components, then Kitsune as the maintained implementation.

What Kitsune Is

Kitsune is a frontend application architecture that uses the browser’s own primitives — custom elements, attributes, the DOM tree, native events — to do the work that current frameworks do in parallel realities. A <kit-shell> owns a small runtime. <kit-boundary> elements wrap regions of the page and give them semantic context (surface, feature, entity). UI components expose application intent through metadata attributes (meta-event="token.saved", meta-command="dialog.open") rather than by importing services. Modules install capabilities — analytics, observability, audit, storage, notifications, validation, permissions — into the runtime and observe events or handle commands. The runtime is the connective tissue that lets a button emit a meaningful, context-enriched event without ever importing the systems that care about it.

The architectural pillars (full spec at /Volumes/Lukes/Jeremy/sites/kitsune/specs/01-architecture.md):

• Shell. A custom element (<kit-shell>) that owns the application runtime, root boundary, installed modules, and lifecycle.
• Runtime. A small kernel that coordinates events, commands, modules, providers, boundaries, and diagnostics. Framework-neutral, plain TypeScript.
• Modules. Installable capability units — one for analytics, one for observability, one for audit, one for storage, one for notifications. They observe events (facts) and handle commands (requests).
• Boundaries. Custom elements (<kit-boundary>) that mark semantic context zones in the DOM tree. They turn the DOM into a context graph — a click inside a donation form on a campaign page for campaign abc123 is a meaningful event, not just a click.
• Metadata Boundary. The bridge from rendered UI into the runtime. Listens at boundary roots for meta-* attributes on custom elements, data-meta-* attributes on plain DOM, and composed custom events. Uses event delegation, not per-element listeners.
• Events vs. Commands. Events describe facts (token.saved happened); commands request behavior (please dialog.open). The split keeps causality legible.
• Providers. A token-based service registry for shared services (storage clients, API clients, routers, loggers). No global imports.
• UI components. Lit-built kit-* elements (<kit-button>, <kit-dialog>, <kit-field>, etc.) that prefer native elements internally, preserve keyboard and focus behavior, participate in forms, and expose semantic metadata.
• Theme system. CSS custom properties + cascade layers + design tokens. No CSS-in-JS runtime.
• Framework adapters. React, Vue, Next, Nuxt, TanStack — translate framework lifecycle and routing context into Kitsune runtime context. The core stays portable.

Design answers to the foundational gaps

These are the positions Kitsune takes on the questions every reader will ask. Some are firm; some are still tentative — flagged where so.

State management. Browser storage is the state layer. localStorage for simple key-value, sessionStorage for ephemeral session state, IndexedDB for structured or larger data, OPFS and the Cache API where appropriate. State persists across page loads naturally because the platform provides it. Reactivity comes from storage events, custom event wrappers around storage operations, and Lit’s reactive properties on components that read from storage. There’s no separate state-container layer; the platform’s storage tier is the application memory.

Routing. Routing is a backend concern. URL changes are new server requests; the browser owns navigation. The frontend handles in-page state changes (modals, accordions, filters, optimistic updates) through UI state and storage; full URL navigation goes to the server, which returns a fresh document. This is a deliberate return to the browser’s original navigation model. It sidesteps a huge amount of client-side complexity (router libraries, history-API plumbing, scroll restoration, route-state syncing) and aligns naturally with progressive enhancement: pages render as documents first, with rich behavior layered on. This is one of Kitsune’s most consequential design positions and reshapes several chapters of the book.

Server interactions. Patterns instead of magic abstractions. Native fetch for the network. Repository objects per entity type that know how to load and save (UserRepository.findById, TokenRepository.save). Adapters and mappers between server shapes and client shapes. Validation at the boundary, before commit. Async-loading widgets that own their own loading state. Authentication header decoration applied at a single point. Open question (tentative): does anything like Apollo Client or axios still earn its place, or are they themselves examples of the over-abstracted patterns the book is arguing against — especially given recent supply-chain incidents in both? Lean: the abstractions they provide can usually be replaced by ~100 lines of repository code per app, with a far smaller surface area; the book should engage this honestly without dogmatism.

Templating and composition. HTML is the composition language. Composition happens through native HTML — slots, custom elements, normal markup — and the source of that HTML can be backend rendering, client-side template literals (Lit), or AI generation. All three converge on the same artifact. There’s no Kitsune JSX-equivalent because the platform already has one: HTML. This is also what makes Kitsune work cleanly for AI-generated UIs — the AI generates markup, and the runtime treats it like any other markup.

Cross-chapter narrative threads

These threads run through multiple chapters. Each named beat lives in the chapter list with a marker.

Browser engines and consolidation

Mosaic → Netscape → IE → Firefox (Gecko) → Safari (WebKit) → Chrome (Blink). The consolidation toward Chromium dominance, the worry that a single engine becomes a single arbiter, the WebKit / Apple counterweight, and the recent push (Servo, Ladybird) toward a more diverse engine landscape again. WinterCG and the Interop 20XX initiative as the standards-side answer to fragmentation.

Open source vs. corporate backing

A meta-narrative running through every framework era. Meta and React (and the Facebook brand-anxiety era). Vercel and Next.js. Shopify and Remix. Netlify and Solid. Vue’s path from independent toward a corporate backer. The recurring question: does corporate backing give a project confidence and resources, or does it eventually erode trust?

JavaScript runtimes

Node (Ryan Dahl) → Deno (Ryan Dahl again, struggling) → Bun (Jarred Sumner, winning, then acquired by Anthropic). Where this lives is open — possibly its own short chapter near the end of Part I, possibly threaded.

The library-on-platform dynamic

A pattern that recurs across eras: libraries earn their lasting value when they sit on top of platform primitives developers understand. GSAP and requestAnimationFrame. jQuery and querySelector. The principle is that knowing the primitive is what keeps the library a tool instead of a black box — and in the AI era, that knowledge is what separates developers who can leverage AI with judgment from those who can only ask AI to follow the latest docs.

Mobile, responsive, and adaptive

The mobile inflection (iPhone in 2007 onward) reshaped the web. Responsive design (Ethan Marcotte, 2010) was the first answer. Container queries are the architectural pivot toward adaptive design — components that respond to their container, not the viewport. This wants its own chapter.

JavaScript, ECMAScript, and the long road to a standardized language

JavaScript started as a ten-day prototype (Brendan Eich, Netscape, 1995) and became, through the TC39 process at Ecma International, one of the most rigorously standardized languages in widespread use. The arc matters: the early scripting language → ECMAScript 3 → the long ES4 standoff → ES5 (2009) → ES6/ES2015 as the inflection point → the annual release cadence (ES2016+). TypeScript (Anders Hejlsberg + Microsoft, 2012) layered structural typing on top and quietly became the default authoring language for serious frontend codebases. The story matters because it’s the platform’s own language growing up — and because TC39’s discipline is what made it possible for browsers to converge on a serious shared runtime instead of fragmenting further.

The dependency ecosystem and supply chain risk

npm (Isaac Schlueter, 2010) made JavaScript’s module ecosystem possible and made it dangerous. The “tiny package, massive blast radius” pattern: the left-pad incident (March 2016 — Azer Koçulu unpublished an 11-line package and broke builds across the JavaScript ecosystem); event-stream (2018 — a maintainer handed off a popular package to an attacker who injected a Bitcoin-stealing payload); ua-parser-js and friends (2021); Log4Shell (December 2021 — a Java library, but the canonical example of a single dependency holding the internet hostage); the ongoing churn of nx, lottie-player, and others through 2024-2025. Underneath the incidents is the structural problem: a typical frontend app pulls in a transitive dependency tree of 1,500+ packages maintained by hundreds of individuals, many of them unpaid, many of them holding up critical infrastructure thanklessly. The xkcd “modern digital infrastructure” comic captured it perfectly. This is part of what the back-to-basics, platform-first proposal is trying to get away from. The platform has no node_modules. It doesn’t break when a maintainer rage-quits. The smaller the dependency surface the more resilient the system, and the more shippable into stochastic AI-generated UI contexts where every additional dep is an additional security audit.

The evergreen platform vs. the churning framework

A specific dimension of the “back to basics” case that doesn’t get enough attention. The browser is committed, by design and by spec, to backward compatibility. A <form> written in 1995 still works in 2026. An XMLHttpRequest from 2008 still works. Custom elements from 2018 still work. HTML, CSS, and JavaScript are extended through TC39 / W3C / WHATWG with serious backward-compat guarantees — when a feature ships in the platform, it stays.

The framework ecosystem doesn’t make that promise. jQuery 1.x → 2.x → 3.x had breaking changes. Angular 1 → Angular 2 was a complete rewrite that fractured the community. React class components → hooks required migrating every component in every codebase. CSS-in-JS solutions rose and fell within five years. The CommonJS → ESM transition is still ongoing years in. Build tools (Grunt → Gulp → Webpack → Vite) churn through generations and leave their config syntax behind. Most npm packages from 2010 are dead, deprecated, or unmaintained; many of them are still buried in transitive dependency trees somewhere, throwing security-audit alerts no one knows how to resolve.

This is the maintenance argument for the platform-first approach: code written against the platform tends to keep working without intervention. Code written against frameworks tends to need rewriting every few years to keep up with the framework’s own evolution. The total cost of ownership of frontend code over a five- or ten-year horizon is dominated by this churn, and most teams don’t account for it explicitly because it has been the default for so long.

For AI-generated UIs the argument sharpens further. Stochastically generated interfaces shipped today need to keep working tomorrow without anyone going back to fix them. The platform makes that promise. Most JavaScript frameworks don’t.

Ergonomics, taste, and the right kind of abstraction

The most honest pushback against a platform-first approach is about ergonomics. Custom elements without a layer on top are verbose. The DOM API has accumulated decades of inconsistencies. Native form validation feels less polished than the third-party libraries that wrap it. Defining a reactive component without help requires more boilerplate than a JSX snippet. These are real complaints from people who care about the craft, and the book has to engage with them seriously rather than dismissing them as resistance to change.

The book’s position has four parts:

1. Some ergonomics complaints are about taste, not capability. Taste matters, but it’s also negotiable when other tradeoffs change. A developer who finds raw custom elements unpleasant may find Lit perfectly comfortable; another may prefer the reactivity model in Solid layered on top of the same primitives. The platform doesn’t dictate one ergonomic answer.

2. The AI inflection changes the ergonomics calculus. When the AI is writing the boilerplate, “ergonomic for the human typing it” matters less than it used to. What matters more: predictability (so the AI generates correct code), consistency (so the AI’s output integrates with what’s already there), type safety (so the AI’s mistakes are caught early), debuggability (so the human reviewing can understand what was done). Several of these are properties the platform provides natively where JavaScript frameworks have to bolt them on. The “ergonomics” the next decade rewards may not be the ergonomics that the last decade did.

3. The right kind of abstraction decorates the API with an opinion. A library that wraps a native form element with better defaults, sensible validation, and easy composition — but that produces a real <form> you can still target through the standard DOM API — is decorating the platform. A library that replaces the form element with a parallel reality the framework owns is replacing the platform. Lit (Justin Fagnani, Steve Orvell, and team at Google) is the canonical example of decoration done well: a Lit element is still a custom element, with the standard lifecycle, the standard DOM, the standard event model. Most of the React ecosystem is the opposite: a <button> rendered by React isn’t really a button you can target from outside React; the framework owns it. Decoration adds; replacement substitutes. Both produce ergonomics, but the cost profile is very different.

4. The choice is about altitude, not all-or-nothing. The honest framing is do you want to work at a higher level of abstraction, or directly at the application interface? Both have tradeoffs. Higher altitude buys ergonomics and consistency at the cost of a parallel reality you don’t own and that you’re locked into. Lower altitude buys longevity, transparency, and platform leverage at the cost of more boilerplate and more design decisions you have to make yourself. The book’s argument is that the lower-altitude tradeoff has gotten dramatically better as the platform has caught up — and that the right kind of decorating abstractions can give you most of the ergonomic wins without the lock-in. Kitsune is positioned exactly in that space.

This thread runs through the framework chapters (where it engages the ergonomics objection generously), the Lit / web components chapters (where it shows decoration done well), and the Kitsune chapters (which are themselves designed as decoration, not replacement).

The web as native application platform

The strongest existing evidence for the book’s central thesis. Electron (originated as Atom Shell at GitHub, 2013) bundled Chromium and Node into a desktop app shell and quietly became the substrate of most modern desktop software: VSCode, Slack, Discord, Notion, Figma (in significant part), Postman, 1Password, Cursor, the desktop ChatGPT and Claude apps. Tauri offers a lighter alternative built on the system webview and a Rust core. On mobile, PWAs and Capacitor / Cordova reach for the same idea — the browser engine as the application runtime, not just a render target inside one. The implication for the book: the argument that the browser is a real application platform isn’t aspirational — the entire industry has already bet on it with their distribution models. The frontend didn’t lose to native; it quietly became native.

The AI inflection and the future of UIs

The book’s most forward-looking thread. Hinted at early (probably in the introduction) as the hook that says why now, then carried through, and culminating in a dedicated section near the end. Two related claims:

1. Contextual depth is the new superpower. Knowing what each layer of the stack was solving for, and what the platform itself actually offers, is what separates developers who can leverage AI with judgment from developers who can only ask AI to follow the latest framework docs. The book is partly an attempt to transmit that contextual depth to readers who didn’t live the history.

2. Chat is transitional. AI-generated UIs are the next frontier. AI tools won’t stay confined to chat interfaces — even where they do, the chat surface itself is starting to embed richer UI components. Beyond chat is the dynamically generated, personalized interface: an application surface composed by an AI per user, per task, per device, per context. Building those interfaces will ship — out of necessity — on browser-native primitives, or on foundations built directly atop them, because no one will tolerate shipping a 200kb framework runtime to render a single AI-generated card. The current ecosystem was largely built to solve past problems: page-based apps, predictable component trees, hand-authored UIs. The future has different shapes, and the platform is what bears their weight.

Hard sub-problems the dedicated section has to engage with:

• Security and reliability when an AI is generating UI on demand.
• The stochastic messiness of AI producing UIs that have to actually work.
• Cross-device, cross-context portability — interfaces that may need to run on a phone, a tablet, a desktop, a TV, a watch, an in-car display, or whatever comes next.
• Trust and governance — what does it mean for a user to use an AI-generated interface that wasn’t reviewed by anyone?

This is exactly the problem Kitsune is built to address: how do you build the future when the current ecosystem was built to solve past problems? The book’s structural argument — history first, then platform, then architecture — earns its keep here. The reader spends the bulk of the book seeing how each layer was assembled and why; by the time they reach this section, they have the contextual depth to see the opportunities, not just the constraints.

Named figures — first-pass placement

A working list. Will grow as we identify more.

Figure / event	Where it lives	Why it matters
Tim Berners-Lee at CERN	Ch 1	The original document model
Marc Andreessen + Mosaic / Netscape	Browser engines chapter, or Ch 6 (Ajax)	First commercial browser; start of the browser wars
Brendan Eich	Ch 4 (JavaScript) and JS-standardization chapter	JavaScript in 10 days; later co-founder of Mozilla and chair of TC39 work
TC39 / Ecma International	JS-standardization chapter	The committee that turned JS into a real standardized language
Anders Hejlsberg + Microsoft	JS-standardization chapter	TypeScript (2012) — the type layer that became default
Isaac Schlueter	npm / supply-chain chapter	Created npm; key in early Node.js ecosystem
Azer Koçulu	npm / supply-chain chapter	The left-pad incident (March 2016) — the canonical npm fragility moment
Log4Shell (Dec 2021, CVE-2021-44228)	npm / supply-chain chapter as parallel cautionary tale	The “tiny library, internet-scale blast radius” pattern at its most extreme
Macromedia / Flash, Silverlight, Apple killing Flash	Ch 5 (existing)	The plugin era and what closed it
The IE6 era	Ch 7 (jQuery)	Why jQuery had to exist
John Resig	Ch 7 (jQuery)	jQuery’s author
Jordan Walke + early React team	Ch 10 (React)	React’s creation and the controversy
Evan You	Ch 10 or 10	Vue, the independent path
Ryan Carniato	Ch 10 or new section	Marko, Solid, fine-grained reactivity
Tanner Linsley	Ch 11	TanStack ecosystem
Kent C. Dodds + Michael Jackson + Ryan Florence	Ch 11	Remix’s positioning
Ryan Dahl	Runtimes chapter	Node, then Deno
Jarred Sumner	Runtimes chapter	Bun
Ethan Marcotte	Mobile / responsive chapter	Coined “responsive web design”
Brad Frost	Design systems chapter	Atomic design
Shadcn / shadcn-ui paradigm	Design systems chapter	Component-copying as a distribution model
WinterCG / Interop 20XX	Browser engines chapter	Standards convergence
GitHub Atom team (Cheng Zhao et al.)	Electron / web-as-native chapter	Electron originated as Atom Shell, 2013
Erich Gamma + the VSCode team at Microsoft	Electron / web-as-native chapter	The killer app that made Electron credible for serious developer tools
Tauri team	Electron / web-as-native chapter	The lightweight Rust + system-webview alternative
Justin Fagnani + Steve Orvell + Lit team at Google	Ergonomics chapter; web components chapters	Lit as the canonical example of “decoration” rather than “replacement” — a Lit element is still a real custom element
Rich Harris	Ergonomics chapter, also Ch 10/10	Svelte’s compile-time approach as a different answer to ergonomics — moves abstraction cost to build time, ships less runtime

Chapter map (proposed comprehensive structure)

The full proposed shape of the book. ~73 chapters across 8 parts. Each chapter has a status (existing draft, rewritten, NEW, restructured), a one-line description, and notes on what it carries (threads, figures) and what it needs.

This map supersedes the earlier “Proposed new chapters” and “Status of existing chapters” tables. Chapter numbering here matches the repo file numbering as of 2026-05-13 — the planning numbers and the chapter file numbers now line up. Total: 75 chapters across 8 parts.

Part I — How We Got Here

The full historical arc, told as a chain of real problems and real solutions, with the human story (figures, controversies, eras) woven through. Each chapter takes one layer of the modern frontend stack and works through what it was solving for, who built it, and what changed once it became default.

1 — The Web Was a Document System [rewritten v2, full chapter]
The browser as document platform; URLs, links, forms, and navigation as the original application model. Sets up the central “browser-owns-navigation” thesis the book builds on. Carries: Tim Berners-Lee at CERN, Andreessen + Bina on Mosaic; foundational for the routing-belongs-to-the-server position later.

2 — CSS and the Separation of Presentation [rewritten v3, trimmed to the foundational architectural argument]
The CSS origin story (Lie + Bos at CERN), the cascade as architectural commitment, structure-first authoring, the CSS Zen Garden moment as visceral proof. Bridges to Ch 4 for the ecosystem story and to Ch 20 (CSS Is a Runtime in Part II) for the runtime treatment. Carries: Håkon Wium Lie + Bert Bos; Dave Shea (CSS Zen Garden); the long arc of the CSS Working Group; decoration-vs-replacement principle established as the framing for evaluating ecosystem tools.

3 — The Stylesheet Ecosystem [NEW — drafted 2026-05-13] The story of how the industry made CSS workable at scale: the preprocessor era (Sass, Less, PostCSS, methodologies — Catlin, Weizenbaum, Sellier, Sullivan, Snook, Roberts, Maddern), the CSS-in-JS generation (Glamor, Aphrodite, styled-components, Emotion, Linaria, Vanilla Extract, Stitches — Stoiber, Maddern, Hohenberger, Hamilton, Dalgleish, Pai), and Tailwind’s utility-first approach (Wathan). What survives, what’s been absorbed by the platform, what’s solving disappeared problems. Carries: the preprocessor and CSS-in-JS arcs, the React Server Components inflection in 2022, decoration-vs-replacement applied to styling, Wathan’s independent path as counter-example to corporate sponsorship.

4 — JavaScript Adds Behavior [existing draft — needs voice rewrite + expansion]
The 10-day language. The JavaScript / Java naming politics (Sun, Netscape, Microsoft). Early DOM scripting before frameworks. Carries: Brendan Eich; the early scripting culture.

5 — JavaScript Standardized: ECMAScript, TC39, TypeScript [NEW]
The language growing up. ECMAScript 3 → the long ES4 standoff and abandonment → ES5 (2009) → ES6/ES2015 as the inflection point → the annual release cadence (ES2016+). TypeScript (Anders Hejlsberg + Microsoft, 2012) layering structural typing on top and quietly becoming the default authoring language for serious frontend codebases. The TC39 process at Ecma International as one of the most successful standards efforts in computing. Carries: TC39, Hejlsberg, Eich (TC39 chair work, Mozilla co-founding); the JS-standardization thread; foundational for everything that follows.

6 — Browser Wars: From Mosaic to a Chromium Monoculture (and Back?) [NEW]
The engine story. Mosaic (NCSA, 1993) → Netscape Navigator → Internet Explorer’s commercial dominance and the IE6 era as a parable of monoculture → Firefox / Gecko’s renaissance → Safari / WebKit (Apple’s KHTML fork) → Chrome / Blink (Google’s WebKit fork). The current Chromium dominance and the worry of a single arbiter. WebKit / Apple as counterweight. The recent push toward diversity again — Servo, Ladybird. WinterCG and the Interop 20XX initiative as the standards-side answer to fragmentation. Carries: Andreessen, the Microsoft / Netscape browser war, Eich (Mozilla), Lars Bak (V8); the browser-engines thread.

7 — Applets, Flash, and the Dream of Native Software [existing draft — needs voice rewrite + expansion]
The plugin era. Java applets, Flash, Silverlight as ways to deliver “real” software inside the browser. Apple’s decision to kill Flash on iOS and what it meant. Carries: Macromedia and the Flash team; Steve Jobs and the Thoughts on Flash letter; the death of plugins as the moment the platform had to step up.

8 — Ajax and the End of the White Page [existing draft — needs voice rewrite + expansion]
The shift from “the page is the unit” to “parts of the page can update.” Gmail and Maps as the cultural moment. XMLHttpRequest as the wedge. Carries: Jesse James Garrett (coined “Ajax”); the Google Maps story.

9 — jQuery and the Compatibility Era [existing draft — needs voice rewrite + expansion]
Why jQuery existed at all: the late-2000s browser landscape was genuinely incompatible. The ergonomics jQuery introduced. The slow obsolescence as the platform absorbed its patterns (querySelector, etc.). Carries: John Resig; jQuery as the canonical library-on-platform that earned its keep, then made itself unnecessary.

10 — Prototype, MooTools, Dojo, and the Search for Structure [existing draft — needs voice rewrite + expansion]
The first attempts to bring application discipline to JavaScript. Carries: Sam Stephenson (Prototype), the MooTools team, Alex Russell (Dojo); the search-for-structure thread.

11 — MVC Comes to the Browser [existing draft — needs voice rewrite + expansion]
Backbone, Knockout, Angular 1, Ember as serious application frameworks. Their differing models (observable properties, two-way binding, declarative templates). Angular 1 → 2 as the canonical “framework breaking change” parable. Carries: Jeremy Ashkenas (Backbone), Misko Hevery (Angular), Yehuda Katz and Tom Dale (Ember); evergreen-platform-vs-churning-framework thread starts here; open-source-vs-corporate thread starts here too.

12 — The Mobile Web and the Move from Responsive to Adaptive [NEW]
The 2007 iPhone and what it did to web design. Responsive design (Ethan Marcotte, 2010) as the first answer. The viewport meta tag, media queries, the “mobile first” movement. Container queries as the architectural pivot to adaptive design — components that respond to their container, not the viewport. The implication: components are now first-class units of layout context. Carries: Marcotte, Jeremy Keith (progressive enhancement), the Smashing Magazine community.

13 — React and the UI as a Function of State [existing draft — needs voice rewrite + expansion]
React’s controversial 2013 debut and what it actually changed. JSX as a deliberate provocation. The virtual DOM and what it bought us (and what it cost). Class components → hooks as a mid-stream pivot that required rewriting every component in every codebase. The decoration-vs-replacement framing applied honestly: React is the canonical replacement abstraction. Carries: Jordan Walke and the early React team; the controversy at JSConf US 2013; Meta and the open-source-vs-corporate thread.

14 — Vue, Solid, Svelte, and the Reactivity Counter-Argument [NEW]
The frameworks that pushed back on React. Vue (Evan You) as the independent answer prioritizing approachability. Solid (Ryan Carniato) and Svelte (Rich Harris) as the fine-grained reactivity counter-thesis — different costs, different ergonomics, different runtime profiles. Carries: Evan You, Carniato, Harris; reactivity as a design dimension; decoration-vs-replacement applied across the spectrum.

15 — The Meta-Framework Era [existing draft — needs voice rewrite + expansion]
Why SPAs got too expensive and what came back to fix them. Next.js, Remix, Astro, Nuxt, SvelteKit, SolidStart. Server rendering returning, routing returning, data loading returning, deployment discipline returning. Carries: Vercel and Next.js, Shopify and Remix, the open-source-vs-corporate thread; sets up the routing-belongs-to-the-server argument that lands in Part II.

16 — The JavaScript Runtimes Era: Node, Deno, Bun [NEW]
The runtime story underneath everything. Node (Ryan Dahl, 2009) as the standard. Deno (Dahl again, 2018) as the rework that struggled. Bun (Jarred Sumner) as the speed-race winner, then acquired by Anthropic. What each argued and what survived. Carries: Dahl, Sumner; the runtimes thread.

17 — npm, Dependency Hell, and the Supply Chain Problem [NEW]
The mess we’re trying to get away from. npm’s rise (Isaac Schlueter, 2010) and the ecosystem it enabled. The canonical incidents: left-pad (Azer Koçulu, March 2016), event-stream (2018), ua-parser-js and friends (2021), Log4Shell as the parallel cautionary tale (December 2021), the steady drumbeat through 2024-2025. The structural problem: transitive dependency trees of 1,500+ packages maintained by individuals, many of them unpaid, many holding up critical infrastructure thanklessly. This chapter is part of the case for the back-to-basics, platform-first proposal — the platform has no node_modules. Carries: Schlueter, Koçulu; the supply-chain thread; the xkcd “modern digital infrastructure” comic moment.

18 — Electron and the Web as Native Application Platform [NEW]
The reveal chapter. Electron (originated as Atom Shell at GitHub, Cheng Zhao et al., 2013) bundled Chromium and Node into a desktop app shell and quietly became the substrate of most modern desktop software: VSCode, Slack, Discord, Notion, Figma, Postman, 1Password, Cursor, the desktop ChatGPT and Claude apps. Tauri as the lighter Rust + system-webview alternative. PWAs and Capacitor on mobile. The argument: the browser already became the de facto native application platform — the industry voted with their distribution models. Carries: Cheng Zhao, the GitHub Atom team; Erich Gamma + the VSCode team at Microsoft; the Tauri team; the web-as-native thread; the GitHub → Microsoft → Electron + VSCode ownership note.

19 — The Browser Caught Up While We Were Abstracting It [existing draft — needs major voice rewrite + expansion]
The hinge chapter. Walks through what the platform shipped between 2015 and now (modules, fetch, custom elements, observers, History API, FormData, ElementInternals, dialog, popover, custom properties, cascade layers, container queries, :has(), view transitions, service workers, storage tier). The chapter the entire Part II argument is built on. Closes with the “React, Apollo, GSAP, Next.js are incredible feats of engineering built on top of the operating system the browser engine provides” moment as the bridge into Part II.

Part II — The Browser We Have Now

Each chapter takes one architectural concept and shows it as a real platform feature. The chapters look like they’re about web standards, but they’re really about architecture; the standards are just where the architecture lives.

20 — HTML Is an Application Language [existing draft — needs voice rewrite + expansion]
HTML as semantic interface to the platform. Why semantics carry behavior. The accessibility tree as a real consequence of markup choices.

21 — The DOM Is a Context Tree [existing draft — needs voice rewrite + expansion]
The DOM as a hierarchical context graph, not a render artifact. Tree traversal as inheritance. Custom elements as node types. Foreshadows Kitsune’s <kit-boundary> model.

22 — Attributes Are a Protocol Surface [existing draft — needs voice rewrite + expansion]
Attributes as a declarative API surface. Data attributes, ARIA attributes, custom-element observed attributes. The platform’s pattern of attribute-as-protocol. Foreshadows Kitsune’s meta-* attribute protocol.

23 — Events Are Not Callbacks [existing draft — needs voice rewrite + expansion]
The DOM event system as a publish-subscribe bus with bubbling, capture, and composition. Composed events crossing shadow boundaries. Event delegation as a real pattern. Foreshadows Kitsune’s metadata boundary.

24 — Forms Are Transactions [existing draft — needs voice rewrite + expansion]
The form element as transaction boundary. FormData, constraint validation, ElementInternals, form-associated custom elements. Carries: the transaction analogy from backend systems.

25 — Browser Storage as Application State [NEW]
The platform’s storage tier — localStorage, sessionStorage, IndexedDB, OPFS, the Cache API, BroadcastChannel for cross-tab — as a real answer to “where does state live?” The storage event for reactivity. Kitsune’s design position: storage is the state layer. Foundational for Kitsune’s state answer.

26 — Routing Belongs to the Server [NEW]
Major architectural chapter. The argument that URL changes should be server requests, not client-side state transitions. The cost of pulling routing into the client (router libraries, history-API plumbing, scroll restoration, route-state syncing). The benefits of returning navigation to the browser (progressive enhancement, real addressability, automatic HTTP caching, no client routing bugs). The line between navigation (server) and in-page state changes (client). Engages the SPA-router assumption every reader brings; ties back to Ch 1’s browser-owns-navigation thesis. This is one of Kitsune’s most consequential architectural positions and gets its formal defense here.

27 — CSS Is a Runtime [existing draft — needs voice rewrite + expansion]
CSS as runtime adaptation system, not styling output. Custom properties as runtime variables, cascade layers as architectural scoping, container queries as component-level reactivity, @scope and modern cascade tools.

28 — Animation, Motion, and the View Transitions API [NEW]
Major design-relevant chapter. Animation as a platform capability, not a library concern. CSS animations and transitions as the foundation. The Web Animations API as the imperative escape hatch. The View Transitions API (Jake Archibald, Bramus Van Damme, the Chrome team, 2023) as the major recent shift — declarative animation between DOM states (document.startViewTransition) and across navigations (@view-transition opt-in). view-transition-name as the CSS property that names elements for the transition. This API is what makes the routing-belongs-to-the-server position ergonomically viable — server-rendered navigation can now feel as smooth as SPA transitions, with the browser doing the heavy lifting. The prefers-reduced-motion media query as motion accessibility. The library-on-platform dynamic applied to motion: GSAP (Jack Doyle), Framer Motion, Motion One — when do they still earn their place over native APIs? Carries: Jake Archibald, Bramus Van Damme, Jack Doyle (GSAP); the platform-caught-up moment for animation; the routing-belongs-to-the-server argument’s final ergonomic answer; foundational for the design dimension as AI-generated UIs become normal.

29 — Accessibility Is the Platform Contract [existing draft — needs major voice rewrite + expansion + human story]
Accessibility as a real architectural concern, not a feature. WAI, WCAG evolution, the accessibility tree, ARIA done right. Where frameworks consistently break the platform’s promises. Carries: the moral dimension of platform-first; figures like Marcy Sutton, Léonie Watson; the W3C WAI’s history.

30 — Internationalization Is the Platform’s Quiet Promise [NEW]
The Intl API surface — the most powerful part of the platform almost no one uses. Locale-aware formatting, plural rules, list formatters, relative time, segmenters. RTL languages as architectural challenge. CJK rendering. Time zones. Same “platform commitment frameworks break” framing as accessibility.

31 — Privacy and the Modern Browser Security Model [NEW]
ITP, Tracking Prevention, third-party cookie deprecation, Privacy Sandbox. CSP, CORS, SRI. WebAuthn / Passkeys. The browser exerting moral and security positions that frontend code has to live with. Carries: the privacy thread; Apple’s WebKit / ITP team; the W3C Privacy CG.

32 — WebAssembly, Workers, and Hardware Access [NEW]
The platform reaching beyond the browser’s traditional scope. WebAssembly as a portable second runtime. Web Workers and SharedArrayBuffer for real threading. WebHID, WebUSB, WebSerial, WebBluetooth, WebMIDI for hardware access. The File System Access API and OPFS. WebRTC for peer-to-peer. WebGL / WebGPU for GPU access. Carries: Lin Clark for WASM; the platform-reaching-into-native-territory thread.

33 — On Ergonomics, Taste, and the Right Kind of Abstraction [NEW — bridge chapter]
Major argumentative chapter. The honest engagement with the ergonomics objection. The four-part response: taste vs. capability; the AI inflection changes the calculus (predictability, consistency, type safety, debuggability matter more than terseness when AI writes the boilerplate); the decoration-vs-replacement principle (named formally here); altitude vs. all-or-nothing. Lit as canonical decoration; React as canonical replacement; Solid, Svelte, Vue, Kitsune mapped on the spectrum. Carries: Justin Fagnani + Steve Orvell + the Lit team; Rich Harris (Svelte’s compile-time approach); the decoration-vs-replacement framing as a named pattern from this chapter onward.

Part III — Starting Over Today

The architectural principles that follow from Part II. We’re not building yet — we’re naming what we’ll build.

34 — What Would We Build If We Started Now [existing draft — needs voice rewrite + expansion]
The thought experiment. Given the platform, what changes? The principles that follow.

35 — From Components to Capabilities [existing draft — needs voice rewrite + expansion]
Why component modularity isn’t enough. Capabilities as the missing layer (analytics, audit, observability, storage, validation, permissions, notifications). Introduces Kitsune’s modules concept.

36 — Boundaries as Application Geography [existing draft — needs voice rewrite + expansion]
Boundaries as bounded contexts (DDD borrowed). Surface, feature, entity. Why the DOM is the right place to mark boundaries. Foreshadows Kitsune’s <kit-boundary>; explicit DDD reference (Eric Evans, the big blue book).

37 — Events, Commands, and Causality [existing draft — needs voice rewrite + expansion]
The CQRS-flavored split. Events are facts; commands are requests. Why the split keeps causality legible. Sets up Kitsune’s events vs. commands.

38 — The Browser-Native Application Loop [existing draft — needs voice rewrite + expansion]
The closed loop: user → component → boundary → runtime → modules → state → UI. The architecture in one diagram. Pulled directly from the closed-loop section of the Kitsune architecture spec.

Part IV — Building the Architecture (by hand)

We build a small runtime from scratch to make the moving parts visible. Not meant to ship — meant to teach.

39 — Building a Tiny Runtime [existing draft — needs voice rewrite + expansion]
The kernel: events, commands, modules, providers, lifecycle. Plain TypeScript, no Lit yet.

40 — Building the Shell [existing draft — needs voice rewrite + expansion]
The application root. Mounting. Lifecycle. What the shell owns and what it doesn’t.

41 — Building Boundaries [existing draft — needs voice rewrite + expansion]
Context attachment, nesting, propagation. Boundary handles. The DOM as context graph.

42 — Building the Metadata Boundary [existing draft — needs voice rewrite + expansion]
Event delegation at the boundary root. Attribute parsing for data-meta-*. Composed event handling for meta:event and meta:command.

43 — Data Patterns: Repositories, Adapters, Validation [NEW]
How a platform-first app talks to a server. Native fetch as the network primitive. Repository objects per entity type (UserRepository.findById, TokenRepository.save). Adapters and mappers between server shapes and client shapes. Validation at the boundary, before commit. Async-loading widgets that own their loading state. Authentication header decoration applied at one point. The honest engagement with Apollo / axios — when does a third-party data layer still earn its place, and when is it itself an example of the over-abstraction the rest of the book is arguing against (especially given recent supply-chain incidents)? Carries: the supply-chain thread; the data-as-architecture argument; sets up the storage chapter (Ch 25) being load-bearing for state.

44 — Building Diagnostics [existing draft — needs voice rewrite + expansion]
Making the runtime visible. The console-stream debug module; later, a real devtools panel design.

Part V — Web-Native Components (built by hand using Lit)

We build the components by hand to make the conventions visible before Kitsune ships maintained versions.

45 — Why Web Components, Why Lit [existing draft — needs voice rewrite + expansion]
Custom elements, shadow DOM, slots, templates as the platform’s component primitives. Lit as the canonical decorating layer — a Lit element is still a real custom element. Carries: Justin Fagnani + Steve Orvell + the Lit team at Google; decoration-vs-replacement applied to component authoring.

46 — Building kit-button [existing draft — needs voice rewrite + expansion]
The simplest case done right. Native <button> underneath, semantic metadata exposed, accessible behavior preserved.

47 — Building kit-dialog [existing draft — needs voice rewrite + expansion]
Native <dialog> underneath. Modal behavior, focus management, the showModal / close API.

48 — Disclosure, Select, and Native Controls [existing draft — needs voice rewrite + expansion]
Native <details> / <summary>, the modern customizable <select>, native popover.

49 — Forms and Form-Associated Components [existing draft — needs voice rewrite + expansion]
ElementInternals, form-associated custom elements, constraint validation participation, accessibility associations.

50 — Styling with Tokens, Cascade, and Containers [existing draft — needs voice rewrite + expansion]
CSS custom properties as theming surface, cascade layers as architectural scoping, container queries as component-level reactivity.

51 — Design Systems and Component Libraries [NEW]
The design-systems industry. Brad Frost and atomic design. Style Dictionary, design tokens (Jina Anne, the W3C Design Tokens CG). Storybook. Shadcn as the component-copying paradigm — a different distribution model. The relationship between design systems and Kitsune. Carries: Brad Frost, Jina Anne, the design-systems community.

Part VI — Kitsune (the maintained framework)

The architecture from Parts III–V, in maintained form. Restructured around the architecture spec rather than the original “introduce + 5 apps” outline.

52 — Introducing Kitsune [existing chapter is a stub — full rewrite]
What Kitsune is in one paragraph. The closed-loop overview from the architecture spec. A complete small app showing every architectural piece working together in ~30 lines of HTML. Should leave the reader feeling: “I see how this works.”

53 — The Shell and the Runtime [NEW]
<kit-shell> as application root. createKitShell as the programmatic API. Runtime lifecycle: install, start, stop. What the shell owns, what it delegates.

54 — Modules and Providers [NEW]
defineKitModule for capability units. createProviderToken for shared services. When to use a module (event handler, command handler, lifecycle) vs. a provider (stable service). The closed-loop guarantee.

55 — Boundaries and Context [NEW]
<kit-boundary> declarative form. runtime.attachBoundary programmatic form. Surface, feature, entity. Nested boundaries and context inheritance. Programmatic boundary handles.

56 — Metadata: HTML as Application Protocol [NEW]
The metadata boundary in detail. meta-* attributes on custom elements. data-meta-* attributes on plain DOM. Composed meta:event and meta:command custom events. Event delegation and attribute parsing. The chapter that explains how Kitsune lets server-rendered HTML, Lit components, and AI-generated markup all speak the same protocol.

57 — Events vs. Commands: The Closed Loop [NEW]
Events as facts; commands are requests. runtime.emit and runtime.on. runtime.command and runtime.handleCommand. Command results. When to use which.

58 — Diagnostics and Devtools [restructured]
runtime.onDiagnostic. The debug module. The closed-loop visualization. The future devtools panel design.

59 — Application 1: Settings Panel [existing chapter is a stub — full rewrite]
First complete app. Forms, state via storage, modules, validation. Every piece of the architecture exercised in something small.

60 — Application 2: Profile Editor [existing chapter is a stub — full rewrite]
Async data loading, repository pattern, adapter mapping, async-loading widgets.

61 — Application 3: Design Token Editor [existing chapter is a stub — full rewrite]
Reactivity from storage, CSS custom property generation, theme switching at runtime.

62 — Application 4: Admin Table [existing chapter is a stub — full rewrite]
Lists, sorting, filtering, pagination, permissions, audit logging. Boundaries with rich entity context.

63 — Application 5: Mini Prompt Workbench [existing chapter is a stub — full rewrite]
The capstone application — AI-flavored. A small AI prompt workbench that demonstrates Kitsune working with stochastic / streaming / generated content. Sets up the AI section in Part VIII directly.

64 — Using Kitsune with React (and Other Frameworks) [existing draft — needs voice rewrite + expansion]
The framework adapters. KitShellProvider and KitBoundary for React. The pattern for Vue, Next, Nuxt, TanStack. Why Kitsune doesn’t ask you to throw out your existing framework.

65 — What Kitsune Is Not [NEW]
The negative space. Where Kitsune doesn’t try to compete (full-blown SSR meta-frameworks, native mobile UI toolkits, etc.). When NOT to use Kitsune. The honest scope.

Part VII — Production, Integration, and Migration

The operational realities.

66 — Server Rendering and Progressive Enhancement [existing draft — needs voice rewrite + expansion]
SSR as default, not opt-in. Hydration vs. attachment. Progressive enhancement as a real strategy, not a slogan. The relationship between Kitsune and Astro / Rails / Phoenix / Django / Laravel as rendering hosts.

67 — Performance: Measuring What Matters [NEW]
Core Web Vitals, Lighthouse, real user monitoring. The performance argument for platform-first (small bundles, fast TTI, no hydration cost). Honest engagement with React’s reconciliation argument. Carries: Addy Osmani and the Chrome team’s performance work.

68 — Real-Time, Collaboration, and Multiplayer State [NEW]
WebSockets, WebRTC, BroadcastChannel. CRDTs and operational transforms. Yjs, Liveblocks. Figma’s multiplayer architecture as case study. How real-time fits into Kitsune’s module / event model.

69 — Privacy, Security, and Data Capture [existing draft — needs voice rewrite + expansion]
Practical security in production. CSP, SRI, COOP/COEP. Data capture done right. The audit module pattern.

70 — Migration: Moving an Existing React App Toward Kitsune [NEW]
The transitional architecture story. Most readers can’t rip out their React app. The strangler-fig pattern. Web components as adoption wedges. The React adapter as bridge. Realistic timelines and realistic scopes. The chapter the gap-list discussion identified as missing — most readers’ actual situation.

71 — Testing Modern Frontend Architecture [existing draft — needs voice rewrite + expansion]
Playwright for browser tests. Vitest browser mode for component tests. Testing the closed loop. The accessibility-tests-as-architecture argument.

Part VIII — The Future

The closing movement. The hook the book has been structurally aimed at since the introduction.

72 — Contextual Depth as the New Superpower [NEW]
The reader has now done the work. They have the contextual depth the introduction promised. What that means in practice: how to use AI tools with judgment; how to recognize when an abstraction is unnecessary because the platform already provides it; how to evaluate the AI’s suggestions against the substrate. The “AI as collaborator for the contextually-deep developer” argument made concretely.

73 — From Chat to Generated UIs: The Next Interface [NEW]
Why chat is transitional. The rise of richer in-chat components. The dynamic, personalized, AI-generated interface as the next frontier. The economics: why these interfaces have to ship on the platform. The HTML-as-AI-output argument: the AI generates markup, the runtime treats it like any other markup, and the same Kitsune architecture absorbs it without modification.

74 — Security, Reliability, and Cross-Device Delivery for Stochastic UIs [NEW]
The hard engineering problems of AI-generated UIs. Sandboxing generated content. Validation at the boundary (the same Kitsune principle, applied to AI output). Cross-device portability — phone to watch to TV to whatever comes next. The trust and governance question. Where the supply-chain and longevity arguments matter most.

75 — What Comes Next: A Platform-First Future [NEW]
The closing chapter. The book’s arc revisited. The reader’s superpower. The platform’s continued evolution. Where Kitsune fits, and where it doesn’t. The argument for taking the operating system underneath seriously — for today’s products and for the interfaces that don’t exist yet. Closes by returning to the introduction’s hook with the depth to engage it.

Open structural questions

Most prior questions are now resolved by the chapter map above. Remaining open questions:

1. Does the open-source-vs-corporate-backing thread need a dedicated reflective chapter somewhere, or does it stay woven through? Currently woven through Chapters 11, 13, 15, 16, 18. Lean: stay woven, but add a brief reflective passage in the closing chapter (Ch 75) about the political economy of frontend infrastructure.
2. Should i18n (Ch 30) and accessibility (Ch 29) merge into one chapter, or stay separate? Currently separate. Lean: keep separate — both deserve full treatment as platform commitments, and combining risks shortchanging one of them.
3. Does Privacy / Security (Ch 31) belong in Part II as a capability, or in Part VII as an operational concern? Currently Part II as a platform capability, with practical operations in Ch 69. Lean: keep both, as they engage different aspects.
4. Does WebAssembly need its own chapter, or fold into Ch 32? Currently folded into the WASM/Workers/Hardware chapter. Lean: depends on how much depth WASM gets; if it’s more than a section, split into its own chapter.
5. Does the “Vue, Solid, Svelte” chapter (Ch 14) want to split per framework? Currently combined as the “reactivity counter-argument” chapter. Lean: keep combined — they’re variations on a theme and three short chapters would lose the framing.
6. Where does Storybook live? Currently mentioned in Ch 51 (Design Systems). Open: could deserve its own chapter as the canonical component-development environment, particularly given how much it shapes how teams build.
7. Should the runtimes chapter (Ch 16) include build tooling (Webpack → Vite → ESBuild → Bun bundler)? Currently it’s runtime-focused. Lean: yes, brief inclusion — the runtime story and the build-tool story are intertwined, and dedicating a separate chapter to build tooling probably isn’t justified.

Working notes

Sketches, half-formed ideas, things to come back to. Add freely.

Candidate framings and pull quotes (raw material)

Author’s own articulations from planning conversations. Preserve as source material — the published prose may rework these, but should keep the shape and spirit.

• “The current ecosystem was built to solve past problems. How do you build the future on it?” — close to a thesis sentence for the AI/future section, and arguably for the whole book.
• “How do we allow AI and all its stochastic messiness to build new novel UIs for users on demand that work, across any device or context?” — the central engineering question the AI section has to engage with seriously.
• “It’s by deeply understanding how we got here that we can more clearly see the opportunities for where we can go.” — the connective tissue that explains why the book’s history-first structure is rhetorically necessary, not nostalgic.
• “The layers like React, Apollo Client, GSAP, Next.js seem like magic — until you dig beneath the hood and realize they are incredible feats of engineering built on top of the operating system and APIs that the browser engine provides.” — strong candidate for the introduction or the close of Part I. Embodies the entire book’s stance toward existing tools: respect, then understanding, then the recognition that knowing the substrate is the actual superpower. Pair well with the “browser as operating system” thesis.
• “Decorate the API with an opinion.” — the design principle for “good” abstractions, distinguishing decoration from replacement. Belongs in the ergonomics chapter as a named principle the rest of the book refers back to. Possible chapter opener or pull quote.
• “The honest framing isn’t platform vs. framework. It’s whether you want to work at a higher level of abstraction, or directly at the application interface.” — the cleanest reframe of the platform-vs-framework debate. Belongs in the ergonomics chapter and worth referencing in the introduction’s “altitude” line.
• “Are we satisfied that this is it? Is this the last web?” — the provocation the book wants the reader to sit with. Belongs in the closing chapter (Ch 75) and possibly echoed in the introduction. Carries the invitation-to-invention framing.
• “The book is an invitation to join a long conversation about invention.” — the closing posture. Frontend’s history is a chain of inventors; the reader is invited into the lineage, not just instructed in its current state.
• “A developer with depth can use AI to create things that don’t exist yet. A developer without depth can use AI to make more of what already exists.” — the cleanest articulation of the AI-and-depth argument. Belongs in Ch 72 (Contextual Depth as the New Superpower).

Notes for specific chapters

• Introduction: the AI-generated-UIs / future-of-interfaces angle is the major hook for the book — it must lead the introduction, not be planted as a buried teaser. The opening paragraphs should say plainly: the next decade of interfaces won’t be hand-authored, they’ll be generated, personalized, dynamic, ride anywhere; that future has to be built on something; the something is the platform this book is about. From there, the introduction can pivot back to the historical / architectural argument as the path to that future. The whole book — the history, the platform chapters, the architecture, Kitsune — is structurally aimed at this hook.
• Close of Part I or opening of Part II: the “React/Apollo/GSAP/Next.js seem like magic until you look underneath” moment lands well as the bridge from history into the platform argument. The reader has just walked through twenty years of accumulated abstraction; this is the line that turns “here’s how we got here” into “here’s why what’s underneath matters” — and quietly sets up the closing future-of-UIs section by reminding readers that the substrate underneath is what bears the weight.

Other notes

• Consider whether the browser-engines material wants to come before the framework chapters (so the reader knows what jQuery was working around when we get there) or after them (so it lands as the “look what was happening underneath” reveal).

• Open question on the AI chapter’s voice: it has to land for readers who are AI-skeptical and readers who already use AI heavily. Probably needs a different opening posture than the rest of the book.

• The Bun → Anthropic acquisition is a recent and politically loaded fact. Worth thinking about how to frame it without it dating the chapter quickly.

• The Electron / web-as-native chapter is potentially the book’s most rhetorically important moment. Most engineers are already using a Chromium-based application to write the code that targets a Chromium-based application. Once the reader sees that pattern, the rest of the book’s argument is downhill. Worth treating as a deliberate hinge, not a footnote.

• Worth checking: how the Electron story interacts with the open-source-vs-corporate thread. GitHub built Electron, Microsoft bought GitHub, Microsoft built VSCode on Electron — Microsoft now effectively controls both the dominant editor and the dominant cross-platform desktop app shell. Likely a paragraph in both the Electron chapter and the open-source thread.

• The dependency-hell argument is itself a major reinforcement of the platform-first thesis. The platform has no node_modules. It doesn’t break when a maintainer unpublishes a package. The smaller the dependency surface, the more resilient the system. This connects forward to the AI-generated-UIs section: shipping stochastic UIs into an ecosystem with 1,500-deep transitive dependency trees is a security non-starter.

• The multidimensional case for the platform-first approach. The back-to-basics argument is simultaneously:

  1. Aesthetic — cleaner architecture, fewer layers, less indirection.
  2. Economic — smaller bundles, faster delivery, lower hosting cost.
  3. Operational — fewer breakage vectors when an upstream changes.
  4. Security — smaller attack surface, fewer transitive deps to audit.
  5. Longevity / maintenance — code written against the platform stays working; code written against frameworks needs rewriting every few years (Angular 1 → 2, class components → hooks, Webpack → Vite, CommonJS → ESM, the steady deprecation churn).
  6. AI-readiness — stochastically generated UIs shipped today have to keep working tomorrow without intervention; the platform’s evergreen guarantee makes that possible in a way that the framework ecosystem does not.

  All six make the same case from different directions. The book should engage all six, not just (1) and (3) which the early draft mostly leaned on.

• The JavaScript standardization chapter and the supply-chain chapter probably want to be adjacent to each other in the running order — they’re a paired story about the language platform and the dependency ecosystem on top of it. Together they set up the platform-first argument that runs through the rest of the book.

• The “decoration vs. replacement” framing should become a named pattern the book uses consistently from the ergonomics chapter onward. Whenever we evaluate a library, framework, or abstraction, we can ask: does this decorate the platform with an opinion, or does it replace the platform with a parallel reality the library owns? The framing applies to React (replacement), Lit (decoration), Solid (mostly decoration), Svelte (decoration via compile-time), Vue (mixed), Kitsune (decoration as design intent). Worth using the framing in the framework chapters when each is introduced, then formalizing it in the ergonomics chapter.

• Routing-as-backend-concern is the most consequential Kitsune position the book takes. It reshapes several chapters: Ch 1 (the document web) becomes preparation, not nostalgia; the Ajax / SPA / meta-framework chapters need to be told as the story of the industry pulling navigation into the client and what it cost; the Part II / III chapters on the platform now need an explicit “routing belongs to the server” section that engages the SPA-router inheritance every reader brings; and the Kitsune chapters can lean on this position rather than sidestepping it. Worth flagging this position early in the book (probably in the introduction’s “what we’re going to build” tour) so readers who reflexively reach for React Router know what to expect.

• Storage-as-state-layer needs its own chapter in Part II. The browser’s storage tier (localStorage, sessionStorage, IndexedDB, OPFS, the Cache API) plus the storage event for cross-tab and cross-component reactivity is a real architectural answer to “where does state live?” — but the existing draft doesn’t engage it as such. Chapter slot: somewhere in Part II between the DOM-as-context-tree and forms-as-transactions chapters.

• Data patterns deserve their own chapter in Part IV. Repositories, adapters, validation at the boundary, authentication header decoration, async-loading widgets — these are the practical “how do I talk to a server” answers Kitsune leans on. The chapter can also engage the Apollo / axios skepticism honestly: when does a third-party data layer still earn its place, and when is it the kind of over-abstraction the rest of the book is arguing against?

• The HTML-as-composition-language principle resolves the JSX-equivalent question. Compose with HTML directly — server-rendered, Lit-rendered, or AI-generated, all converge. No need for a Kitsune JSX. This belongs as an explicit principle in the web components / Kitsune chapters and connects directly to the AI-generated UIs section: the AI’s output target is the same HTML composition any other rendering source produces.

Notes on the comprehensive chapter map (added 2026-05-10)

• Scope reality. The chapter map proposes ~74 chapters across 8 parts. At ~8 pages per chapter that’s a 600+ page comprehensive O’Reilly-scale book. The author has said this is the right scale.
• Renumbering executed 2026-05-13. The repo chapter files have been renumbered to 01–46 to accommodate the inserted Ch 3 (The Stylesheet Ecosystem). Repo file numbers and planning-doc numbers now line up for the chapters that exist. Future inserts will require similar renumbering passes.
• Order of work. The most leveraged sequence for actually executing the rewrite:
  1. Finish Chapter 1 review (we’re here).
  2. Rewrite Chapters 2–3 (CSS, JavaScript) in voice + expansion mode using existing draft material.
  3. Draft Chapter 5 (JS Standardized — NEW).
  4. Draft Chapter 6 (Browser Wars — NEW).
  5. Continue forward, adding new chapters where they slot, rewriting existing ones in place.
  6. Save Part VI (Kitsune chapters 51–64) for after the architecture spec has stabilized through use in earlier chapters.
• Existing repo files vs. proposed chapters. The existing book-draft/01-… through 46-… now line up with planning-doc Ch 1–46 for the chapters that exist. Planning Ch 5, 6, 12, 14, 16, 17, 18, 25, 26, 28, 30, 31, 32, 33 (and more in later Parts) are NEW and don’t yet have repo files; they get drafted into new files at their planning-doc number when we get to them.
• Animation and View Transitions added (2026-05-10). The View Transitions API is design-relevant enough that it justifies its own chapter rather than a passing mention. It also closes the ergonomic loop on the routing-belongs-to-the-server position — server-rendered navigation can feel as smooth as SPA transitions when the platform handles the animation declaratively. Insertion at Ch 28 shifted Part II–VIII numbering by +1; total chapters went from 73 to 74.
• Reverence and invitation framing added (2026-05-10). Two new framing dimensions added to VOICE.md and the outline’s hook section: reverence for the masters (every named figure was often the absolute best at what they did, doing world-class engineering at the edge of what the platform of their day allowed — the tone when naming them is reverent, and critique comes from gratitude rather than hindsight) and the book as an invitation to invention (the closing posture is that we’re not at the end of frontend evolution, and the reader, with the contextual depth the book provides, is being invited to join the long conversation about invention — alongside AI as collaborator). These principles shape the voice of the historical chapters (reverence) and the closing chapters (invitation), and should be felt throughout. The closing chapter (Ch 75) is the natural place to make the invitation explicit, paired with the question “are we satisfied that this is it? Is this the last web?”
• Kitsune chapter restructure. The current Kitsune chapters (existing 35–41) become the new 50–63 — but with seven new architectural chapters (51–56 + 63) inserted before/around the application chapters. This restructure is the biggest single change to the existing draft and probably wants a dedicated planning pass before drafting begins.