[leojfc]

Thanks for writing this up — some great insights!

The server deciding what to replace reminds me of some old (dangerous, I think) patterns like returning actual JS from the server which the client then executes.

But it was a nice pattern to work with: for example if you made code changes you often got hot-reloading ‘for free’ because the client can just query the server again. And it was by definition infinitely flexible.

I’d be interested to hear from anyone with experience of both Datastar and Hotwire. Hotwire always seemed very similar to HTMX to me, but on reflection it’s arguably closer to Datastar because the target is denoted by the server. I’ve only used Hotwire for anything significant, and I’m considering rewriting the messy React app I’ve inherited using one of these, so it’s always useful to hear from others about how things pan out working at scale.

[naasking]

> The server deciding what to replace reminds me of some old (dangerous, I think) patterns like returning actual JS from the server which the client then executes.

Basically every single web page on the modern web has the server returning JS that the client then executes. I think you should clarify what's dangerous about the specific pattern you're thinking of that isn't already intrinsic to the web as a whole.

[cassiogo]

I like Hotwire but I admit its a bit confusing to get started with and the docs dont help. Form submits + redirects are a bit weird, you cant really make the server "break out" of a frame during a redirect if the form was submitted from inside a frame (there are workarounds, see https://github.com/hotwired/turbo/issues/257).

Also, custom actions [https://turbo.hotwired.dev/handbook/streams#custom-actions] are super powerfull, we use it to emmit browser events, update dom classes and attributes and so on, just be careful not to overuse it.