[xcrunner529]

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.

[terandle]

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/

[recursivedoubts]

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/

[terandle]

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.

[lakomen]

It's a big step back