Yes but in 6 months react will release a compiler to catch it up by a lot. Performance has diminishing returns and at some point, things just need to be fast enough (see vscode) and the industry will continue on as the switching cost is way too high.

True. But if the sites performed well (big if) and feel responsive, look nice, don’t break middle click and other browser functions - well I don’t see the problem, then. I don’t think the “hate” is irrational.

Which is why I think react (and other SPA frameworks) are now pointing beginners to full stack frameworks like nextjs, remix etc where those best practices are baked in. It took the JS frameworks a bit to find their path there but I think they are there now.

What are your thoughts on things like HTMX though, which with a small payload allow lots of SPA-like features and part of the content language itself. The other hatred I have is the need for all of this crap on top of a crappy language.

It's a big step back

HTMX has a ceiling on how interactive/complex you can make your site [1]. If you know you will never need to exceed those sure. However I like to use nextjs as it gives me the peace of mind I will always be able to pivot or implement whatever the customer wants.

[1] https://htmx.org/essays/why-gumroad-didnt-choose-htmx/

that's true[1] but there is also the programmer dictum "You Aren't Gonna Need It" (YAGNI)[2]

it very much depends on the type of app you are building, but I think many web applications could at least start with htmx and then, when more complex user interactions present themselves, use an island of interactivity approach that localizes the complexity.

this keeps overall system complexity as low as possible for as long as possible, and you may never need to go beyond htmx, which can lead to a much less complicated codebase [3]

[1] - https://htmx.org/essays/when-to-use-hypermedia/

[2] - https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

[3] - https://htmx.org/essays/a-real-world-react-to-htmx-port/

I think nextjs does lead to a very simple codebase at every step of the interactivity gradient. You can have pure server side rendered HTML all the way up to full blown SPA and everything inbetween with just one tool rather than having...

1. HTMX itself

2. Your backend language Go/Java/whatever

3. Whatever JS framework for your interactivity islands

But yes we are all on the same team here of reducing complexity in the codebase and if HTMX works for you go for it.