Live data from Hacker News

Htmx 4.0

four.htmx.org

211–220 of 229 posts

Re: Htmx 4.0

#211

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 .

You found HTMX?

Re: Htmx 4.0

#212
Htmx 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 = 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

#213

Earlier 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.

As far as I understand D* only uses id (which is a pretty normal HTML attribute?) to key morphs in SSE. I only use one id for fat morphs on the body, and even if I needed more I'm not sure I'd find that any less ergonomic than other web standard attributes (class for example I have to use religiously in my day job with tailwind, etc).

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

#214
post #158

Somewhat 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.

I had a similar thought when someone linked [1] Mike Acton's "Data-Oriented Design Operating Rules" [2] written for agents. The text is Claude-y, but the step-by-step DOD guidance is neat, it specifies a development protocol the likes of which I haven't seen elsewhere, besides in Mike's talks (in less detail).

1. https://news.ycombinator.com/item?id=49062520

2. https://github.com/macton/nagent/blob/main/context/data-orie...

Re: Htmx 4.0

#215

Htmx 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

#216

Htmx 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

103KB is the actual source code. You should not be reading or debugging the minimized or gzip/transport bytes.

Re: Htmx 4.0

#217

Maybe 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?

Because serialisation and deserialisation have a price and you almost never need what you describe

Re: Htmx 4.0

#218

Is it a good idea to code an app with infinite canvas (like Excalidraw) in Htmx?

Nope, this kind of app will hold a ton of business logic in the JS side, so HTMX is irrelevant in this context.

Re: Htmx 4.0

#219
post #116

Earlier 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.

So what do you use instead?
Post reply on HN