Datastar is going to be my default pick for web technology going forward

Blog Post 5 posted: 2025-11-04

After spending the lat week getting to grips with datastar, I have come to realize that this is the tool/approach I wish I had learned when I was learning web fundamentals more than a decade ago. Part of it is that datastar enables a primarily systems and backend developer (like myself) to have the fancy full featured webapps of the web without having to go through a million hoops of the Javascript framework ecosystem (it's basically react all over now).

The big part of it is how it really just simplifies workflows, it gives you (almost) all the power of react, with no "hydration", no state untangling, no need for an API data layer (and all the associated churn included). It's just hypermedia on whatever you like (in my case, templ is what I like). It also largely solves the security considerations since everything that matters for the state is set and adjusted on the server.

I had two big realizations that helped me to figure out the key points of reactive state.

1. PatchElement should be preferred over PatchSignal
2. When in doubt, just load the whole page (rather than trying to diff things).

The reality is that the framework is made for easily and quickly patching the DOM in a smart fashion. You can send as much or as little HTML in the response and you need and it will work. If you send the full page, so long as the element IDs are consistent (trivial with well composed templates) it can diff. If you send the fragments to the right IDs, it will also replace them correctly.

Signals, on the otherhand, for as incredibly powerful as they are, are something that can be easily abused if one is not cautious. Signals themselves can be driven by the client and the server for updating the client state. I think that it can lead to some.... poor performance and such if signals are overused. Signals are intentionally a front-end global state and intended to have all of them sent to the server with every datastar request. This means that there's a high potential for namespace issues as well as a problem of needing to maintain the state in your head. Additionally, it can get you into a tightly coupled mess similar to SPA frameworks being heavily reliant on JSON RPC.

Rather than using signals as a kind of global JSON RPC, these signals are -- in my opinion -- better used almost exlusively on the frontend for small islands of frontend heavily reactive state.

For example, in my project related to AI, I had to break my brain trying to get certain attributes to be set based on a signal, when -- if I were to rearchitect it -- I would just add an ID to the button and replace it each time with a separate templ template (probably just parameterizing the button itself).

I know that I wrote in my readme on this site that I was planning to add HTMX and Alpine, but I think I'm just going to embrace the datastar way and proceed with using it for all my web projects going forward. It just makes the web so much fun and is so easy to get all the power of react/dioxsys with none of the headache and boilerplate.

If you haven't tried out Datastar, you honestly owe it to yourself to give it a shot. So far, it is up there as my favorite approach to building for the web with the hypermedia approach.