221–230 of 235 posts
According to their docs "htmx is a library that allows you to access modern browser features directly from HTML, rather than using javascript" Can anyone confirm this claim? How good is this? Doing everything in HTML/CSS might have some advantages. Is it quick and compatible enough?
Why did they skip version 3?
As a joke. Back when 2 came out, they promised there would never be a version 3. I.e., no breaking changes. Then they realized they did need to make a breaking change, so the only way to be true to their promise was to skip version 3.
The upgrade is completely voluntary: it won’t even be set as the default version in npm till next year, and there are no known security issues that would force anyone to upgrade. People happy with v2 can just stay on it for the foreseeable future.
Earlier quoted context omitted.
As a joke. Back when 2 came out, they promised there would never be a version 3. I.e., no breaking changes. Then they realized they did need to make a breaking change, so the only way to be true to their promise was to skip version 3.
This can be a good summary of htmx overall; a confident solution based on half understanding of the problem domain.
And by the looks of it, the Author is starting to understand the reason React and the likes exists and has start to build them over again: https://fixiproject.org/ LOL. Frontend dev never changes.
Congrats and thanks! htmx brings me joy. Pretty much every experiment I build now starts with Go, htmx, and SQLite to keep things simple and fast but still responsive. I put a few more thoughts about this here: https://housecat.com/blog/the-hugs-stack-hypermedia-unix-go-...
If you want a prototype fast, don't you use an LLM? And if you do, why start with a simpler framework?
Earlier quoted context omitted.
This can be a good summary of htmx overall; a confident solution based on half understanding of the problem domain.
You’ve misunderstood the reason for v4; see https://news.ycombinator.com/item?id=49493929
He is catching up though, now approaching the early 2010s jQuery (moxi) and backbonejs era with fixiproject.org
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…
Earlier quoted context omitted.
I don't understand (possibly because I lack Angular experience): what is it about a .NET backend using HTMX that requires presentation concerns to be mixed with business logic? Don't you have to maintain that separation either way? Your core/application logic shouldn't know how its result is ultimately represented. That could be JSON or HTML over HTTP, Protobuf over a TCP stream, or a custom binary protocol over a Un…
HTMX requires you to return HTML chunks (and calls that hypermedia) that get dumped directly into the client-side HTML. So instead if returning data (JSON, XML, whatever), every part of your API now needs to return parts of client-side UI, and be aware of changes in it.
I understand the issue of mixing state models.. angular SPA style vs HATEOAS.
But that still doesn't answer what I was asking about mixing presentation concerns into business logic. Returning HTML means the presentation layer has to know about HTML. Why would that require the business logic to know about it?
Earlier quoted context omitted.
You’ve misunderstood the reason for v4; see https://news.ycombinator.com/item?id=49493929
No, you misunderstand what is going on. htmx is an exercising in learning web development by someone who didn’t follow 2 decades of web development progress. He is catching up though, now approaching the early 2010s jQuery (moxi) and backbonejs era with fixiproject.org
The creator has been working on these ideas for a long time, but the core idea–swapping HTML from the server into the DOM–has been constant throughout.
It's exactly because he followed the past two decades of web dev that htmx avoids almost everything about it. Fixi and htmx extensions follow the 80/20 principle and can work by just being dropped in with a script tag. You don't need an elaborate npm setup, same as everything else in the htmx ecosystem.