231–240 of 256 posts
Was curious to see the code so found the GitHub. Posting it here in case anyone is interested since the author doesn't link to it on the site and also the npm page doesnt link to it either https://github.com/Kalabasa/htmz
It is right at the end of the first sentence.
I think there's a pretty strong argument at this point for this kind of replacing DOM with a response behavior being part of the platform. I think the first step would be an element that lets you load external content into the page declaratively. There's a spec issue open for this: https://github.com/whatwg/html/issues/2791 And my custom element implementation of the idea: https://www.npmjs.com/package/html-include-e…
This seems snappy from the US but I doubt someone in say NZ will have a good experience. Going back and forth between the client and the server on every interaction can result in terrible UX. Users will be happy waiting 1-2 seconds after submitting a form but waiting that much to switch a tab is not gonna fly. Plus there's internet weather etc which might result in unpredictable latencies over long distances. Yes, yo…
If you need to fetch data from the server side, you need to fetch data from the server side. It doesn't matter much if it's a 10k json that you have to load and parse, or a 12k html snippet that you can directly display, the delay would be the same. If you are concerned about the delay when switching a tab, nothing prevents you to load both tabs during the first page load, and then just display the content without a…
Earlier quoted context omitted.
Hi Carson! I've been using htmx sprinkled with hyperscript and I find using your tools very enjoyable (though I found myself fighting a bit with hyperscript at the beginning but past that and once you get the mindset and the hs way, things are easier). Thanks for these tools! I wanted to also take the opportunity to ask you something you either mentioned, commented or heard in a podcast. You said that htmx might not…
I wrote an essay on that topic here: https://htmx.org/essays/when-to-use-hypermedia/ Things that involve a lot of events that need to be handled quickly are not a good fit for hypermedia. Sometimes you can have a rich island inside hypermedia though (e.g. a rich text editor w/ autocomplete, etc) so long at is triggers events and offers form participation. Two common examples I give are google maps and google sheets.…
The next request hits the service worker and then gets any json from the server ( if not cached ) and returns the html fragment.
It uses htmx .
I thought it was a nice have your cake and eat it too
Earlier quoted context omitted.
Hi Carson! I've been using htmx sprinkled with hyperscript and I find using your tools very enjoyable (though I found myself fighting a bit with hyperscript at the beginning but past that and once you get the mindset and the hs way, things are easier). Thanks for these tools! I wanted to also take the opportunity to ask you something you either mentioned, commented or heard in a podcast. You said that htmx might not…
I wrote an essay on that topic here: https://htmx.org/essays/when-to-use-hypermedia/ Things that involve a lot of events that need to be handled quickly are not a good fit for hypermedia. Sometimes you can have a rich island inside hypermedia though (e.g. a rich text editor w/ autocomplete, etc) so long at is triggers events and offers form participation. Two common examples I give are google maps and google sheets.…
This seems snappy from the US but I doubt someone in say NZ will have a good experience. Going back and forth between the client and the server on every interaction can result in terrible UX. Users will be happy waiting 1-2 seconds after submitting a form but waiting that much to switch a tab is not gonna fly. Plus there's internet weather etc which might result in unpredictable latencies over long distances. Yes, yo…
This is my biggest gripe with this approach as well as HTMX. Avoiding delays for what should be purely client-side actions is a non-negotiable to me.
Earlier quoted context omitted.
Kind of makes me wish there was a htmx-lite of sorts. Like an 80/20 solution at 20% of the size, which could be extended to the full blown package with extensions. Have you thought about moving more features to extension, like was done with the web sockets feature?
I've looked at the codebase and there isn't much I feel would do well as an extension. As I said upthread, most of the code is AJAX, input gathering, history support and then book-keeping/event stuff around that. There will be a bunch of htmx-like libraries coming out though and I expect many of them to take different design perspectives. Two that I'm aware of are https://data-star.dev/ and https://ajaxial.unmodernwe…
https://github.com/delaneyj/datastar
https://data-star.dev/examples
The way SSE is done is pretty cool as well as the NATS server integration.
The 3D aspects with htmx looks talk fab too
Why not htmy ?
I'm guessing it's like "htmx-zero", given it's a superlightweight version of what htmx is doing.
But iframes can't do
* Deletion (e.g complete a todo list item)
* Tail end append (e.g lazy loading infinite scroll list)
So i pivoted to js...
onclick=async e=>{x=e.target.dataset.x;if(x){e.preventDefault();document.querySelector(x).innerHTML=await fetch(e.target.href).then(r=>r.text())}}
doesn't works with form though.