I've been building a frontend with Go, Templ and Datastar for a few months now. I really like the @actions and how the page is updated with the response.

I'm on the fence about signals though. They are fine for simple things like individual text form fields or opening closing a drop-down. But my backend is a Kubernetes style API server. And storing a JSON Kubernetes style resource in a signal does not work because of how Datastar implements parsing the structure into child signals. For me it would be better to just be able to turn this off.

One example where it breaks are K8s labels. They are map[string]string and the key is often hostname prefixed. E.g. example.com/label-key. Datastar can't handle these keys at all and the resulting signals are a mess.

I'm aware that I may be using signals not as intended. But something as simple as data-signals-resource="k8sJson" and then data-bind="resource.metatdata.name" is a great way to work. And it works for metadata name. But it doesn't work if any part of the path needs to be an index in a list or a label key in hostname style.

The other thing I find painful about Datastar signals are the magic about how attributes written something-something in HTML become somethingSomething in JS and all all the snake, camel etc. __modifiers. It's just error prone to work with. Not a great experience.

But overall I still stuck with it so far and am happy with the general idea of HTMX and Alpine functionalities implemented as one and using hypermedia as a general approach. Anything so I can avoid the NodeJS ecosystem really.

When a few RCs back the wire format changed, it was quite a laborious update for me, because using Fiber I can't use the Go SDK and implemented my own. But the wire format clearly changed for the better so it was worth it.

I think the developers are on to something and should keep iterating.