Rendered at 11:54:49 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Aeolos 5 hours ago [-]
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 5 hours ago [-]
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)
Since you tried both, what made you choose datastar over htmx?
Aeolos 1 hours ago [-]
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 35 minutes ago [-]
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 6 minutes ago [-]
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 5 hours ago [-]
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.
Nice, I really like this series, this made me really understand those web frameworks much better as before. Thank you.
worthless-trash 21 minutes ago [-]
They didnt mention the real side benefit of HTMX, and thats the twitter account memes.
n4pw01f 9 hours ago [-]
Have a pretty large application running HTMX + WebComponents + Hono + Cloud Functions to serve up frontends, happy with it for about 2 years now
People throw salt at my stack but it’s fast, and straightforward to manage attack surface
esperent 7 hours ago [-]
I'm using Hono + Tanstack Router as a Next.js replacement. Best software related decision I ever made, it feels like I stopped fighting with the stack.
wren6991 22 hours ago [-]
Huh, so every interactive event has a network request in the loop, with perceptible latency? And you still end up obligating client-side JS for the plumbing? I'd been meaning to look into HTMX but based on the content of this post it seems like a worst-of-all-worlds technical solution. Is it at least pleasant to work with?
yawaramin 21 hours ago [-]
No, every interactive event doesn't need to have a network request in the loop. And you only need a tiny bit of client-side JS for a most of the plumbing.
It is quite pleasant to work with, because you don't have to worry about a constant stream of vulnerabilities or supply chain attacks. You just vendornthe script in your repo, add it as a <script> tag on the page, and you're done.
Rohansi 9 hours ago [-]
Supply chain attacks are not a JavaScript or npm exclusive risk. If you pull in any dependencies you have a supply chain risk.
barrkel 6 hours ago [-]
As is well known, security is not a binary, it's a spectrum. It's why you add security in layers, and why it's generally a trade-off between risk and usability.
Your mileage may vary, but I sleep better with my own projects not having any node_modules in their build tree.
robertoandred 8 hours ago [-]
How is htmx invulnerable to vulnerabilities and attacks?
stymaar 3 hours ago [-]
It's not invulnerable, I think gp just means that reducing your amount of dependencies reduces the attack surface.
deadbabe 12 hours ago [-]
Who is worrying? If JavaScript is on the front end the supply chain attacks are really not your problem.
traverseda 10 hours ago [-]
What? It handles your password fields.
deadbabe 10 hours ago [-]
Just do SSO.
dmoreno 22 hours ago [-]
That's why many times HTMX is used together with alpinejs [1].
For areas that need server side, if you use say react and return a JSON you have to deserialize and do the render. It might be much more efficient to just replace.
Having said that I use HTMX /alpinejs for small projects, and still trust react for bigger more interactive ones.
It’s only has a network request in the loop if the interaction requires a network request.
Htmx is a replacement for network interactions, not every bit of UI interactivity.
muvlon 14 hours ago [-]
It's for building extremely backend-brained frontend stuff, like a sort of anti-NextJS. Also like NextJS, this sort of domain-bending has some unfortunate operational consequences.
draw_down 11 hours ago [-]
[dead]
inigyou 14 hours ago [-]
the network is faster than so much shitty client-side JS these days.
grebc 13 hours ago [-]
When you say these days, I’d argue since mid/late 2000’s for internet with a cable vs. radio waves.
Radio waves caught up in developed countries with 4G roll outs in my opinion(is that mid 2010’s?).
Large client side JS has been garbage for most things since it’s inception.
8 hours ago [-]
yyyk 7 hours ago [-]
The problem with HTMX is not network traffic but needing to use hyperscript for anything advanced.
antihero 4 hours ago [-]
Also don't you entirely lose typing?
My favourite thing about TSX is that it is typechecked. How do you do that with random strings of HTML?
sparse-Matrix 1 days ago [-]
Bravo! I never would have thought this would be so simple. As a direct consequence of this exercise: I now know something about what, precisely, htmx does.
cheers
oaxacaoaxaca 11 hours ago [-]
>Or you can just use htmx?
great idea thank you for the recommendation
pixel_popping 20 hours ago [-]
The Github link at the bottom contains a `,` char, might want to fix it.
Is there something known wrong with github rn (aside from everything, I guess)? It claims there are 422 contributors but when you click in there are only three.
ameliaquining 12 hours ago [-]
Change the period from "last 3 months" to "all".
sodapopcan 11 hours ago [-]
I did. Still 3.
But then I'd ask my original question that I didn't post: how the hell does this repo have 422 contributors?
GitHub's contributor graph is based on authorship of Git commits, and doesn't track whether a given GitHub account ever actually interacted with a given GitHub repo. This Git repo is a fork of the htmx Git repo (though it's not marked as such on GitHub), so all contributors to htmx as of the fork date are also contributors here.
sodapopcan 11 hours ago [-]
Ahhh makes sense if it's a fork. Odd that it's not marked as one. Sort of an odd thing that you can get associated with a repo you don't even know exists.
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.
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.
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
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:
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.
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...
People throw salt at my stack but it’s fast, and straightforward to manage attack surface
It is quite pleasant to work with, because you don't have to worry about a constant stream of vulnerabilities or supply chain attacks. You just vendornthe script in your repo, add it as a <script> tag on the page, and you're done.
Your mileage may vary, but I sleep better with my own projects not having any node_modules in their build tree.
For areas that need server side, if you use say react and return a JSON you have to deserialize and do the render. It might be much more efficient to just replace.
Having said that I use HTMX /alpinejs for small projects, and still trust react for bigger more interactive ones.
[1] https://alpinejs.dev/
Htmx is a replacement for network interactions, not every bit of UI interactivity.
Radio waves caught up in developed countries with 4G roll outs in my opinion(is that mid 2010’s?).
Large client side JS has been garbage for most things since it’s inception.
My favourite thing about TSX is that it is typechecked. How do you do that with random strings of HTML?
cheers
great idea thank you for the recommendation
https://github.com/bigguysoftware/htmxxx
But then I'd ask my original question that I didn't post: how the hell does this repo have 422 contributors?
GitHub's contributor graph is based on authorship of Git commits, and doesn't track whether a given GitHub account ever actually interacted with a given GitHub repo. This Git repo is a fork of the htmx Git repo (though it's not marked as such on GitHub), so all contributors to htmx as of the fork date are also contributors here.
Thanks for engaging me and my confusion.
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.