You're arguing with an imaginary straw man. Is someone credible in the React community saying everything should be be done in React?

There aren't many people in the React community who are explicitly arguing that everything should be React. But there seem to be very few things that the React community believes are a poor fit for React.

Take addons.mozilla.org. It's a simple, tiny website with a list of browser addons and a button to download each one. Perfect fit for server-rendered HTML, right? Nah, front-end developers rewrote it in React. [1]

Or blogs. Blogs are just a collection of text pages with occasional images and links. Surely you should use static HTML for those, right? Well, okay, but only for the initial page load; after that, make sure you let React take over so it can "improve" your page navigation. [2]

[1] https://blog.mozilla.org/addons/2017/10/25/test-new-look-add...

[2] https://www.gatsbyjs.org/blog/2017-07-19-creating-a-blog-wit...

You put "improve" in quotes as if instant page navigation without flickering is somehow worse than the alternative. Browse around this [1] website and tell me it is not a better experience than your bog-standard html + vanilla js concoction. Also every time this is brought up the developer/content editor experience is entirely neglected, when in reality it is a big consideration when creating something other than your own dev-blog that you update once a year.

[1] https://reactjs.org

I tried the site you linked on my phone. It is not a better experience than a standard HTML site:

1. The Back button had a noticable half-second lag.

2. When I temporarily lost connection and a link I clicked was taking a long time to load, I wasn't given the option to stop loading it like I am when I click a normal link.

I tried disabling JavaScript like a sibling comment suggested, and the website was indeed faster and still flicker-free. (Where do front-end devs get this idea that you need tons of JavaScript to do flicker-free page navigation? Have they never used Hacker News?) But then I wasn't able to see the interactive code examples on the homepage, because those genuinely needed JS to work.

This is because disabling JavaScript is an all-or-nothing proposition. There's no "throw out bathwater but not baby" button or "allow JavaScript only for things it should actually be used for, and not clumsily reimplementing browser features while forgetting half the edge-cases" toggle-switch.

> You put "improve" in quotes as if instant page navigation without flickering is somehow worse than the alternative.

Yes, instant page navigation without flickering is better than the alternative - instant being what you get from reloading a static HTML page, alternative being React.

Seriously, fetching, parsing and displaying a tiny bit of HTML is fast. As fast or faster than the React virtual DOM shenanigans, once you account for the computational load the framework adds on top of your simple page.

Real life is not code golf. We do not build things entirely for ourselves. We build things for our employers, for our co-workers, for our family members and for our friends. We build to create value for someone and value is not a one-to-one correlation with the weight of a site in KB.

If I can make it easier for me and anyone working with my site in the future by sacrificing 50-150 KB then I will take that deal any day of the week. That is what abstractions are for. That is why we do not work in byte-code. We pay for convenience in clock-cycles and disk space.

Arguably, using React where a static HTML with maybe a little bit of vanilla JS would do, is code golf.

HTML and CSS are not bytecode. They're high-level abstractions, hiding a very complex renderer underneath. Sometimes you need to build another tower of abstractions when this doesn't suffice - like when you're trying to build an application with complex GUI in the browser and you need an adapter between DOM and a more suitable GUI pattern. But displaying text and images communicating a message is not one of those cases.

We do not rebuild the tower of abstractions for every site that uses them. I do not personally implement React from scratch when I use it for any of my sites. I get all of the benefits for none of the effort. You do not seem to acknowledge factors other than straight up performance, as is evident by what you are picking and choosing from my comments, so obviously it is not attractive to you.

It seems to work fine under umatrix set to "kill everything but first-party images and css".

Perfect! So we can have the DX of React with no downside for you. Win-win, right?

Wouldn't it be easier to just use a static site generator for a simple site like this, though?

It is built on a static site generator based on React, it's called GatsbyJS.

Sorry then, I guess I have no idea what this discussion was about in the first place. Why would anyone care about the build tools of someone else's site if it doesn't affect the user?

They shouldn't, but they do.

There is no clear line between "what can be obviously done with vanilla HTML/CSS" and "that problem definitely needs React". So, most people opt for something like React to enable the capability, in case they need it. There's nobody purely saying that 100% of everything should be in React, but that's effectively the outcome.