First, I'll preface this that what I'm about to write is meant as an endorsement of HTMX.
What HTMX does should've been a W3C standard a decade ago, and I've my fingers crossed that some day I'll be able to do what I've done with jQuery and remove it.
Thank you for pushing the state of the art forward in a meaningful (and RESTful!) way.
I love the model. I've been writing a golang app with the standard library template system and it works really well.
One bit I've found slightly unintuitive is the swap and settled states. Took my a while to animate in a sidebar how I wanted. It was my fault for not groking it faster but perhaps some more examples or guides in that regard could be useful.
Hi, on the subject of hypermedia: I recently saw your talk when you showed hyperview.org as an alternative to HTML for mobile use case.
As someone who is very interested in the space, are there other hypermedia implementation (if is the right word) that you found interesting? Or do you have some pointer for those who want to explore this space?
Personally I really want some kind of hypermedia framework for terminal application, since I often need to work with hardware (or bandwidth) where the only interface is a terminal, and I never feel productive with manually writing the application code, having to reimplement a new client every time.
Also thank you for htmx, I started using for a couple of project, and it really is refreshing. Especially kudos for the various example, that really helped making it "click".
heya, i don't know of any terminal-based hypermedia, but that's an interesting concept
maybe gopher as a prototype example?
adam stepinski (creator of hyperview) is one of the heroes of hypermedia in that he didn't just develop a hypermedia format but also developed a hypermedia client, and you need both for a proper hypermedia system
so, I would say... maybe you are lookin' at the person in the mirror who is going to make that terminal app hypermedia?
How does error handling work? If I try to replace the content of some div with a reply I get using htmx, but the request fails or times out etc., what content is then put into the div? What if the reply is not valid HTML?
I've never used htmx, primarily because I like the concept of "components" so much. (They serve two needs - standardizing larger blocks of UI and encapsulating them with an alternative interface, and providing islands of rich interactivity)
Is there any material on successfully combining htmx with web components? It doesn't look to me like the original design takes this possibility into consideration...
(note: at a surface glance it doesn't look to me like components are in conflict with hypermedia - one could treat them as a side channel that "enhances" the standard set of elements)
I'm not sure if I've entirely grokked the idea of components, but can't you define them server-side? So write them as some template magic that creates the "inner HTML". Then you just need some HTMX to enable using the component in a richer way.
It's not really Web Components as specified, but iirc those are generally pretty much JS-dependent? But hypermedia's reliance on server side rendering means that you can just move this logic to the server.
Why wouldn't htmx work with web components? It just does asynchronous fetches and DOM swaps. Web components are just pieces of DOM. There should be absolutely no issue with them working together?
You have mentioned here and in other places that you use HTMX + HyperScript in production. Curious what that looks like, is it part of consulting, a side business, a day job ?
When I started using them, one of the hardest parts was to actually have it imported and built with webpack, since the site focuses on cdn and webpack example is really brief. Same goes for hyperscript
What’s the story for modals? Or multiple modals, navigating in them etc… Do you plan to take inspiration from Unpoly Layers (https://unpoly.com/up.layer) or is it out of scope for htmx?
Quick question, as it made me curious. Can I send the content that I want to swap to the server itself? Say I want to submit a form to the backend, will it only send form fields or is there a way to send the form html itself?
I'm gonna make a note on that when I have cycles to burn to experiment with htmx. From my understanding of reading that section, parameters being a container of kv pairs, I'd have to hack on the internals of htmx for it to be able to send a pure string (not form/multipart) as the body of a post/put request.
If I get around of experimenting with that, and it fits my flow, would that be something you'd accept back into the project as a contribution to the code?
I have a nifty (or so I'd like to think) slapped together HTML parser, that instead of building a DOM tree, streams the HTML nodes as a list. Which in practice makes it easier to validate a field, and insert the appropriate validation message at the right location, without switching from request -> data representation -> validation failure model -> templating language ifdefs to inline the validation classes and additional helper text.
Might sound not that convenient for basic things like login forms, but I have frontend code that builds dynamic form fields, which I'd like to not replicate via the backend templating language, if extracting data from HTML itself is a breeze in my case.
Of course I'm going to do that myself anyway, but I'd rather use an established library which also handles in browser page restoration/caching (possibly also fragments), instead of rolling my own JS lib.
Two questions. What would you recommend to build the backend in, some language that can parse xml/html well? And second question, are there any more extensive examples such as working authentication?
That’s part of the benefit of htmx and it’s hypermedia approach, you can build the backend in anything you prefer. Some like using language and frameworks that use templates. Others, like we do, used fairy basic HTML generation libraries. We love Clojure so we use the Hiccup library to generate HTML. We use the full power of clojure and functions to build reusable HTML type components and their fragments.
I stopped scrolling as soon as I noticed I have to ask myself what am I posting to this URL?
Maybe digging deeper I could find the reference docs explaining in very vague terms where the payload is coming from. But this was supposed to be simple.
This project has seemingly picked up a bunch of traction. The number of times it has appeared on the front page of this website serves as some indication, as well as the plethora of conference talks.
You seemed unwilling to put more than 2 minutes into looking at an example, or 10 seconds into checking what page you were on, yet felt that your experience warranted these dismissive comments which cumulatively proportionally surely took up just as much time.
You aren’t acting in good faith. This doesn’t add to the conversation at all.