15 posts tagged with "react"

Most people install Claude Code, talk to it like a chatbot, and stop there. The difference between that and a genuine force multiplier is a small amount of configuration: a file that tells it your conventions, a couple of hooks that enforce quality automatically, and one skill that encodes a workflow you'd otherwise re-type every day.

The first load of a Next.js app is a document — HTML down the wire, parsed, hydrated. But once the app is interactive, open your Network tab and you'll notice it never asks for a document again. Instead you see a trickle of odd little requests: some are GETs that return something that isn't HTML, and some are POSTs to the page you're already on, streaming a response back. Those POSTs are the part that looks weird, and they're the reason this post exists.

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.

"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.

Routing in React has evolved from simple client-side navigation into a larger architectural concern. Today, routes can define not only which component appears for a URL, but also how data is loaded, how mutations happen, how errors are handled, and how layouts are nested.

A top-down tour of Next.js: start from the mental model of the framework as a whole, then drill into the concepts that actually shape how you build with it.

This is the first of a series of posts about the most common mistakes in Frontend development. This is the most common mistake I see in React projects.

This post explains what the Single Responsibility Principle (SRP) is and why it's important for React components. It shows how putting too much code and too many tasks in one component can lead to messy, hard-to-maintain apps.

The Compound Component Pattern has become a popular approach in React for building flexible, reusable components. You'll often see it in two flavors: separate exports (<SelectTrigger />) or dot notation (<Select.Trigger />). But like any pattern, it comes with significant trade-offs. Let's explore both sides.

A one-line-per-concept tour of Next.js — the whole mental model at a glance, from routing to rendering to deployment, with no fluff.

Recently, we had an in-depth discussion on structuring React applications using a layered architectural approach. This method aligns with fundamental software architecture principles such as the Single Responsibility Principle (SRP) and the Single Source of Truth (SSoT). It shares similarities with Clean Architecture and Layered Architecture and, interestingly, shows parallels with the Model-View-Controller (MVC) pattern in some respects. We are also applying Dependency Inversion principle (DIP), depending on abstractions rather than concrete implementations of lower-level modules.