Nice, I really like this series, this made me really understand those web frameworks much better as before. Thank you.
Let's make the worst Htmx
41–50 of 85 posts
Re: Let's make the worst Htmx
#42Earlier quoted context omitted.
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 app…
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.
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
Re: Let's make the worst Htmx
#43HTMX is amazing on paper, not in real life.
It loses things like scroll position and text highlighting on re-render - it’s not high performance like React.
This is for server sided or static web pages not building rich UI.
There is no robust state management or DOM performance improvements you get with React with larger components.
HTMX team should build a game with it. Load some 3D in WebGL/WebGPU, showcase high performance UI.
Or showcase complex state management.
I need more than syntax idealism.
Re: Let's make the worst Htmx
#44I wrote a really tiny web app using Django and HTMX to do a find-as-you-type telephone directory, and it worked really well.
I wish I did more front-end stuff so I could play with it more.
Re: Let's make the worst Htmx
#45I 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, t…
How do you debug SSE messages since they don’t show up in chrome dev tools with Datastar?
Re: Let's make the worst Htmx
#46I really want to try htmx but it specifically prohibits my most common usecases:
1) I want to take a JSON response, create HTML from it, and replace the target element with the generated HTML.
2) Similar to the above, take a JSON response, perform some action, and do nothing to the source element.
Is there a plugin to add this? I want to move away from jQuery, and having a small framework to wire up hooks would be useful.
Re: Let's make the worst Htmx
#47Earlier quoted context omitted.
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 tag on the page, and you're done.
Who is worrying? If JavaScript is on the front end the supply chain attacks are really not your problem.
The supply chain attacks you need to worry about come from using npm.
Re: Let's make the worst Htmx
#48I 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, t…
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.
Re: Let's make the worst Htmx
#49Huh, 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?
Datastar has a lean and mean signals implementation that handles all the front-end reactive stuff - so you don’t have to go to the server for interactivity.
Re: Let's make the worst Htmx
#50HTMX is amazing on paper, not in real life. It loses things like scroll position and text highlighting on re-render - it’s not high performance like React. This is for server sided or static web pages not building rich UI. There is no robust state management or DOM performance improvements you get with React with larger components. HTMX team should build a game with it. Load some 3D in WebGL/WebGPU, showcase high per…
> HTMX team should build a game with it. Load some 3D in WebGL/WebGPU, showcase high performance UI.
Why? Why you'd pick htmx (or even reactjs?!?) to build a game?