If I understand the code for these correctly though, you're not actually doing the "idiomatic" datastar things as the article describes? No diffing/patching individual elements, just rerender the entire page?
Tbh that mental model seems so much simpler than any or all of the other datastar examples I see with convoluted client state tracking from the server.
Would you build complex apps this way as well? I'd assume this simple approach only works because the UI being rendered is also relatively simple. Is there any content I can read around doing this "immediate mode" approach when the user is navigating across very different pages with possibly complicated widget states needing to be tracked to rerender correctly?
I mean Datastar is pretty flexible. I'd say CQRS is pretty idiomatic if you want to do multiplayer/realtime stuff. As you mentioned, once you've se that up, the mental model is much simpler. That being said the initial set up is more involved than req/response Datastar.
Yes we are building complex accounting software at work with Datastar and use the same model. "Real UI" is often more complex, but a lot less heavy less divs, less data, fewer concurrent users, etc compared to these demos. Checkboxes are a lot more div dense than a list of rows for example.
Tbh that mental model seems so much simpler than any or all of the other datastar examples I see with convoluted client state tracking from the server.
Would you build complex apps this way as well? I'd assume this simple approach only works because the UI being rendered is also relatively simple. Is there any content I can read around doing this "immediate mode" approach when the user is navigating across very different pages with possibly complicated widget states needing to be tracked to rerender correctly?