4 ms·

HTMX relying on a server request to make even minor UI changes (e.g. their first example https://htmx.org/examples/click-to-edit/ https://htmx.org/examples/clic

by lxe 3y ago

HTMX relying on a server request to make even minor UI changes (e.g. their first example https://htmx.org/examples/click-to-edit/ https://htmx.org/examples/click-to-edit/) is wild to me. You might remember when a thing called DHTML revolutionized how JavaScript could be used to build interactive UIs on the web... why go back to pre-2001 era? I get it, SPAs are overkill, but swinging the pendulum all the way back is very strange.

Karrot_Kream 3y ago
What's a good middle ground for you? I don't intend to be combative at all, I just mostly hack on backend professionally and for fun so when it comes to evaluating frontend technologies I'm useless. Is it preact? Svelte?
- lxe 3y ago
  You can make a reasonable interactive app with htmx + javascript, but tings will be rather barebones -- you'll need to invent some patterns outside of what HTMX prescribes. With react you get somewhat prescriptive low-level patterns when it comes to "managing data flow", so I would probably use react to keep things consistent.
jddj 3y ago
I've been seeing more lately that the stack is being mentioned as htmx+alpinejs. Not sure how long it'll be until the htmx part gets rationalised out in those instances. Maybe it won't, and people will keep shipping both. Stranger things have happened
deleted 3y ago
[deleted]
recursivedoubts 3y ago
https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/ https://hypermedia.systems/client-side-scripting/ https://hypermedia.systems/client-side-scripting/ I can understand the objection to the first request but the second is necessary to update state on the server. You could avoid the first request via scripting but the complexity, in my opinion in most cases, would not be worth it.
yawaramin 3y ago
htmx doesn't require you to make a request for UI changes. You can express your UI in terms of components which have built-in interactivity, eg dropdowns, inputs, details/summary tags, etc. You can go pretty far with those before you need to make a request.
wrapperup 3y ago
Agree on the first point, I think using JS makes more sense when you need to update some client state, like a dropdown or even that edit example. But htmx makes a lot more sense when you need to render some data from a server. In a SPA, you receive JSON, only to transform it back into HTML to render, so why not skip that middle step? You might find https://data-star.dev/ https://data-star.dev/ interesting, it takes some of the modern approaches (signals, etc) and mixes it with the efficiency of sending straight-up HTML, htmx style. It's very similar to using Alpine + htmx together.

by lxe 3y ago

Karrot_Kream 3y ago

What's a good middle ground for you? I don't intend to be combative at all, I just mostly hack on backend professionally and for fun so when it comes to evaluating frontend technologies I'm useless. Is it preact? Svelte?

lxe 3y ago
You can make a reasonable interactive app with htmx + javascript, but tings will be rather barebones -- you'll need to invent some patterns outside of what HTMX prescribes. With react you get somewhat prescriptive low-level patterns when it comes to "managing data flow", so I would probably use react to keep things consistent.

jddj 3y ago

I've been seeing more lately that the stack is being mentioned as htmx+alpinejs. Not sure how long it'll be until the htmx part gets rationalised out in those instances. Maybe it won't, and people will keep shipping both. Stranger things have happened

deleted 3y ago

[deleted]

recursivedoubts 3y ago

https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/ https://hypermedia.systems/client-side-scripting/ https://hypermedia.systems/client-side-scripting/ I can understand the objection to the first request but the second is necessary to update state on the server. You could avoid the first request via scripting but the complexity, in my opinion in most cases, would not be worth it.

yawaramin 3y ago

htmx doesn't require you to make a request for UI changes. You can express your UI in terms of components which have built-in interactivity, eg dropdowns, inputs, details/summary tags, etc. You can go pretty far with those before you need to make a request.

wrapperup 3y ago

Agree on the first point, I think using JS makes more sense when you need to update some client state, like a dropdown or even that edit example. But htmx makes a lot more sense when you need to render some data from a server. In a SPA, you receive JSON, only to transform it back into HTML to render, so why not skip that middle step? You might find https://data-star.dev/ https://data-star.dev/ interesting, it takes some of the modern approaches (signals, etc) and mixes it with the efficiency of sending straight-up HTML, htmx style. It's very similar to using Alpine + htmx together.