This has got to be one of the most stupid comments I've read this week. This is a page with random lazy-loaded images splattered all around, the load and render time difference if this used React would be not more than 10 milliseconds.
On the other hand, since the typical (!) React site has no fallbacks whatsoever for noscript, even though a specific HTML tag exists for this very purpose, the React site stays a white page, one can wait an arbitrarily long time and it still won't work or change, and the browser tab gets closed.
I'll avoid getting into the whole discussion about people on slow connections, accessibility, etc., as I get the impression you really don't care about them, and just point out the obvious fact that everyone has JavaScript disabled whilst your JavaScript is downloading.
You'll avoid it, because you don't have any valid arguments.
Slow connections are not a problem, because React is ~40KB and Preact is ~3KB. If downloading 3KB is too much for your network, it's not the fault of React, JavaScript or any web developer that you're gonna miss out. Also, server-rendered HTML would NOT be smaller than 3kB - in fact it would require MUCH more bandwidth since server-rendered HTML can't be cached as easily, so every page will re-transfer the exact same HTML for shared things like navigation bars, footers, etc.!
Accessibility isn't any issue either, this is a ridiculous argument to even try to make, accessibility tools use HTML and are fully aware of the existence of JavaScript - React doesn't magically bypass HTML to display something on the page.
> everyone has JavaScript disabled whilst your JavaScript is downloading
Everyone has HTML disabled whilst your HTML is downloading.
Since we are talking about _typical_ React sites, accessibility is immediately out of the window, when it only renders a white page. Even if it renders a proper page and even if one allows its JS to run, accessibility is usually still not even an afterthought, because the typical React page breaks back and forth buttons and standard browser functionality. The typical React app also will use some "components" thingy, instead of standard HTML form elements, and in the process makeing a complete mess of the DOM, so accessibility is also out there.
The number of things this paradigm breaks, only to then have to fix them again, but this time by implementing them in JS partially correctly is just too high, for the average web dev to manage on the short time budget they get assigned in their day to day scrum managed job, where new feature requests and KPIs are more important than actual usability of their pages, and few people even properly test on multiple browsers, let alone screen readers and the noscript situation. It is just too tempting for them to use some component "someone else already made" "do not reinvent the wheel" etc., while constantly being discouraged to spend more time on making things actually work well.
Streaming HTML and Transfer-Encoding: chunked have existed since 1999 at least. I don't actually care about this argument one way or the other, but you can continue updating the site with HTML/CSS indefinitely, zero js required, simply by never completing page load.
I think the complaint is mainly about the failure mode. I guess it would be trivial to use the noscript tag to display a message saying JavaScript is required, instead of showing a blank page that keeps loading.