Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building Progressively Enhanced Forms Using htmx

rafa.ee

Post reply on HN
Print view View original

11–15 of 15 posts

Re: Building Progressively Enhanced Forms Using htmx

#11

Post by yawaramin »

wmanley wrote: post #8
yawaramin wrote: post #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.

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…

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.

Re: Building Progressively Enhanced Forms Using htmx

#12

Post by [deleted] »

yawaramin wrote: post #11
wmanley wrote: post #8

Earlier quoted context omitted.

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…

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.

[deleted]

Re: Building Progressively Enhanced Forms Using htmx

#13

Post by JSR_FDED »

wmanley wrote: post #8
yawaramin wrote: post #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.

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…

Datastar makes this even simpler. No need to think about OOB swaps. Just regenerate the page and Datastar streams it over SSE and surgically updates the DOM. They call this “fat morph”. You can be more precise about individual updates but it’s hardly ever necessary - it’s basically instantaneous.

Given how much you’ve already developed it would take you no time to pick it up but of course it’s nice to control your own destiny with your own code.

There’s one additional thing you get with Datastar and that’s a very easy Signals implementation on the browser side. For lightweight interactivity you don’t need a server trip. And when you do POST something to the server the values of the signals are automatically included so your backend code knows the front end UI state (and can modify it).

Re: Building Progressively Enhanced Forms Using htmx

#14

Post by QuantumNomad_ »

arthurcolle wrote: post #9
QuantumNomad_ wrote: post #5

Earlier quoted context omitted.

Video codec is avc1. I think in Safari on iOS this codec is not available on iPhones older than iPhone 15 Pro.

I have an iPhone 15 Pro Max. Damn you Tim Apple

But then that codec should work.

Maybe there is something else about the video that iOS doesn’t like also?

Re: Building Progressively Enhanced Forms Using htmx

#15

Post by torarvid »

QuantumNomad_ wrote: post #5
arthurcolle wrote: post #2

Video 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.

16 Pro here. Also doesn’t work
Post reply on HN