Datastar: Lightweight hypermedia framework for building interactive web apps

I think it was probably the copycat/followup effect rather than anything coordinated, but I haven't looked closely.

Trying to decide whether to merge the threads and/or which of them should 'win'...

"Frontend" is a huge field.

Some people write their own websites where they blog (where Wordpress would be enough), some build shops with mostly static content that has to load fast but has no real interactivity, others build full-fledged software like Figma/Discord and for the true masters, the DOM is a prison and only coupled with GPU-accelerated computations will do.

Obviously htmx and it's siblings are nice for blogs, docs and shops. You don't build a "software" level website with it.

> Not sure why the community is being so hostile

I cannot speak for other people, but here is where I'm coming from:

- There is no mention of Pro on the home page, I only found out about Pro after flipping through the documentation. This comes off as sleazy, like "Look at our cool open-source project", and then after they have you hooked they go "oh, if you want all all of it you gotta get Pro". - Pro is locking genuine features, not just support, video tutorials or code examples. - It is vendor lock-in, if you want to rely on any Pro feature you are now at the mercy of the maintainers. - What make the vendor lock-in particularly problematic is the fact that without Datastar your website will not work. Sure, it does suck if your CI service, test platform or whatever does not work, but as long as you can compile and deploy the code you will survive, even if you have to do it by hand. Not so with a library. - There are no examples of what your are buying. At least with the non-Pro features you can try them out for free without any commitment, but when it comes to Pro you are just taking a blind guess as to whether any of them are what you want. Compare that to the Pro examples Alpine has[1], where you can play around with them in the browser. - I don't know if you get source code, but even if you do you cannot share your improvements with anyone.

Note that I never mentioned the price. The value will vary from person to person, for some it will be unaffordable, for others it will be a great deal (e.g. freelancers who will make the money back within one gig). I got my employer to sponsor Alpine a year ago and they have given more to Alpine than what Datastar are charging for Pro.

For reference, two projects which have non-objectionable Pro versions are Alpine.js[2] and React Flow[3]. React flow even have a link to their Pro page right on the home page.

[1] https://alpinejs.dev/components [2] https://alpinejs.dev/components [3] https://reactflow.dev/pro

You should probably update your comment to at least let people know this is a one-time lifetime cost. Not a subscription.

Which is priced similar to Tailwind UI, which people are fine paying for.

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.