https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • l
    I might do that, yeah. It would be nice to avoid the additional complexity, to be sure
  • b
    It might be a good option. It helps me not to let 5% of the requirements drive 100% of my design.
  • l
    I do also plan to make a mobile frontend, but that should be a separate API anyway in most cases
  • l
    So, it shouldn't factor in too much
  • o
    I just was interested in how qwik registered event listeners & dynamically loads individual clientside behaviors as outlined in the article and more specifically why htmx didn't implement a similar mechanism, that is all. I wasn't considering replacing htmx for qwik or the like.
  • r
    So, basically this picture
  • r
    That's actually an interesting idea
  • r
    I think this could be considered for htmx 2.0
  • o
    Yes, this exactly is what I meant
  • r
    There would be some shenanigans with hx-trigger syntax
  • r
    htmx is capable of handling any js event (including custom events)
  • r
    Whereas the code in the image iterates over predetermined list of events
  • r
    likely generated build-time, but don't quote me on that
  • r
    plus, there is a number of synthetic htmx-specific events (like polling events) and also events modifiers
  • r
    I'm struggling to see how to fit it all together rn
  • r
    yea, some htmx features (polling, HX-Trigger header to name a couple) are quite an obstacle to this approach, I don't see a way to bypass tree-walking
  • o
    The only obstacle I see is the polling stuff
  • o
    And how parsing the syntax htmx uses for hx-trigger every time it triggers may be a bit costly vs registering it once, though that can have some workarounds (like setting an attribute on an element if the individual event for it is registered so the "global listener" doesn't consider it)
  • m
    agreed, that's an interesting way to make scripting lazy
  • m
    although you wonder if action latency is an issue
  • o
    I guess you're trading initial page load for action latency
  • o
    Which seems bad until you have large apps I guess
  • m
    It Depends™️
  • b
    To get the Qwik magic, I think it requires the backend to play ball, right? So it’s not strictly an HTMX thing. HTMX can be the frontend piece, but the backend has to be built to provide resumable responses.
  • b
    Is resumability in hypermedia just hypermedia with fancier controls? 🤔
  • r
    I did some surface-level profiling of event listeners being set up. This is 1200 buttons being fetched with hx-get. I'm no performance pro by any means, but in this 400ms span: 200ms is network (a half) 60 ms cleanup and swapping 60 ms paint 60 ms settling, of which - 16ms addtriggerhandler (~0.013ms per button) - 34ms events being dispatched Again, I'm not a perf pro and this is very basic setup, but the way I see this, adding event listeners is not a bottleneck
  • r
    that said, in this particular setup this is 1200 event listeners, 1199 of which never fires, which is obviously suboptimal
  • r
    so there is a clear benefit of avoiding all the useless work
  • o
    I've had similar results for my own large tests like 2000 table rows. Guess it doesn't matter as much as the blog claims.
  • o
    And I presume for events whose target is the entire document it makes even less sense, or for events that fire very frequently like 
    scroll
    or 
    mouseover
    , to handle the dynamic finding every single time with javascript instead of registering the event once and letting the browser figure it out in a probably more efficient mnner
1...985986987...1146Latest