https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • m
    (I believe this was a feature you wanted/implemented?)
  • m
  • h
    yeah - I was planning on spending some time tmr reading through the notes
  • h
    from talking about it last night it certainly seems it's firing more events than it needs to
  • h
    I don't think the redirect should alter the history at all - it should be transparent like with a 3xx redirect
  • l
    Sorry - day job has been time consuming today. I'll take a look this weekend and let you know if I think of anything. I'm fluent in Java - I just don't use it for my side work where I also use htmx. 🙂
  • a
    Big improvement on this idea I had earlier: Why make a single server host the entire virtual dom? What if instead, there were front end microservices, each responsible for only a piece of the page? If a dynamic web app can have a modular interface, the generation of the modules can be distributed, right?
  • a
    Instead of a server maintaining the state if a big virtual dom, stateless micro-services could generate their piece based on given parameters on the fly
  • g
    ... this message goes so starkly against the culture of this server i can't express it
  • a
    Oop 💀 😅
  • g
    "microservice", "virtual dom", all the dirty words :]
  • g
    i think this can be made to fit in with htmx in some way though
  • g
    if CORS wasn't an issue you could have different servers generating html fragments that all get swapped into one page
  • a
    Another acronym I’m not familiar with lol https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
  • a
    To be fair, I thought a big server side stateful virtual dom was an ugly idea, which is what spurred this lol
  • a
    I think it’s a good ideal that servers are stateless with regards to the client
  • g
    shared state between server and client is something we're trying to eliminate
  • a
    Yeah
  • g
    i think the hitch with the server virtual dom idea, microservices or not, is that the server needs a continuous session per user instead of self-contained request/response cycles
  • a
    Exactly
  • g
    but!
  • g
    the erlang runtime was designed for phone carriers, which means it can hold on to lots of ongoing processes
  • g
    thus the Phoenix web framework can do the thing i sent you earlier
  • g
    the way that works is it has a separate greenthread for each user
  • g
    the server holds the canonical dom state. the client sends events, and receives dom patches
  • a
    It’s always interesting when an idea I have already exists lol
  • g
    the phoenix/elixir/erlang/BEAM cinematic universe is pretty cool
  • j
    Fun fact: Java had support for green threads, but was removed in JDK 1.1. And now the biggest awaited feature in Java for March 2023 - Project Loom is Erlang style green threads.
  • g
    I have forms which send POST requests to Django views, which in return send back HX-Trigger headers and the frontend responds as expected. The event controller is tied to body element. But when a button sends a delete request, the frontend recieves the same HX-Trigger headers but the frontend does not react as expected. I believe that the button itself is consuming the event and is not letting the event bubble up to the body. How can I fix this?
  • g
    I have checked the network response and the headers are coming back from the backend just as they should, its only that the frontend eventhandlers are not reacting to the event, even though they are reacting to the same events when the events come after a form POST.
1...973974975...1146Latest