[Aeolos]

I highly recommend everyone to give htmx or datastar a try, especially if your main experience is react or nextjs.

We recently rewrote a half-million LOC codebase from react to datastar, with a detour through htmx first, and the results are staggering.

First page load is 20KB down from a 750KB js bundle. 1 network request vs 40+. Total load time 0.1 seconds down from 2 seconds of spinners. Page refresh is so fast, the browser doesn’t even flash - there’s no massive js bundle to parse, so it can start rendering instantly.

But the most staggering result is that in-document navigation over SSE achieves up to 5000:1 compression ratio for network requests within the Brotli compression window. Yes, 5000:1, you read that right. When changing server state we rerender the entire page, like an immediate-mode game engine, and push it to the client over an SSE “fat morph”, in about 100 bytes.

It’s so fast and so much more stable, our users are literally having fun. With a medical device.

And this ends up ~50% less code to maintain for a VASTLY superior UIX.

You are really missing out if you don’t learn how this works. It can give you a significant competitive edge if you care enough to try.

Edit: Big BIG thanks to bigskysoftware and the datastar team for making the web a sane place again. You really deserve all the props.

[andersmurphy]

My experience was similar. I'd wound down a startup and as a solo developer could no longer afford to do react + a backend. So I tried HTMX, then turbo (which introduced me to morph and push based re-fetch). Finally moved to datastar because I could drop alpine and it has best in class morph, signals and SSE support. Immediate mode over the network is amazing DX.

Makes multiplayer out of the box over large datasets trivial. See these demos if you don't believe me [1][2] (open them in multiple tabs and have fun)

[1] https://checkboxes.andersmurphy.com

[2] https://example.andersmurphy.com

[bramhaag]

Since you tried both, what made you choose datastar over htmx?

[Aeolos]

Our UI is highly interactive: think 3d visualizations with toggle-able overlays, various display settings, searchable lists, drawing tools etc.

We made a lot of progress with htmx, but eventually hit a complexity wall where we were spending more time fighting the tool than solving the business need. Note, I'm not blaming htmx here, the documentation is clear about its strengths and limitations, and the hypermedia approach is still fundamentally right. But even with alpinejs in the mix, we just weren't able to achieve the smooth developer experience we were looking for.

So we tried datastar, and it basically addressed all the friction points we had:

  - No more DOM hunting to figure out why the hx-get ended up in the wrong spot or why OOB swap is glitching out. D* morph just works.
  - No need for hidden form <input> to submit client state, D* signals are cleaner and easier to use.
  - No more micro-routes for targeted element updates to avoid hx-swap butchering page state. One route per page, just render the whole thing and morph takes care of the rest. Immediate-mode rendering and fat morphs removed ~50% of our routing table.
  - SSE + fat morph is a superpower. This is view = f(state) done right.

We've had very few issues, D* just works and gets out your way. The team has really created something quite exceptional.

The great news is htmx4 is adopting many of these ideas, so I recommend trying both and seeing what fits you best.

[andersmurphy]

It's nice to see HTMX4 is adopting the core strengths of Datastar. That sort of cross pollination of ideas is a huge boon to the wider hypermedia community in general.

[sudodevnull]

HTMX v4 doesn't actually address what's makes Datastar work at it's core. It at best it copies some of the broad strokes of the API but not in a robust it efficient spec compliant way

[andersmurphy]

A focus on morph by default means you don't have an explosion of endpoints and can write programs like the 300 redirect days. [1]

Once you want realtime/collaborative app SSE + morph lets you do that easily. Add streaming compression and this approach is suddenly crazy bandwidth efficient.

For people coming from react this gives you v = f(state) over the wire.

Lastly signals handle the edge cases where an out of bound morph would nuke your ephemeral client side state (mostly text input).

You can do this in htmx but you are fighting the design the whole way. Turbo is a bit better but doesn't have signals.

[1] https://dev.37signals.com/a-happier-happy-path-in-turbo-with...

[JSR_FDED]

I’m getting about 800:1 compression with Brotli. I wonder if need to tune anything? Although tbh I have no performance issues at all.

It took me a minute to change my mindset to Datastar’s way of doing things. But it’s been amazing. Firstly to keep 99% of the state and logic on the back end is just so nice - no more having to deal with two sources of state at the same time (front end and back end). Secondly the ability to regenerate the entire view from scratch anytime something changes and then have Datastar efficiently morph just the changes is just such a simple mental model. Every fiber in me was like “no way that can work, the cpu, bandwidth, latency etc” - but it is buttery smooth.

[andersmurphy]

So compression ratios with streaming compression (brotli/zstd) come down to the regularity of the data, the size of the change, and the size of your window.

Basically, if your html fat morph frames are 65kb uncompressed and you make a small change like checkbox it will send 13bytes so that's 5000:1. Caveat is as long as your compression context window is big enough.

[halfcat]

How do you debug SSE messages since they don’t show up in chrome dev tools with Datastar?

[Aeolos]

You either buy a datastar license to get their debug tools, or you spend a couple of hours to build your own. I'm sure you can find something on GitHub too.

One of the cool things is how extensible d* is. Everything is a plugin, and you are free to extend it to suite your needs. We've invested a few days building a few specific data-* attributes for our application and it's super convenient.