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.

Thank you, that is great to hear! We're pushing pretty hard to get a pre-alpha out to get some foundations testable by the community.

You're not wrong. They add miniscule value. But what does that say about the people using these images who are now struggling to replace them?

You can't have it both ways.

If their value-add was miniscule then they should be trivial to replace.

If it's a struggle to replace them then that's the value they were adding.

We also know the Sun is going to swallow the Earth and eventually burn up. That doesn't mean we stop building with what we have now.

Those to two very differently sized eventually's.

Packaging is not miniscule value, it's valuable gruntwork.

A lot of work that apparently is not valued enough to justify paying for.

You could make the same argument against Linux, openssl, ffmpeg, compression algorithms, web browsers and so many more things.

A select few will pay for the rest of us, but it's valuable to everyone who uses it.

Broadcom just wants to squeeze anyone who can't do it themselves.

I'm mixed... I've spent the time to create installers and docker images for a couple things, mostly because I wanted them to exist for myself, that others found them useful was a cool side effect. Nothing to the breadth or scope of Bitnami though.

That said, it seems to be a side effect of their business model that they don't feel they can offer for free, or otherwise choose not to in order to convince people to move. It seems there's nothing stopping someone from forking and/or continuing the packaging for apps they use based on where Bitnami is today. Cool.

I'd personally like to see a lot of these hardening efforts upstream anyway... separating base images for build vs. runtime and more so with the "official" app images themselves. People do and should have different expectations from a lot of applications when packaged in a container vs. installed on a system.

The problem isn't paying for it, it's the extra workload of retrofitting authentication to all your things. I'd find this a lot more enticing if they just made you set a "i have a license or i am evaluating or i am not commercial" flag in Helm or fail the build. Plus the cost is extremely disproportionate, but some will pay it given the one month deadline.

it doesn't say anything nice that "moderate inconvenience" is a "struggle"

Everything under internal did discourage me from trying templUI too. What's the reason for it?

Yeah, totally fair question.

Originally, I had templUI components available via Go module imports, but there were a few real issues:

- Tailwind v4+ with CSS-only config needs hardcoded paths to `.templ` files. That clashed in teams where Go paths differed (e.g. `~/dev`, `~/code`, etc.).

- It made Git diffs messy – you had `.templ` and `.go` files being imported per component.

- Updating components via module versions often led to unwanted breaking changes – not easy to "just use one component" from a newer version.

- Workarounds like Makefile tricks for Tailwind `src` path felt too hacky.

The CLI avoids all that. It copies clean files into your codebase, so it's portable, version-safe, and no import path magic needed.

That said – I’m open to feedback. If there's a solid reason to bring back module imports (optionally), I’m listening!

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.

But is the icon going to be a syringe, a pill or a tombstone?

Three cuboids (with a slightly larger cuboid off to the side).

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.

Giving teams more insights into their apps at runtime without requiring changes to the apps is as close as one gets to a superpower.

Agreed! I'm very happy to see that we are getting to the point where engineers that don't work at big tech companies can get these kind of insights, too.

It's funny, as someone proposing frameworks make sense in IaC (Terraform in my case), how the framework/no-framework topic apparently never gets old.

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.

Yeah there is definitly something to be said for having a limited DSL. I feel though the language as-is, has a bit to much dynamic features that kinda half work and then give you completly useless error messages. But tbf, it has gotten alot beter with recent versions.

But to explain where I'm coming fromm, this is something I ran into recently:

this breaks and returns null if http is not set: lookup(each.value.http, "port", 8080)

So I need to do this to make it work: coalesce(lookup(each.value.http, "port"), 8080)

Not a huge deal, but just one of these many things over the years where I think don't reinvent the wheel.

I want both config and code to be concise and clear. “Boring” means it’s unfinished and contains small mistakes that we miss when our eyes glaze over.