I think it is more about how you structure your components for development. React provides a nice modular approach using composition, which is just enjoyable to write. With static html files you need to come up with a good composition approach, forcing you to make decisions on how you want to do that.

Secondly, it also allows you to progressively enhance the static site easily if you want to in the future.

The same reason why anybody is using React instead of full site reloads.

Only do a small (api) data request per page, faster page transitions, a more interactive experience.

Just think of the site generator as a static api backend for the the JS frontend.

Why not just have HTML generated at some earlier time? It's faster, can be cached, and does the same thing.

I'm a little confused about no page transitions. I don't know why that is a problem that needs solving. Also hot reloading.

It comes down to user experience. There's a categorical difference between having to do regular transitions and full-page reloads, and no page transitions and hot reloading. The latter is more overhead from an initial bandwidth and processing perspective, but results in zero-latency interactions, which can be important.

Is a JS framework the best way to achieve that? Maybe, maybe not. There are many factors to consider. I just don't think it's a matter of "this isn't a problem that needs solving."

> It comes down to user experience

Indeed, it does. My experience visiting SPAs is frankly one of annoyance. Somehow, with 32GB of memory, dual SSDs and an i7 extreme processor, the browser grinds to a crawl with at least 1 CPU core maxed out for however long it takes for the extraneous (to me) transition/effect to complete. As a side effect the CPU fan kicks in for my auditory pleasure.

Compare that to a traditional web page where the browser only needs to handle a small fragment of html after initial page load, which typically makes for blazing fast page transitions, indistinguishable from SPA transitions.

I get the benefit of offloading work to the client when scalability is an issue, but for a static blog site? Not so much, I'd say using React in this case is less about the user experience and more about the developer's.

> My experience visiting SPAs is frankly one of annoyance.

I will echo this. SPAs can be great when done well, but my experience with them as a user suggests they're easy to do poorly.

I agree with you. Plus, if you use Cloudflare, your server may not even take the burden of the request. They will do the caching of static content for you.

I dunno...

Reloading 10K of (likely cached in memory and compressed by server) HTML to load a new page of HTML when a user clicks a link, with a browser that respects caching headers and so doesn't bother reloading content supporting images/UI element sprite sheets/CSS/JavaScript is never the wrong thing to do with "static" sites. In many cases, it's the most right.

Having React on a static blog makes it easier to share component libraries that you've built up on other projects (perhaps SPAs) with said static blog.

It also allows the use of React's ecosystem, such as react-helmet[0], which makes it easier to change the meta tags and title on the page when rendering.

[0]: https://github.com/nfl/react-helmet

...which can be done with YAML frontmatter on a markdown file in other static site generator, simply referencing the frontmatter in the layout partial that you have wrapping every page anyway.

Right, except support for that has to be built into the static site generator you're using. In the React case, the user can choose how they want to do it without the SSG author caring at all. I will also say that in the case of frontmatter, react-helment is a far more powerful solution which allows defining at any point in the tree, not just a layout partial.

In addition, the React way allows you a full language to handle import/export for "templates" instead of relying on a hampered template language/partials implementation.

The key here isn't the specific instance of frontmatter, it's having the flexibility to use everything one might use to build a SPA to target static sites. This re-use of existing solutions and skills is important.