Seven talks and essays, none of them a framework tutorial, that together cover what a senior frontend engineer is actually paid to understand: how a page gets to the user, where the client/server boundary sits, how a codebase stays maintainable, and how engineering practice changes when an agent writes most of the code. Each one is worth an evening; this post says why, and in which order.
This list reflects the state of things as of March 2026. The ideas in these pieces are durable; the specific tools, metrics thresholds and model names mentioned in them will drift, so check the current details before quoting numbers.
Frontend engineering at a senior level is not mostly about React. It is about three questions that outlive any framework:
- How does the page reach the user? Bytes, parsing, rendering, interactivity, and the metrics that measure each step.
- Where does the program run? Which parts execute on the server, which in the browser, and what crosses the boundary.
- How does the code stay coherent? The architecture that keeps a large codebase changeable, and, since 2025, the practices that keep it coherent when an agent writes most of it.
The seven pieces below map onto those three questions, and that is the order they are worth watching in. The browser layer comes first because everything above it is a trade-off against it; the boundary comes second because React Server Components (RSC) only make sense once you can picture the browser's cost model; architecture and agent practice come last because they are decisions about people and process, and the earlier layers constrain what they can achieve.
The common thread is that every one of these pieces teaches a cost model rather than a recipe, and cost models are the only frontend knowledge that survives a framework change. A tutorial on the current router will be stale in eighteen months. Knowing why hydration costs what it costs, or why a component that runs on the server cannot hold client state, does not go stale.
The browser: loading and rendering
Start here, because every later decision, from where a component runs to how much the agent is allowed to generate, is ultimately paid for in the browser. Two long videos by Dmitriy Zhiganov, a Berlin-based senior frontend engineer whose channel is built around frontend system design, cover the layer end to end.
The 2025 Web Performance Roadmap
Frontend System Design: The 2025 Web Performance Roadmap (about 69 minutes, December 2024) splits performance into two problems that are usually blurred together: loading time, meaning how long until the page is usable, and user interface (UI) speed, meaning how responsive it feels once it is. The first hour then walks the loading half metric by metric, in the order the browser experiences them: Time to First Byte (TTFB), First Contentful Paint (FCP), Largest Contentful Paint (LCP) and Time to Interactive (TTI), with the levers that move each one.
The reason to watch it rather than skim a Core Web Vitals cheat sheet is the ordering. Each metric bounds the next: you cannot paint before the first byte arrives, and you cannot be interactive before the paint, so optimising a late metric while an earlier one is slow is wasted work. The video makes that dependency chain explicit and hands you a checklist that follows it. It is framed as system design interview preparation, but the content is exactly what a performance audit on a real product looks like.
Web Rendering Patterns
Web Rendering Patterns: SSR, CSR, Hydration, Static Generation, Resumability (about 80 minutes, July 2024) is the natural sequel: once you know what the metrics cost, the question is which rendering strategy buys the ones you need. It covers Server-Side Rendering (SSR), Static Site Generation (SSG), Client-Side Rendering (CSR), hydration, trisomorphic rendering, resumability and CSR with pre-rendering, then closes with three worked cases, a social network, a dashboard and a marketplace, where the choice is argued rather than asserted.
Two ideas from it are worth keeping. The first is the framing of pages as cost centres versus profit centres: a marketing page that earns money from search traffic and a logged-in dashboard that earns none have different performance budgets, and picking one rendering strategy for a whole product ignores that. The second is what the video calls the "one app for the price of two" problem: with SSR plus hydration you pay to render the page to HTML (HyperText Markup Language) on the server, then ship the whole application again as JavaScript so the browser can render it a second time before anything is clickable. Resumability, and partial hydration in general, exist to stop paying twice.
The table below is the compressed version of the trade-offs the video spends an hour on. It is a simplification; the video is where the nuance lives.
| Pattern | Where the HTML is produced | Time to first content | JavaScript before interactive | Server work per request | Typical fit |
|---|---|---|---|---|---|
| Static Site Generation (SSG) | At build time | Content that changes rarely | |||
| Server-Side Rendering (SSR) + hydration | On the server, per request | Personalised, crawlable pages | |||
| Client-Side Rendering (CSR) | In the browser | Logged-in dashboards | |||
| CSR with pre-rendering | Shell at build time, rest in the browser | Marketing page in front of an app | |||
| Resumability | On the server, with serialised state | Interaction-heavy public pages |
The boundary: one program, two computers
With the browser's cost model in place, the next question is where the program runs. The two React Conf 2024 talks below approach RSC from opposite ends: one derives the idea from first principles, the other builds it from scratch in code. Watched together they leave very little mystery.
React for Two Computers
React for Two Computers by Dan Abramov (React Conf 2024, about 29 minutes; the talk page lists it) is the conceptual origin story of RSC. Its argument is that a web application was always one program that happens to span two computers: the server emits something the client executes, and fetch is the channel that coordinates the two halves. Most of the accidental complexity in a web app comes not from the domain but from coordinating one program across two machines.
The talk gets there by imagining React invented server-first. A tag like <Component /> is a potential function call, a blueprint that can be executed later and somewhere else, as opposed to an actual call that must run here and now. Components can be evaluated in an early world, on one computer, and dissolve into primitives, the elements that end up as Document Object Model (DOM) nodes, that a late world, on another computer, finishes off, with the serialised tree streamed between the two over HTTP (HyperText Transfer Protocol). Server components fall out of that split rather than being bolted on. Abramov later wrote the ideas up as an essay, React for Two Computers (April 2025), which is the better format for the second pass. Once you see the server/client split as a single program cut at a chosen point, most RSC rules stop being arbitrary and become consequences.
And Now You Understand React Server Components
And Now You Understand React Server Components by Kent C. Dodds (React Conf 2024, about 22 minutes) is the same idea from the implementation side. Dodds builds RSC without a framework: render a component tree to the RSC payload, stream it, resolve client module references, add a tiny client-side router, and handle caching and the back button. Each step is a few lines, and each removes a layer of "the framework does something magical here".
The point of building RSC by hand is not to ship a hand-built RSC, but to know precisely which problems a framework is solving for you and which of its constraints are essential rather than incidental. After this talk, "why can't a server component have an onClick" and "why is the payload not just HTML" are questions you can answer from the mechanism, not from the documentation.
The codebase: architecture and agent-era practice
The last three pieces are about keeping a codebase coherent. The first is the classic version of that problem: structuring code so it stays changeable. The other two are the 2025 and 2026 version: structuring the work so it stays verifiable when an agent produces most of the code.
Frontend Architecture Patterns You Need to Know in 2025
Frontend Architecture Patterns You Need to Know in 2025 (about 46 minutes, July 2025) tours the architectural patterns frontend applications borrow from the rest of software engineering: Model-View-Controller (MVC), Model-View-Presenter (MVP), Model-View-ViewModel (MVVM), Hierarchical MVC, MVVM with coordinators, VIPER (View, Interactor, Presenter, Entity, Router), Clean Architecture, Hexagonal Architecture, Screaming Architecture and Vertical Slices, each with guidance on when it earns its weight.
The value for a React engineer is recognition rather than adoption. Most React codebases are an unnamed MVVM, with hooks as the view models, and naming the pattern makes it obvious where the dependency arrows are supposed to point. The later sections, on Clean and Hexagonal architecture and on vertical slices, are the ones that matter for large applications: they are three different answers to the same question of how far the domain should be kept from the framework, and the video is honest that the answer depends on how long the code has to live.
Engineering practices that make coding agents work
My fireside chat about agentic engineering at the Pragmatic Summit by Simon Willison (March 2026, video with a full transcript) is the most practical piece on this list. It is a conversation with Eric Lui of Statsig, and it reads as a list of practices Willison has landed on after two years of agents writing most of his code:
- Red-green test-driven development (TDD) as a prompt. Telling the agent to write the failing test first turns the test suite into the thing that keeps it honest.
- Manual testing still exists. He built Showboat, a tool that has the agent produce a Markdown record of the manual test it ran, so the human reviews evidence rather than claims.
- Conformance-driven development. For anything that must match a standard, a test suite run across several implementations is how the agent discovers the standard's real edges.
- Code quality matters in proportion to lifespan. Disposable tools can be sloppy; long-lived code cannot, and agents copy whatever patterns the codebase already has, so a template that establishes good ones pays for itself.
- Sandboxing and the lethal trifecta. An agent with private data, exposure to untrusted instructions and a way to send data out is a security incident waiting to happen; run it where a mistake is contained, and never against production data.
- Ambition, and its cost. Agents make it cheap to start many projects at once; the limiting resource becomes the engineer's attention, not the code.
The through-line is that with agents the scarce skill moves from writing code to designing the verification the code has to pass. That is exactly the end-to-end (E2E) and integration-testing muscle frontend teams have historically underinvested in.
Beyond Vibe Coding
Beyond Vibe Coding with Addy Osmani (The Pragmatic Engineer podcast, October 2025, about 68 minutes) is the complementary view from someone who runs developer experience for Chrome. Osmani's central observation is the 70% problem: AI (artificial intelligence) tools get an experienced engineer to roughly seventy percent of a feature very fast, and the remaining thirty percent, the part that requires understanding the whole system and caring about quality, is where the engineering still happens. His answer is spec-driven development, planning before prompting, tests as the guardrail that shows when generated code has drifted, and keeping expectations low and control high.
Watched after Willison, the two agree on almost everything and disagree usefully on emphasis: Willison is more optimistic about how far autonomy can go inside a sandbox, Osmani more insistent that critical thinking is the part that does not delegate. Both land on the same conclusion, which is that AI-assisted development raises the value of senior judgment rather than lowering it.
The watchlist in one table
The pieces in viewing order, with the one thing each is best for. The last column rates how long the content will stay true: the conceptual pieces are close to timeless, the ones tied to a specific year of tooling will need a refresh.
| # | Piece | Author | Format and runtime | Best for | Shelf life |
|---|---|---|---|---|---|
| 1 | The 2025 Web Performance Roadmap | Dmitriy Zhiganov | Video, ~69 min | The dependency chain between loading metrics | |
| 2 | Web Rendering Patterns | Dmitriy Zhiganov | Video, ~80 min | Choosing a rendering strategy per page, not per product | |
| 3 | React for Two Computers | Dan Abramov | Conference talk, ~29 min, plus the essay | The mental model behind RSC | |
| 4 | And Now You Understand RSC | Kent C. Dodds | Conference talk, ~22 min | The mechanism behind RSC | |
| 5 | Frontend Architecture Patterns | Dmitriy Zhiganov | Video, ~46 min | Naming the structure your codebase already has | |
| 6 | Engineering practices for coding agents | Simon Willison | Fireside chat with transcript | Concrete verification practices for agent-written code | |
| 7 | Beyond Vibe Coding | Addy Osmani | Podcast, ~68 min | Where the engineering still happens with AI |
What they have in common
None of these seven tells you what to build. Each gives you a way to price a decision: what a byte on the critical path costs, what a second render costs, what a component costs when it moves across the boundary, what a dependency arrow in the wrong direction costs, what an unverified agent change costs. Senior work is mostly making those prices visible to the people who have to choose, and these pieces are the shortest path I know to being able to do that from first principles.
References
- Dmitriy Zhiganov, Frontend System Design: The 2025 Web Performance Roadmap, YouTube, December 2024.
- Dmitriy Zhiganov, Web Rendering Patterns: SSR, CSR, Hydration, Static Generation, Resumability, YouTube, July 2024.
- Dan Abramov, React for Two Computers, React Conf 2024 (talk page); and the essay React for Two Computers, Overreacted, April 2025.
- Kent C. Dodds, And Now You Understand React Server Components, React Conf 2024.
- Dmitriy Zhiganov, Frontend Architecture Patterns You Need to Know in 2025, YouTube, July 2025.
- Simon Willison, My fireside chat about agentic engineering at the Pragmatic Summit, March 2026.
- Gergely Orosz and Addy Osmani, Beyond Vibe Coding with Addy Osmani, The Pragmatic Engineer podcast, October 2025.