3 ms·

One major downside to HTMX is that as soon as there is any state you have to keep track of, you're teleported back to the late 90s or early 2000s where you have

One major downside to HTMX is that as soon as there is any state you have to keep track of, you're teleported back to the late 90s or early 2000s where you have to keep track of all your state in hidden form fields, and you're extremely constrained in how you update pages. IMO, it's annoying enough that it's probably not worth it unless you're doing something trivial. If you want to render html on the server you can still do that, but in many cases it is easier to just use custom javascript and maybe even receive the rendered html as json to simply updating pages rather than use htmx.

jon1628492 5y ago
I'm new to htmx and alpine, but isn't alpine's global store what you'd want in this case? https://alpinejs.dev/magics/store https://alpinejs.dev/magics/store
- saimiam 5y ago
  (I'm not very familiar with Alpine and htmx but I'm comfortable with Vue and React.) Htmx pulls html content from the server and replaces inner|outerHTML with it. A JSON object (of the type React/Vue and presumably Alpine use) isn't a good fit to store html blobs and state.
nlitened 5y ago
Yeah, those damned early 2000s when back/forward buttons worked perfectly and we didn't lose the entire rich client state upon page refresh or wireless internet hiccup. Thank god we have a lot of JavaScript libraries and ambitious programmers to save us from those trivial things :)
- kiawe_fire 5y ago
  But those were actual problems back then, and they were solved only through significant engineering work to hide them, each of which had their own problems. Frameworks like .Net WebForms were created to abstract and hide a lot of this from developers, with things like long encoded strings of "view state" that would be re-posted on each request, by serializing things to the URL, or by saving them to Cookie-backed sessions. But each of these has issues, from privacy concerns using the URL, to security concerns with the "view state", to concurrency and integrity concerns with sessions. IMO, the biggest reasons these didn't stand out as huge problems in the early 2000's was because: (a) we didn't use the web like we do today, and our expectations were very different in how things would work if we, for example, added an item to a shopping cart (b) most heavily interactive / app-like things that more closely work "the way we expect" today, were either still done as desktop apps (like business software) or were implemented as Java applets, Flash, or something else of the sort (c) in the rare cases that neither (a) nor (b) applied, it was because some very good engineers put in a lot of work to make it work that way.
- phist_mcgee 5y ago
  You mean when a page refresh asked us if it wanted to resubmit a form?
  - nlitened 5y ago
    We did this standardized simple trick to prevent this: https://en.m.wikipedia.org/wiki/Post/Redirect/Get https://en.m.wikipedia.org/wiki/Post/Redirect/Get

jon1628492 5y ago

I'm new to htmx and alpine, but isn't alpine's global store what you'd want in this case? https://alpinejs.dev/magics/store https://alpinejs.dev/magics/store

saimiam 5y ago
(I'm not very familiar with Alpine and htmx but I'm comfortable with Vue and React.) Htmx pulls html content from the server and replaces inner|outerHTML with it. A JSON object (of the type React/Vue and presumably Alpine use) isn't a good fit to store html blobs and state.

nlitened 5y ago

Yeah, those damned early 2000s when back/forward buttons worked perfectly and we didn't lose the entire rich client state upon page refresh or wireless internet hiccup. Thank god we have a lot of JavaScript libraries and ambitious programmers to save us from those trivial things :)

kiawe_fire 5y ago
But those were actual problems back then, and they were solved only through significant engineering work to hide them, each of which had their own problems. Frameworks like .Net WebForms were created to abstract and hide a lot of this from developers, with things like long encoded strings of "view state" that would be re-posted on each request, by serializing things to the URL, or by saving them to Cookie-backed sessions. But each of these has issues, from privacy concerns using the URL, to security concerns with the "view state", to concurrency and integrity concerns with sessions. IMO, the biggest reasons these didn't stand out as huge problems in the early 2000's was because: (a) we didn't use the web like we do today, and our expectations were very different in how things would work if we, for example, added an item to a shopping cart (b) most heavily interactive / app-like things that more closely work "the way we expect" today, were either still done as desktop apps (like business software) or were implemented as Java applets, Flash, or something else of the sort (c) in the rare cases that neither (a) nor (b) applied, it was because some very good engineers put in a lot of work to make it work that way.
phist_mcgee 5y ago
You mean when a page refresh asked us if it wanted to resubmit a form?
- nlitened 5y ago
  We did this standardized simple trick to prevent this: https://en.m.wikipedia.org/wiki/Post/Redirect/Get https://en.m.wikipedia.org/wiki/Post/Redirect/Get