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.
This is awesome. Having a single state for all resources in an environment is critical for keeping all the moving pieces in check and a core design aspect of Kubestack. But the growing state files quickly become a bottleneck. I'm definitely giving this a good test drive. Very excited.
I'm working on an application and use Fiber, Templ and Datastar to keep my frontend in Go, like my backend. I'm overall quite happy with this approach.
But Datastar tries to do both, AlpineJS stuff like show/hide dropdow options, as well as HTMX stuff like talk to backend and merge/replace parts of the DOM.
I came across TemplUI a few times while working on this app so far. But always felt the Vanilla JS plus HTMX approach of TemplUI conflicts with Datastar. Too much overlap in different components doing the same stuff for my taste. While at the same time, I spent way too much time converting Tailwind UI components into Tempo. Time I could spend better.
Datastar is quite on the experimental/unstable side of things. And its concept of signals doesn't quite work for my Kubernetes style API resources. So maybe I need to revisit this decision at some point.
What I really like about Datastar and what made me choose it in the first place is how easy it makes using server sent events.
So yeah, exciting times. Still some rough edges I would say. But for me personally I already prefer hypermedia over the predominant React frontends approach.
We've got some overlap on the stack part. But I am more focused on the infra side of platform engineering (including bootstrapping clusters), seems for you it's more app dependencies. Check https://www.kubestack.com and ping me if you're interested in chatting.
But if you create a configmap to store that label isn't that state? It may be more lightweight than what Terraform or Helm store, but it's still state.
Yes, conditionals and loops in TF are limited and have various annoying and surprising edge cases. But if something is hard to do with the Terraform DSL it's usually a good idea to reconsider if it is really something that one should be doing.
We want infrastructure automation to be boring and just work.
The risk with general purpose programming languages is that people will always find a way to outsmart themselves. Yes, sure, you can use the testing tool chain of the language of your choosing. But it's not like we have figured out to write software without bugs, despite all the awesomeness of modern languages.
It's not trivial to get the labels correct to avoid collateral deletions. Also, while it makes sense, I and many teams I consulted with found it rather unintuitive that apply --purge with a label selector will also only update resources with the label. Not all resources that are in the list of resources. Last time I checked it was also still marked experimental and has been for years.
Keeping the tombstones around in the configuration I have to maintain instead of the state the tool maintains for me also increases the effort for me though. So either I have the effort of setting up the remote state and handling some edge cases. Or handling the shortcomings of stateless in my own code base.
Yes, but setting up and handling edge cases of Terraform state causes the effort. Once you have it, storing just IDs or more doesn't make a difference anymore.
This doesn't work unless your infrastructure is entirely static. As soon as you have active control loops like e.g. an autoscaler it will create resources that you don't know about and would then delete.
The delete this approach is imperative though. If you aim to be declarative you need a way for the tool to be able to determine actions necessary to go from current to new desired configuration. You need to store previous applied config somewhere, to be able to determine if something needs purging in a declarative way.
I maintain a Terraform provider for Kubernetes. And one of the main reasons for that is because the Terraform state ensures purging of deleted resources.
Something that kubectl is not capable of. The lastAppliedConfig annotation does not help for purging, because once the manifest has been deleted on disk, there is no way of knowing what to delete from the server. The unusable apply --purge flag is the best example of this issue
I think the state mainly exist to know what has been created in the past but since been deleted from manifests and therefore needs to be purged. The caching/performance argument is rather weak, because Terraform refreshes by default anyway before any operation.