React is actively harmful if your website is static(gomakethings.com)
gomakethings.com
React is actively harmful if your website is static
https://gomakethings.com/harmful-complexity-using-react-for-static-content/
12 コメント
I agree that React (or anything like it) is not the right choice for static content [0]. Islands are great too.
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.
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.
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.
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.
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.
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.
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.
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.
[1]: https://astro.build/ [2]: https://fresh.deno.dev/ [3]: https://nextjs.org/
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.
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.
[1]: https://astro.build/ [2]: https://fresh.deno.dev/ [3]: https://nextjs.org/
The phrases actively harmful and considered harmful in tech writing have become hyperbolic and should be retired. They no longer mean anything.
It would make sense if suboptimal 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.
It would make sense if suboptimal 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.
They could merely be replaced with "I do not like" or "I prefer a different approach".
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.
React is fine. It can be abused just like anything else. This post brings nothing to the table.
"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 offer no alternatives for the actual use case."
The use case is static and mostly static websites. The article author suggested using manual HTML and CSS, alongside Web Components for the non-static JavaScript parts. Make of that what you will, but it's not "no alternatives".
The use case is static and mostly static websites. The article author suggested using manual HTML and CSS, alongside Web Components for the non-static JavaScript parts. Make of that what you will, but it's not "no alternatives".
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.
Thank god this man has one consulting slot available!
"My arrogance and small-world view is available for hire!"
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.