Building Progressively Enhanced Forms Using htmx
1–10 of 15 posts
Re: Building Progressively Enhanced Forms Using htmx
#2Video doesn't seem to be rendering, has 0:00 and 0:00 as start and end times
Re: Building Progressively Enhanced Forms Using htmx
#3Video doesn't seem to be rendering, has 0:00 and 0:00 as start and end times
Works for me in Firefox. It's h264/mp4.
Re: Building Progressively Enhanced Forms Using htmx
#4Re: Building Progressively Enhanced Forms Using htmx
#5Video doesn't seem to be rendering, has 0:00 and 0:00 as start and end times
Video codec is avc1. I think in Safari on iOS this codec is not available on iPhones older than iPhone 15 Pro.
Re: Building Progressively Enhanced Forms Using htmx
#6> Fiddling with out-of-band swaps to solve this feels error prone and overly hard to maintain.
This is almost always because of using a string-based templating system. If you use a language-embedded HTML generation library, it represents HTML fragments as first-class values in your language, and you can compose them together in flexible ways. This makes out-of-band swaps very simple.
Re: Building Progressively Enhanced Forms Using htmx
#7> Fiddling with out-of-band swaps to solve this feels error prone and overly hard to maintain. This is almost always because of using a string-based templating system. If you use a language-embedded HTML generation library, it represents HTML fragments as first-class values in your language, and you can compose them together in flexible ways. This makes out-of-band swaps very simple.
HTMX is great, Hypermedia and HATEOAS are great, HTML-string-templates are not great.
For some reason they are still popular.
A fun experiment is to use a JS runtime with React but render the component tree on the server onto a Writeable stream.
Very easy to understand, no useEffect footguns, great composability.
Re: Building Progressively Enhanced Forms Using htmx
#8> Fiddling with out-of-band swaps to solve this feels error prone and overly hard to maintain. This is almost always because of using a string-based templating system. If you use a language-embedded HTML generation library, it represents HTML fragments as first-class values in your language, and you can compose them together in flexible ways. This makes out-of-band swaps very simple.
You mean by having a function per fragment? I don’t think this solves the hard to maintain bit - which is “which fragments should I regenerate/send”, and how do I keep that list up to date as my app evolves.
FWIW I have a potential solution: to show live data in my app I use an SSE stream of OOB swaps. On every relevant change to the database I regenerate the HTML and compare it to the previously generated html to create OOB swaps (including hx-preserve). I send that down so the browser can update.
The same approach could be used for normal POSTs. On a POST generate the HTML before and after modifying the database and diff them to generate OOB swaps.
Re: Building Progressively Enhanced Forms Using htmx
#9Re: Building Progressively Enhanced Forms Using htmx
#10> Fiddling with out-of-band swaps to solve this feels error prone and overly hard to maintain. This is almost always because of using a string-based templating system. If you use a language-embedded HTML generation library, it represents HTML fragments as first-class values in your language, and you can compose them together in flexible ways. This makes out-of-band swaps very simple.
You mean by having a function per fragment? I don’t think this solves the hard to maintain bit - which is “which fragments should I regenerate/send”, and how do I keep that list up to date as my app evolves. FWIW I have a potential solution: to show live data in my app I use an SSE stream of OOB swaps. On every relevant change to the database I regenerate the HTML and compare it to the previously generated html to cr…
> FWIW I have a potential solution: to show live data in my app I use an SSE stream of OOB swaps.
You might be interested in Datastar [1], which is like htmx but centered around Server-Sent Events. You don't have to do diffing yourself in application code because it's already handled by the framework under the hood through the "idiomorph" DOM morphing algorithm.