What server components actually solved for me
I did not get it for a long time. Then one day I did. Here is the exact moment that changed.
Read postSearch across posts, tags, and categories.
Server components, client components, layouts, and why the file names mean what they mean. Written in the order things actually clicked for me.
The thing that finally made the App Router make sense to me was the idea that everything is a server component unless you say otherwise.
When I write a page.tsx, it runs on the server. That means it can read files, call a database, or fetch from an internal API, and none of that code ever reaches the browser. Very fast, very safe. The output is HTML.
When I want interactivity, I write use client at the top of a component file. Now it ships to the browser, and I can use hooks like useState, useEffect, and onClick. The line between the two is a boundary. I think of server components as the skeleton and client components as the joints.
Layouts are just server components that wrap multiple pages. The folder structure mirrors the URL structure. page.tsx is a route, layout.tsx wraps it, loading.tsx shows while data loads, error.tsx shows when something throws. That is basically it.
Everything else is a variation on this idea. Nested layouts, parallel routes, intercepting routes, route groups. All of them are just the file system describing the shape of the page tree.
I did not get it for a long time. Then one day I did. Here is the exact moment that changed.
Read postAn intro to who I am, what I'm learning, and why I'm writing this in public instead of in a private notebook.
Read postI was bad at prompting for a long time. This is the first one that got me a result I could ship.
Read post