You missed the point. It's not about what React does, it is the "nobody uses jQuery anymore, everybody uses React" syndrome. React doesn't need to do anything as long as we use it.

I think you're attacking a straw man here. The people who want you to get rid of jQuery are mostly arguing that vanilla JS does what jQuery does.

As for abstracting the relationship between data and presentation, there is definitely a React bandwagon, but that's kind of the second stage after getting past jQuery.

I got your point, but who uses vanilla JS these days when you can just use React, specially when it is not needed?

I can’t imagine a more suitable use case for a static site than for documentation. Why on earth?

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.

Even a static site needs to be generated somehow, and React is quite a nice way to generate HTML. It can even do that on the server, and disabling JS in dev tools shows that's what they do :).

> Even a static site needs to be generated somehow

No, it doesn't. You can just write it.

Anyway, the question here is not why they're using React to generate a site, but rather why they're using it to display the site.

As others have mentioned, there are lots of tools to write DRY HTML/CSS, then compile, then deploy as a static site. No one would ever know which tool you used.

The weird thing here is that they're using React in the browser (not as a one-time step) for a completely static site.

I love using Markdown for documentation. It's readable in source, it's easy to compile to HTML, and it's pretty easy to add some JavaScript later for dynamic parts.

Why not? There's no real downside when combined with SSR.

Complexity is costly and generally more brittle

Even "just writing it" is a generation step.

If it's anything like my experience then one thing to switch to React or any frameworks would be for better developing experience.

For simple pages templates are totally fine and frameworks might be overkill but when the projects starts getting big stringing templates together can be quite painful let alone debugging them.

Just my opinion though but I'd also like to hear the actual reason for the switch.

Firefox's web developer tools are all react/redux now as well, and are much laggier because of it :(