When you first open a Next.js app, the browser downloads a document: a page of HTML (HyperText Markup Language). The browser reads it, and then React makes it interactive (this step is called hydration). After that, open the Network tab of your browser's developer tools and you'll see that the app never asks for a document again. Instead you see a small, steady number of unusual requests. Some are GETs that return something that isn't HTML. Others are POSTs to the page you're already on, and their answer arrives in pieces. Those POSTs look the strangest, and they're what this post explains.

You type a domain, hit Enter, and a second later you're clicking around a working app. That second is deceptively busy. Between the keystroke and the first working button there's a DNS lookup, a couple of cryptographic handshakes, a streamed HTML document, a fan of parallel downloads, a serialized React tree, and a reconciliation pass that stitches JavaScript onto server-rendered markup without throwing any of it away.

A design system that starts on the web rarely fits mobile directly. This post shows what still works on mobile, what doesn't, and how to keep one source of truth (one place that stores each design decision) for both.

"Rendering" is one of those words that means three different things depending on who you ask. Before we walk the timeline, it helps to separate the layers:

1. The rendering API — the actual function you call (ReactDOM.render, createRoot, renderToString…) to turn a component tree into DOM or HTML.
2. The rendering strategy — where and when the HTML is produced: in the browser, on a server per-request, at build time, etc.
3. The hydration model — how a server-produced HTML page becomes interactive on the client. The post is organized around layer 2 (strategies), because that's where the chronological and simple-to-complex story is richest — but each strategy is tagged with all three: an At a glance box names its rendering API and hydration model too. There's also a short section near the end that lists the API methods on their own, since "render a component" can literally mean those. Each strategy also has a Metrics table in web-vitals shorthand (TTFB, FCP, LCP, TBT, INP, CLS) — every acronym in this post is spelled out in the Glossary at the end.

One honest caveat up front: chronology and complexity mostly line up, but not perfectly. Islands and streaming SSR landed around the same time, for example. I've ordered primarily by conceptual complexity and noted the rough dates as we go.

Every framework, HTTP client, and browser hides the protocol behind a few convenient calls — so most developers never see the request that actually goes over the wire. This post pulls back that curtain: the communication model, the methods, the status codes, and the headers you've been using all along without knowing it.

Debugging a React single-page application (SPA) and debugging a Next.js App Router app are different sports, and the whole difference comes down to one thing: where your code runs. This is a recipe-oriented reference for the questions that keep coming up — where your logs went, how to see backend calls, how to observe React Server Components (RSC), and which logging options and tools are worth reaching for.

Bundlers are the most invisible critical infrastructure in frontend development. Every npm run dev and every continuous-integration (CI) pipeline runs through one, yet most of us only think about them when something breaks or when a migration guide lands in our feed. This post is an attempt to fix that: what a bundler actually does under the hood, how we got from script tags to Rust toolchains, which tool owns which niche today, and where the whole thing is heading.

Type a URL, hit Enter, and a page appears. Between that keystroke and the first pixel sits a surprising amount of machinery — DNS, TCP, TLS, HTTP, load balancers, and the services behind them. This post walks the whole path, end to end.

Virtual Private Network (VPN) marketing has done an incredible job convincing people that a single subscription makes them anonymous, secure, and untouchable. "Military-grade encryption." "No logs." "Total privacy." The reality is far messier: a VPN is a useful tool for a narrow set of problems, but as a privacy solution it has structural weaknesses that no amount of marketing can fix.

A CDN feels like magic: your site suddenly loads fast everywhere. But it's really just a handful of well-understood parts working together. Let's take them one at a time.