https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • f
    There's a configuration data structure that defines how data flows through the system - and webservers are just nodes in that data flow graph. You can have different webservers for different UIs - some for the operator of a particular vessel, others for people monitoring an entire fleet.... the webserver just displays whatever resources get sent to it over the messaging middleware.
  • f
    So as far as the webserver is concerned, it's basically just a dumb cache with some additional functionality -- like the ability to send out an SSE event when a resource changes.
  • f
    Feeding into the webserver are several other components in the dataflow graph. each corresponding to some UI component, or some computation being done somewhere.
  • f
    This means you can have V1 software on one boat, and the UI will display the V1 UI component ... and V2 software on another boat, and the UI will display the V2 UI component ... and both can be on the same page.
  • g
    I think I follow you. Sounds like a lot of network connections to maintain 🙂
  • f
    They're all peer-to-peer, so there's no central broker.
  • g
    I guess that's the real issue. Peer-to-Peer changes the game.
  • f
    The configuration data structure just tells each peer which other peers it needs to communicate with.
  • g
    I'm working with ActivityPub, which is a distributed (they say Federated) protocol. So, similar, but vastly different scale.
  • f
    So there's no peer discovery (yet).
  • f
    The ambition is to make a control system for autonomous global logistics ...
  • g
    In that model, everyone has their own clients (and versions) but promises to send messages around via the same basic (extensible) protocol. So, the rendering is all done in a single place for each individual node in the network, even though they might have different software versions.
  • f
    Yup.
  • f
    Similar.
  • g
    Call me old fashioned, but I think centralizing something gives you a leg up on managing the overall complexity.
  • f
    I centralize the configuration and lifecycle (start/stop/pause) control ...
  • f
    Does that count?
  • g
    When you have something to release, make sure to share it with the rest of the HTMX crowd. I know everyone would be super-excited to see something like this being deployed with this toolset.
  • g
    It absolutely counts 🙂
  • f
    Yeah ... my code is super wierd though ... mainly because (at the moment) all the HTML/HTMX is generated in Python using the dominate library ...
  • f
    So I end up with stuff like this:-
  • f
    Copy code
    with tag.div(data_hx_sse = sse_cmd_connect):
    with tag.div(data_hx_get     = xact.lib.web.util.url(id_content),
                 data_hx_target  = '#' + id_content,
                 data_hx_trigger = ', '.join((sse_content, 'load')),
                 **_class('min-h-screen',
                          'flex',
                          'items-center',
                          'justify-center')):
        tag.div(id = id_content)
  • f
    So I can write python modules that generate fragments of HTMX.
  • g
    Yeah, it's like -- how many sets of mirrors do I have to look through to see my actual output?
  • f
    Very much.
  • g
    I have zero experience in Python. I'm sure there are some good templating libraries for it, though. Do they perform well? Or are they a lot slower than Dominate?
  • f
    But I've got a ton of component level tests, and it's easy enough to stick probes into the dataflows ...
  • f
    I don't really care about the speed ... because the HTML is essentially rendered once....
  • f
    Or not rendered very often.
  • f
    What I'm interested in is being able to generate it more dynamically.
1...777879...1146Latest