As an old-school web guy, I am kinda astonished at some of the new React-only devs I run into. I'm the dumbest programmer in the world and these guys can run circles around me when it comes to anything webapp. But then sometimes they get lost with the most seemingly basic HTML or CSS related question.<p>It's like watching someone masterfully use an excavator, but then seeing them use that same excavator to hang an Ikea picture frame on a wall because they don't know how to use a hammer.
I agree that React (or anything like it) is not the right choice for static content [0]. Islands are great too.<p>I disagree that React is fundamentally bad. React (et al) probably should not be used in 80% of the cases it is being used for, but it is plenty fast for 80% of cases it is reasonable to use. And yes, I read the author's links on the topic.<p>What I found to slow SPA type things (mostly built in React due to its popularity) to a crawl are ~bad~ terrible choices for UI libs, several (!) tracking libraries, badly loaded 3rd party assets, unoptimised images, ads, not using URLs properly, and a cascade of API calls. All of which independent of React, but much of it affordances of client-side fuckery.<p>0 - The idea to set up an entire stack and everything that comes with it to render a hand full of paragraphs borders on lunacy. It is equally insane to wire up a dozen services and as many databases to manage a hand full of entities for a dozen users. I have come to terms with the fact that all software is fundamentally broken and everybody involved (including myself) has been infested with brain worms. The Butlerian Jihad can't come soon enough.
the biggest thing is native html is a pain to make non-trivial websites with. JSX, via react, provides a nice modular abstraction layer that easier to write and manage vs a blob of html and raw js files.<p>Of course if web components, I haven't really looked into them, provide a similar level of abstraction, thats great. If not people will end up (mis)using React and co because it's easier from a developer experience point of view.<p>There are alternatives of course. Astro [1] produces native, static html from JSX. Deno has Fresh [2], which offers a similar thing in the Deno ecosystem. Next.js [3] has static html option, but last time I tried it, it wasn't as nice as Astro or Fresh in this particular area.<p>[1]: <a href="https://astro.build/" rel="nofollow">https://astro.build/</a>
[2]: <a href="https://fresh.deno.dev/" rel="nofollow">https://fresh.deno.dev/</a>
[3]: <a href="https://nextjs.org/" rel="nofollow">https://nextjs.org/</a>
The phrases <i>actively harmful</i> and <i>considered harmful</i> in tech writing have become hyperbolic and should be retired. They no longer mean anything.<p>It would make sense if <i>suboptimal</i> or another word was used instead. But it wasn't and the end result makes it appear as though there is a harmful risk when in fact there is none.
All for being simple, I often write websites by hand in html if it makes sense. But the author doesn't know what they're talking about and using any of the major React based static site generators or frameworks is a perfectly valid and incredibly performant option for building a static website that gives you prefetching, image pipelines, the ability to progressively add in dynamic local first features later and other beneficial things that would be time consuming to do by hand.
"If you don't need javascript you're making things complex and slow. Therefore everything about React is bad. I offer no alternatives for the actual use case." is a pretty nuclear take.
I'd like to think that Kernighan and Ritchie chose their iconic first example (the static greeting "hello, world") as an homage to the simplicity of constant data.