I found Htmx to be a great combo with agent driven development. It lets you end-to-end test the UI without a full headless browser by just examing the HTML, which means UI tests are cheap and fast, which means you can have tons of them. And coding agents are exactly as good as your test coverage. So with Htmx they're great .
Htmx 4.0
211–220 of 230 posts
Re: Htmx 4.0
#212 fetch('/my/api/content.html')
.then(response => response.text())
.then(html => {
document.getElementById('content').innerHTML = html;
});
I don't mean to imply this is close to total number of Htmx features, but fetching islands of content is the core idea and I feel like we're way past feature bloat at this point for something that is supposed to be simpler than React (Preact is only 10kB)Re: Htmx 4.0
#213Earlier quoted context omitted.
I'll shill datastar for a second, there's barely a notion of frontend state management if you treat HTML as a projection surface with interactivity. I'd argue HTML is the most efficient wire format for interactive web apps, especially with streaming + compression. Seriously DB->json->client->toHtml DB->toHtml->client Just imagine if that html wire format also conveyed the interactivity too and you eliminate the issue…
Datastar relies way to much on IDs everywhere that it's not ergonomic and turns into a chore. It's also a bit too complicated for its own good trying to solve everything.
Can you elaborate on the "too complicated" part? It seems a lot simpler to me given the slim surface area of the APIs?
Re: Htmx 4.0
#214Somewhat of an aside: it's ironic the that some of the clearest, most concise technical documentation I now find on the Internet has come out that way because it was written for a machine: https://raw.githubusercontent.com/bigskysoftware/htmx/v4.0.0... Human readers don't receive this level of care or attention.
1. https://news.ycombinator.com/item?id=49062520
2. https://github.com/macton/nagent/blob/main/context/data-orie...
Re: Htmx 4.0
#215Htmx 4.0 is over 100kb / 2,000 lines of code. Isn't there a way to slim this down some? I mean, isn't the basic idea just a couple lines of code? I remember AJAX 2.0 or whatever loaders that were only 1-5kb wrappers around XHR back in the day. Now we have fetch() which is even more basic: fetch('/my/api/content.html') .then(response => response.text()) .then(html => { document.getElementById('content').innerHTML = ht…
Re: Htmx 4.0
#216Htmx 4.0 is over 100kb / 2,000 lines of code. Isn't there a way to slim this down some? I mean, isn't the basic idea just a couple lines of code? I remember AJAX 2.0 or whatever loaders that were only 1-5kb wrappers around XHR back in the day. Now we have fetch() which is even more basic: fetch('/my/api/content.html') .then(response => response.text()) .then(html => { document.getElementById('content').innerHTML = ht…
Where are you getting those numbers from? The minified code is about 40kB before compression and about 13kB with gzip. https://bundlephobia.com/package/htmx.org@4.0.0
Re: Htmx 4.0
#217Maybe I’m missing something, but why would you want HTMX server side rendering, rather than a restful API that can return platform-agnostic data structures that you could render in various contexts, like a SPA, or a mobile app, or a terminal app, etc?
Re: Htmx 4.0
#218Is it a good idea to code an app with infinite canvas (like Excalidraw) in Htmx?
Re: Htmx 4.0
#219Earlier quoted context omitted.
> managing state on the server is not fun at all. Really? I've never found that difficult. Sessions exist, URL parameters exist... Perhaps in a complex SPA you can have trouble, but so many of the "applications" I've worked on are just glorified documents.
I haven't used sessions in over a decade and haven't regretted that decision once. It opens up a whole new class of problems you don't have when using client-side frameworks.
Re: Htmx 4.0
#220Shame the page does not tell you what HTMX is, even in one sentence.