Rendered at 02:01:17 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
yawaramin 5 hours ago [-]
> 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.
wmanley 4 hours ago [-]
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.
eliasdejong 2 hours ago [-]
> 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.
Sure, that's basically what Phoenix LiveView does. But I would submit that you don't actually need that level of complexity with a bit of judicious UI/UX design, where as the app grows in scale, the number of oob swaps to keep track of doesn't grow as much.
There are many ways to skin the cat.
36 minutes ago [-]
dhamidi 5 hours ago [-]
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.
arthurcolle 8 hours ago [-]
Video doesn't seem to be rendering, has 0:00 and 0:00 as start and end times
QuantumNomad_ 6 hours ago [-]
Video codec is avc1. I think in Safari on iOS this codec is not available on iPhones older than iPhone 15 Pro.
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.
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.
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.
[1] https://data-star.dev/
There are many ways to skin the cat.
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.