reducing complexity is important but is hardly the fundamental reason to choose between server side or client side rendering or state management. that just depends on the nature of the problem and the context it has to be solved in. sometimes it doesn't matter, then you have a choice.
you guys are furiously arguing (and not really listening) about this or that hammer being good enough to treat every problem as a nail, like ssr was the "holy hammer". well, it isn't and not every problem is a nail, and while datastar looks excellent to me i simply would have no use for it if i needed client side logic or state for whatever reason.
I agree, but the kicker is that most websites can be server side rendered trivially. Most web "apps" are not applications. They are forms and pages.
The client side logic is, usually, just to make the developers happy because developers love complexity.
Obviously there are many exceptions. But not every application is exceptional. We all hate to admit we're working on simple or trivial things but... We are. Often.
Why? What's stopping you putting some state on the client with datastar. Just because it's discouraged doesn't mean you can't.
It has a whole client side signal system.
interesting! i wasn't aware of that, thanks for pointing it out.
to be clear, my point was that where the state has to be managed is more often than not an architectural decision given by the requirements, and the choice of tools should be a consequence of that, not a precondition.