[HN Gopher] A modest critique of Htmx
___________________________________________________________________
A modest critique of Htmx
Author : wibwobble12333
Score : 91 points
Date : 2024-10-08 20:19 UTC (2 hours ago)
(HTM) web link (chrisdone.com)
(TXT) w3m dump (chrisdone.com)
| recursivedoubts wrote:
| These all look reasonable to me.
|
| I especially go back and forth on attribute inheritance (it can
| be disabled via the htmx.config.disableInheritance option)
|
| Three of the criticisms boil down to the fact that client-side
| state doesn't always play well w/htmx swaps (especially the
| simple ones) which is absolutely true.
|
| And events can get crazy. They are powerful, but crazy and at
| times hard to debug. Such is event-driven life.
|
| The one thing I don't agree with is the default queuing mode: it
| is not to cancel an existing request and replace it. Instead it
| is to keep the current request in flight and queue one and only
| one additional request. I'd need to sit down w/them to see if
| they were misinterpreting something, using the hx-sync attribute
| to implement the behavior they mention, or if there is a bug.
|
| I would also like to take this opportunity to market our mug for
| people who don't like htmx:
|
| https://swag.htmx.org/products/htmx-sucks-mug
| nickpeterson wrote:
| I'll definitely pile on with the inheritance causing issues. It
| made me feel like unsetting them constantly defensively.
| recursivedoubts wrote:
| You can disable it globally, see
| htmx.config.disableInheritance:
|
| https://htmx.org/docs/#inheritance
| dullcrisp wrote:
| By queue only one additional request, do you mean cancel any
| existing queued request?
| recursivedoubts wrote:
| the code is a little gnarly, but if you don't specify
| anything the default behavior is to keep the "last" event
| that comes in while a request is in flight:
|
| https://github.com/bigskysoftware/htmx/blob/1242977d11bebe56.
| ..
|
| and that dumps the existing request queue and puts request
| created by the last event in it by itself:
|
| https://github.com/bigskysoftware/htmx/blob/1242977d11bebe56.
| ..
|
| we don't cancel the current request or issue the next request
| until the current request finishes
|
| but there could be a bug in the code, for sure, it's pretty
| crazy
| dullcrisp wrote:
| I thought they were complaining that any request is being
| cancelled by a subsequent one, since they wanted all the
| requests they made to go through (presumably the requests
| are altering state?) Probably I misunderstood what was
| meant by "losing work" though.
| recursivedoubts wrote:
| yeah i don't know if I understand what they were saying
| either
|
| regardless if you have a lot of events flying around then
| updating the UI via hypermedia exchanges is going to be a
| bad idea, as I mention here:
|
| https://htmx.org/essays/when-to-use-hypermedia/#if-your-
| ui-s...
| ricardobeat wrote:
| > Even morphdom overwrites some things you'd expect it not to, so
| we had to patch it to avoid messing with input elements, and
| details elements.
|
| Would love to hear more about this issue. Preserving the state of
| elements like input or detail is the main function of libraries
| like morphdom, something must have gone wrong there.
| recursivedoubts wrote:
| at the end of the day morphdom (and my own algorithm,
| idiomorph) can only do so much, because the current DOM APIs
| nuke much of the state of nodes when they disconnect from the
| DOM
|
| if you look at the algorithms they give up very quickly and
| simply merge the new nodes in once matching doesn't work at a
| certain level because of this
|
| there is a new API coming down the pipe, moveBefore(), that
| will allow much better morphing/preservation in general:
|
| https://github.com/noamr/dom/blob/spm-explainer/moveBefore-e...
|
| htmx supports it today if you enable it in chrome canary:
|
| https://htmx.org/examples/move-before/
| jasoncartwright wrote:
| After hearing about it for years, and it apparently being popular
| in the Django community, I tried htmx for the first time just
| this morning on a very simple task in an admin interface.
|
| It's easy to put unobtrusively in place, fun to play with, and it
| worked. Reminded me of using jQuery for the first time. Would I
| use it for a complex and involved project? Initial impressions
| suggest probably not.
| candiddevmike wrote:
| It's jQuery but for HTML. Same spaghetti result, different
| language.
| recursivedoubts wrote:
| maybe so, but sometimes spaghetti is delicious:
|
| https://htmx.org/essays/a-real-world-react-to-htmx-port/
| lucis wrote:
| We have been using HTMX to create performant storefronts and the
| results are satisfactory.
|
| https://farmrio.deco.site/ is one of the largest clothing
| retailers in Brazil and all the frontend interactions use HTMX,
| alongside a partial rendering strategy we developed.
|
| More info at https://deco.cx/en/blog/htmx-first-class-support
| lelandfe wrote:
| Love how good the CLS is. I wonder if you can deal with flashes
| of white during navigation with the new View Transitions API
| yawaramin wrote:
| > React and Htmx do not interact nicely.
|
| I want to dig into this a bit. React of course maintains its own
| rendered part of the DOM and htmx trying to reach into and change
| any part of that DOM is not going to go over well. It's just
| going to be replaced with React's rendering again on the next
| render cycle.
|
| htmx provides two points at which it can interact with other
| libraries or frameworks: DOM events and CSS classes. I don't see
| any problem with classes, but React's synthetic events would
| probably not work well with htmx (or any other non-React library
| really). Maybe frameworks like Preact which use _real_ DOM events
| would work better.
| dsego wrote:
| > Htmx-in-React?: The server sends a JSON blob that React
| converts into virtual DOM components.
|
| The author should try inertia.js, it has server-side routing and
| react templates.
| sauercrowd wrote:
| > The default queuing mode is bonkers
|
| > By default, Htmx will cancel requests that are in-flight if you
| trigger another request on the same queue (element).
|
| This seems like the only default that's reasonable to me
|
| don't know if the author has a specific example in mind, but if a
| user submits an input, changes that input mid-request and submits
| again the request needs to be cancelled, otherwise the UI will be
| inconsistent by showing a response to an outdated input
|
| Just processing one response after the other won't be possible if
| a response swaps out content with different IDs, so a second
| response won't be able to be swapped out in the same way
| hahahacorn wrote:
| Is there an equivalent to Turbo Mount for Htmx?
| https://evilmartians.com/chronicles/the-art-of-turbo-mount-h...
|
| I think it's one of the best ways to use Hotwire/Turbo. Default
| to Hotwire to whatever degree of understanding you have, and as
| soon as it feels like HTMX/Hotwire isn't the right tool, you can
| easily switch to your framework of choice.
| sauercrowd wrote:
| Very much agree with you on this - htmx (turbo, hotwire,
| alpine,...) are not trying to replace all your client side
| logic.
|
| It's a spectrum of interactivity, and we should try to pick the
| best (whatever that may mean) tool possible for the job -
| sometimes that's hx-boosted links, sometimes it's a react app
| stavros wrote:
| > An attractive future direction might be to re-implement Htmx in
| React: The server sends a JSON blob that React converts into
| virtual DOM components.
|
| Isn't this exactly what HTMX was replacing? The client needing to
| have a ton of logic and state?
___________________________________________________________________
(page generated 2024-10-08 23:00 UTC)