Hacker News Reader

Comment by recursivedoubts | Hacker News Reader

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

View on HN

I just want to say thank you. Not only because of HTMX, but for being a model and showing what proper "Engineering" should be. Knowing trade - offs and accepting the fact no solution is perfect.

Although that may be because you have a background of Industrial Engineering.

I know there are other libraries which offer similar features (alpine.js), but none are as simple and focused as HTMX.

It seems like such an elegant solution I’m surprised more people haven’t started using it. It just works.

Man, you’re everywhere. I have a Montana’s restaurant in my city and I’m scared to go in because of you.

you should be

By queue only one additional request, do you mean cancel any existing queued request?

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

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.

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

>https://github.com/bigskysoftware/htmx/blob/1242977d11bebe56...

This seems to be a scenario where switch/case blocks could make the elif-trees a bit easier to read.

Also, the code could use some care about not going so deep into the Vs:

    // request headers
    if (requestAttrValues.noHeaders) {
    // ignore all headers
    } else {
      for (const header in headers) {
        if (headers.hasOwnProperty(header)) {
          const headerValue = headers[header]
          safelySetHeaderValue(xhr, header, headerValue)
        }
      }
    }

could just be:

    // request headers
    if (!requestAttrValues.noHeaders) {
      Object.keys(headers)
        .filter(hdr => headers.hasOwnProperty(hdr)) 
        .forEach(hdr => safelySetHeaderValue(xhr, hdr, headers[hdr]));
    }

Not even sure if that hasOwnProp check is needed, unless header keys are explicitly set to undef.

yeah i prefer just plain ol' if statements, i find them easier to debug

I had to read and think carefully enough about what you just explained (on second try!) to feel like I understood it, so I'm not at all surprised if other people are confused about or misinterpret what they are seeing! (I'm not an htmx user though).

Actually, I guess, then, OP just had an off-by-one error? Imagine requests [r0, r1, r2 ... rN], where r0 is still in flight... OP thought r0..r(n-1) would be cancelled, in fact just r1..r(n-1) will be cancelled (I think?). Or maybe OP understood it but just mis-described it!

I am curious to hear the reasoning/use cases for this choice being the default strategy.

It makes sense with GETs if you’re opinionated I think.

This way an in-flight request has a chance to complete (otherwise if you send requests too often none of them would ever finish), but any request that hasn’t started yet isn’t sent since it’s meant to be overwritten by the result of the later request anyway. Of course if you expect later requests to do anything other than idempotently replace the previous ones you’ll be surprised.

I’ll definitely pile on with the inheritance causing issues. It made me feel like unsetting them constantly defensively.

You can disable it globally, see htmx.config.disableInheritance:

https://htmx.org/docs/#inheritance

I cannot express the pleasure I felt seeing prices in my local currency automatically, without the Shopify "Zoinks! Looks like you're on our American store, would you like to change to our Polish store?" modal I've come to know and hate. Thanks.

Often changing to local currency isn't just a straightforward x*(exchange rate). There could be weird taxes applied

And regional pricing, although maybe less relevant for hardware

the good thing about htmx / javascript or even a framework like Vue - is that the authors know the web browser is not a 'pure' platform as React people try pretend it to be.

because of the event system on the web - things yeah are weird.

And thanks for bringing intercooler.js / htmx as alternatives to a crazy world.

yeah, inheritance enabled by default bit me in the ass more than once. With template engines you end up trying to debug some weird behavior and it takes some time for you to realize somewhere up in the tree on a different file there's an hx-* tag being inherited.

I should have disabled it early in the project, too late now.

I also still haven't figured out how to properly use the "save history to local storage" thing. Often there has been a server state change between the user navigating away and clicking the back button and I see no option other than disabling the thing altogether.

Reply on news.ycombinator.com