https://htmx.org logo
Powered by
# htmx-general
  • m
    Just the big stuff, where you are moving data back and forth, that's when you want HTML and HATEOAS
  • m
    All that said, it would be good to start putting together patterns that help perceived performance
  • m
    Another tool to look into to improved load performance is @User 's extremely cool preload extension: https://htmx.org/extensions/preload/
  • g
    I was gonna shill for that one, but it’s so much nicer to hear you say it. 😇
  • g
    is there really a 100-200ms difference between mousedown and the normal event that triggers a request??
  • g
    Yes. It’s shocking how slow humans are.
  • g
    Try the links in the documentation. 🤓
  • g
    oh man that's wild.
  • g
    my timing is between 60-100 the majority of the time but i have a RTS gaming background 😛 and i see sometimes it creeping up towards the 150s. really interesting
  • g
    i think triggering the preload on hover is probably acceptable for most of my usecases and holy cow that feels nice
  • g
    Yes. Triggering in hover is much more aggressive, but it gives you almost a second, most of the time.
  • g
    https://alistapart.com/article/the-future-of-web-software-is-html-over-websockets/ btw, this is related to the htmx/hateoas stuff and is a very compelling read
  • s
    It is a very good article, it was the starting point for me into htmx
  • s
    I found a "solution" (I would rather call it "work-around") for the Playwright issue. If I add 
    time.sleep(0.1)
    before clicking, then it works. Nevertheless I think this kind of waiting should not be needed. Somehow Playwright clicks the button before the button is ready to get used: https://stackoverflow.com/a/66703730/633961
  • s
    I had a look at it. I agree to the HTML-over the wire part, but why WebSockets? I am happy with https. Does WebSocket simplify things for me? In my current context I never need to push from server to client. I am happy with http GET+POST.
  • s
    websockets are a techonology often misused, its a layer of complexity you should avoid unless you absolutely need to use it.
  • s
    This advice applies to pretty much anything, don't pull in adependency if you can write it in 30 lines of code.
  • s
    after a while the majority of dev time spend on a software project well be in bug fixing, your best guard against this is keeping complexity low.
  • m
    Exactly. It seems like some people just can't keep it simple. There is a cult of new in tech and the industry (especially web) doesn't naturally gravitate towards evolutionary changes, it always has to be a revolution. Couple that with FONLSS (fear of not looking sufficiently smart) and you end up with these rube goldberg technology solutions to what effectively boils down to appending an item to a list.
  • m
  • g
    There are certainly benefits the HTML over websockets.
  • m
    definitely so, but the majority of web apps don't need them for the majority of their functionality
  • m
    or at least that's my current impression 🙂
  • s
    please elaborate, I am curious. What are the benefits of HTML over websockets?
  • g
    Live data. Being able to update the dom via more than just user triggered events
  • m
  • m
    submitted @User debugger article again
  • m
    absolutely, where I start to get a little uneasy is when you try to stream your entire site interaction over them because there isn't a good standard there. it seems like whatever is being achieved over WebSockets should ideally over normal HTTP w/ something like Keep-Alive
  • m
  • g
    If i do a htmx.process on an element... Shouldn't the htmx:afterProcessNode be triggered?
1...195196197...1146Latest