off-topic 2026-09-01

I've been using HTMX with a little bit of Alpine.js during the last few months and been having lots of fun. I haven't tried Datastar yet, but have seen Anders Murphy's https://andersmurphy.com/2025/04/07/clojure-realtime-collaborative-web-apps-without-clojurescript.html. I like how it handles some JS stuff you'd need Alpine or Vanilla JS for. Datastar also features a pixel art drawing of David Nolen on its frontpage — a big selling point. on the other hand, I don't love how view-transition and query-string helpers are on the pro tier. another thing that puts me off slightly is that it has an SDK. iirc that's mostly helpers to facilitate the SSE machinery, but I like how simpler HTMX is in comparison. has anyone here evaluated both and feel like sharing findings?

❤️ 1
José Javier Blanco Rivero 2026-09-01T00:30:20.327899Z

I was also a bit put off by datastar Clojure SDK, but I found https://github.com/brianium/datastar.wow easier. But yes, starting with htmx feels smoother. Still I need to explore both more seriously and I believe is worth the effort

I have also noted • https://github.com/andersmurphy/hyperlithhttps://github.com/dynamic-alpha/hyper/tree/main which are other options on top of Datastar

htmx 4 is out now too which includes things like signals maybe? (I only superficially heard that htmx 4 is like datastar but maybe only a bit less than that?) Don't be intimidated by the word SDK, for Datastar you can totally just write your own thing, it only needs 2 endpoints I believe that you can just write yourself

I was looking at the what's new page and I think the signals-like thing is hx-live: https://four.htmx.org/extensions/hx-live https://four.htmx.org/docs/whats-new-in-htmx-4

Iirc htmx 4 also has some basic state management stuff that's intended as a built-in alternative to alpine

yeah, I think that's hx-live

yo, its D* guy... i've been summoned... i'll answer all this in the #C0AAPB59G6T chan

2

It's nothing like HTMX in practice. I'd add if you're comparing the two/undecided then probably stick with HTMX.

to be clear, @andersmurphy wants to keep his cosmic powers to himself

😁 1

Same way I don't recommend clojure.

😂 2
☝️ 1

Why use Clojure over Python? Is not a conversation I would have. I'd say keep using Python.

If you value of FP and immutability then clojure is the obvious choice over Python. Datastar, same thing, if you value state on the server, streaming, CQS, push and immediate mode. Then Datastar is the obvious choice over HTMX. If you don't value those things, or don't know why you should, then stick with HTMX. Unless you want to spend time learning why those things might be valuable (same way with clojure you had to spend time learning about the value of FP and immutability).

i totally get the D* is just HTMX+Alpine vibe. its not, but i get why people say that. i will warn that the internal is htmx4 are gonna mean that mostly will see a htmx8. so just depends on what's important to your project

About view-transition and query-string helpers etc, might be useful to check out https://github.com/dataSPA/dataSPA too which has MIT alternative versions of some Datastar Pro features. Recently, I used LLM on Phel WP plugin project to generate the required JS for syncing state with query string and to make some simple view transitions work. It is not that complicated with a narrow case. SDK is also a bit useless, though can be a useful tutorial/reference to get started with.

👍 1
☝️ 1

Yeah I only implement one function and I don't use the SDK. But, the SDK is still a great reference for some of the things you might want to implement on the backend like compression.

👍 1

> i totally get the D* is just HTMX+Alpine vibe. its not, but i get why people say that. I'm aware it's a different beast! but the comparison is right there at the https://data-star.dev/guide/getting_started :) > Datastar provides backend reactivity like https://htmx.org/ and frontend reactivity like https://alpinejs.dev/ in a lightweight frontend framework that doesn’t require any npm packages or other dependencies > i will warn that the internal is htmx4 are gonna mean that mostly will see a htmx8 I don't get this part. do you mean that the fact that HTMX released a new major with a bigger API surface means they're likely to switch things up again?

without getting into stuff you likely don't care about. D* has a tiny core ~3kb. part of that is making reactive expressions. much like you can't bolt on homoiconicity later, D* is built around everything being a plugin from that reactive core. HTMX does things very differntly and bolts on stuff with extensions, but you can never remove stuff. SSE, pro stuff, etc can be swapped out no problem in D*. Kinda like the immutable layer of Clojure, if you take that away its a different lang and your code is 100% different. Datastar has made choice to make the web more declarative and shim just the tiny parts needed for now.

And... @delaneygillilan is right here whereas the htmx author is not... that's an easy choice then right? :P

💯 2
🫂 1

and don't forget the pixel art David Nolen

being serious now, that's a very useful framing. thanks for the context, @delaneygillilan!

🚀 1

i mean i'm a weird beast. i'm happy to help but my decision making is based off of metrics, flamegraphs, and living within the spec of the platforms I use. Happy to answer any questions and explain in detail any decision. Most of them are how to never have a v2 if possible and be so fast that it's never the issue. If I can solve web dev then I can get back to the real issues

like stealing all the good ideas from people like @borkdude

😆 1
😅 1

One thing I worry about with datastar is that while the model is beautiful, there can be problems that show up later in prod if you are not careful. E.g., wouldn't it be pretty easy to make something that works on your laptop, but then chokes in prod because you didn't think about non-sticky load balancing, where the state lives, etc.?

we've tested out to 40k connection per core on your server. i pretty sure we've done more analyse than any framework i know of. but never trust numbers, you have to measure yourself.

@isak you have to get into specifics about exactly what the issue you are concerned with.

you don't have to think about sticky load balancing at all (in the way most of us use datastar). its not a websocket

excuse the self promotion but https://www.youtube.com/watch?v=W7Ki3aXgmZU really is my attempt to explain it once and for all

🔥 1

@delaneygillilan just finished the video. Very cool, I see it has a lot of things I didn’t know about, like the expressions you can do client side, so my fear about state may be unfounded. I’ll give this a try for sure. Thanks!

🚀 1

np, hope it helps!

I don't get this part. do you mean that the fact that HTMX released a new major with a bigger API surface means they're likely to switch things up again?
HTMX 4 is full of breaking changes. You can't just upgrade from HTMX 2. That's the difference.

The Clojure solution to that is to just rename your project

💯 3
😂 1

Unless your goal is to have no-one use your thing (see hyperlith). 😂

🐈 1

yeah you can say please don't use this, but we all know what happens next

They pay you millions to stop changing it?

you discover that people are using it and won't change it anymore, although it has all the red flags of being called alpha, that's at least my experience ;)

💯 1
🧠 1

@isak yeah that's where SSE is a big win over websokets. Also why you keep state in the database projection.

✍️ 1

@borkdude yup. But, if you're lucky this Borkguy comes along and makes a better version that you can use instead and don't have to maintain. 🧠

Open source is just an attempt to nerd snipe you into building things we need. Which reminds me I need to bump up my borksponsorship. 😂

babshka FFI is chef_kiss

❤️ 5