I find react to be a very pleasant way to make websites, even static ones. And for static sites you can use SSR or something like GatsbyJS to make everything load as if you had actually written the html (i.e. no dependence on javascript). That's the approach I use for my blog and according to google pagespeed the only problem with it is that the TTFB is too high (which is surprising because I host it as a totally static site on AWS)

How is it surprising that rendering a React website is slower than simple HTML?

The server doesn't do any rendering before serving the page. All the "SSR" is done exactly once at build time. To the server it's no different from serving any other site.

I'm not too familiar with Gatsby but something has to be slowing you down if TTFB is too high.

It's not that high, Google says I might be able to save .8 seconds. I might try hosting on netlify and see if that improves things

An SSR React site IS simple HTML.

Doesn't matter, React has to rehydrate which blocks the CPU.

SSR solves waiting for the API but not the CPU problem.

That doesn't affect TTFB.

Ah you are right, my bad. I was thinking of TTFI.

Because static sites are not cool anymore unless you use Gatsby and its GraphQL interface to read your markdown files, because directly read markdown from your disk is not cool either.

Why keep reading markdown from disk and regenerating the page when you can just compile the site once and be done with it? Much easier to cache.

I think you missed the sarcasm from parent poster.

Docs can be really dynamic, like the ones that have runnable sample code in various languages. It's just that these docs... aren't.

Even for those, it's completely reasonable to have most of the page be static and only have the runnable parts be dynamic. You could use React for the dynamic bits and regular HTML for the rest.

Unfortunately, React typically takes over the whole page, so it's a little less straight forward.