The Modern Web Front End
From the two files every page is still made of, up to a rendering model where half your components never reach the browser at all.
9 articles · about 91 min in total
Start with How HTML and CSS Actually Work TogetherFront-end work has a reputation for churn that is only half deserved. The tools change constantly. The underlying model has changed exactly once in the last decade, and this path is about that one change.
It starts where every page still starts, with two files and the relationship between them. That is not filler. A surprising amount of modern front-end confusion comes from people who learned a framework before they learned what the framework is generating.
The middle steps are the actual shift. React Server Components split a component tree across a network boundary, so some components never reach the browser at all. That is a genuinely different mental model, not a new API, and most of the production pain people report comes from applying the old model to it.
The path ends on the build and runtime layer, including WebAssembly, because that is where the next boundary is moving. It is worth knowing what it is actually good at, which is narrower and more interesting than the marketing suggests.
Key takeaways
- React Server Components split the component tree across a network boundary, so some components never ship to the browser at all.
- Most reported pain with server components comes from applying client-component assumptions about state and effects to code that runs once on the server.
- TypeScript pays for itself at the point where types encode rules the runtime would otherwise have to check at every call site.
- WebAssembly is worth reaching for when a workload is compute-bound in the browser, and rarely worth it for ordinary application logic.
Step 1: How HTML and CSS Actually Work Together
HTML defines what a page contains. CSS defines how it looks. The relationship between them is one of the cleanest separation-of-concerns examples in computing, and it’s also a lot more nuanced than most beginner tutorials let on.
Aug 26, 2025 · 6 min read
Step 2: How JavaScript and jQuery Are Related
jQuery is a JavaScript library that dominated web development for a decade. The reason it existed, and the reason it doesn’t need to anymore, is most of the story of how the modern web got built.
Aug 19, 2025 · 5 min read
Step 3: Advanced TypeScript Patterns Every Senior Engineer Should Know
From discriminated unions and branded types to variadic tuples and module augmentation: the TypeScript patterns that catch real bugs.
Feb 24, 2026 · 15 min read
Step 4: React Server Components in Production: What Nobody Warns You About
The server-client boundary is a clean idea. The runtime serialization errors it throws at 2am are not. Here's what breaks when React Server Components meet real traffic, plus the CVSS 10.0 flaw that hit the whole ecosystem in December 2025.
Jun 6, 2026 · 11 min read
Step 5: Next.js 16 Cache Components: The Mental Model That Finally Makes Sense
Next.js 16 flipped the caching default: nothing is cached unless you write 'use cache'. That sounds like a footgun and turns out to be the fix. Here's the mental model that makes Partial Prerendering click, and the traps that hang your build for 50 seconds.
Jun 8, 2026 · 11 min read
Step 6: Design Systems for Platform Teams
Building a design system is easy. Getting product teams to actually use it is the hard part. Here's how platform and product engineering co-own a system that speeds up delivery without becoming a bureaucratic bottleneck.
Jan 14, 2026 · 8 min read
Step 7: pnpm vs npm: The Real Reason to Switch Isn't Speed
Most pnpm vs npm comparisons lead with install times. They're missing the point. npm's flat node_modules silently lets your code import packages you never declared, and the bug only surfaces in production. pnpm refuses to lie to you.
May 5, 2026 · 15 min read
Step 8: WebAssembly in Production: Real Performance Gains and Practical Trade-offs
What WASM actually delivers in production: real benchmark numbers, Rust compilation workflows, and honest trade-offs for browser and server deployments.
Mar 17, 2026 · 9 min read
Step 9: WASM Components: The Quiet Standard That's About to Eat Microservices
Containers won a decade ago. The next unit of deployment is smaller, boots in microseconds, and nobody's calling it a container. It's the WebAssembly Component Model plus WASI Preview 2, and it just got native async in WASI 0.3.
May 31, 2026 · 11 min read
Frequently asked questions
- What problem do React Server Components solve?
- They let components that only read data run on the server and ship their rendered output instead of their code. That removes library weight from the bundle and lets data access happen without an extra API round trip, at the cost of a harder mental model.
- Is TypeScript worth it on a small project?
- Usually yes, because the cost is front-loaded and the benefit compounds. On a genuinely throwaway script it is overhead. On anything you will return to in three months, the types are the only documentation guaranteed to still be true.
- Should I use pnpm instead of npm?
- pnpm is faster and uses far less disk because it links packages from a content-addressed store rather than copying them. The stricter dependency resolution also surfaces packages you were relying on without declaring, which is a benefit that first appears as a broken build.
- When is WebAssembly actually worth using?
- When the work is compute-bound and already exists in a compiled language: video and image processing, cryptography, simulation, parsing large formats. For ordinary application logic the call overhead and bundle cost usually outweigh the raw speed advantage.