Creating a Blog with React

when i was thinking about possible futures for Create React App, it was clear client-only doesn’t make sense. way too limiting.

why are we always producing an empty HTML file if React can pre-render to HTML? why can’t i make a blog by map()ing over markdown files on my disk?

— дэн (@dan_abramov) March 17, 2023

for a while i thought maybe that’s what the next iteration of CRA should be. sure, you still don’t have to use a Node.js server — but you should be able to take advantage of running code during the build! it doesn’t make sense that you did not have that option.

— дэн (@dan_abramov) March 17, 2023

in that possible future, you’d imagine CRA was similar to what it used to be, but it can do a static pre-render of your component tree. so that your HTML isn’t empty. but from that point it obviously lets you use client features. we like interactivity :)

— дэн (@dan_abramov) March 17, 2023

however, you can’t make it work that way without an integration with a router. how else can we pre-render more than a single page? we wouldn’t know what to render.

okay, so let’s add a file-based router as a good “works for most cases” solution. HTML per route + client handoff.

— дэн (@dan_abramov) March 17, 2023

we could actually stop here. you’d have a tool that generates some code during the build and lets you do the rest on the client. navigations feel like SPA.

then let’s say you *want to* add one dynamic server route. but you can’t do that. you are LOCKED INTO not using the server.

— дэн (@dan_abramov) March 17, 2023

here’s the thing.

the current crop of modern frameworks (specifically, Next.js and Gatsby) already work this way.

they let you start 100% static + client. HTML generation, file-based routing, SPA navigations, and real client code (as much as you like). that’s the baseline.

— дэн (@dan_abramov) March 17, 2023

however, if you *do* want to use the server for some dynamic route — like, reading from a DB instead of a file — they let you do that easily. you just change a couple of lines of code. your existing pages remain static/client.

frameworks provide LESS LOCK-IN in that sense.

— дэн (@dan_abramov) March 17, 2023

so i realized that building this would just building a more limited version of what Next.js/Gatsby already have to offer. it would do exactly the same things they already do, but would not allow you to do more.

modern frameworks are hybrid. they let you build SPAs *and more*.

— дэн (@dan_abramov) March 17, 2023

it’s the same story with React Server Components. people hear “server” and assume Node.js. but RSC can run during the build.

in fact, in Next 13 App Router it’s the *default*. if you fetch() something in RSC, it would be *at the build time* unless you opt into dynamic rendering.

— дэн (@dan_abramov) March 17, 2023

the shift we’re seeing (and yes, trying to make happen) is not from “writing SPAs” to “not writing SPAs”.

it’s from “being locked into SPAs” (it’s difficult to add built-time or server-side integration later on) to “using whatever mode makes sense for each page”.

hybrid era.

— дэн (@dan_abramov) March 17, 2023

it’s a shift, but mostly a mental shift.

past: “start with client-only. rewrite to another approach when need build-time or server.”

future: “start with build-time + client, however you want to split it. add server if you want. per page.”

— дэн (@dan_abramov) March 17, 2023

as everything converges on hybrid, our old terminology gets really confusing.

- people want to save “SPAs” because they like not having to run a server.
- people dismiss “static” because they like navigation without page reloads.

but hybrid does all of that already!

— дэн (@dan_abramov) March 17, 2023