https://htmx.org logo
Powered by
# htmx-general
  • g
    Oops. Sorry y'all. I didn't realize you were waiting on me.
  • g
    Honestly, I'm not very familiar with WebSockets, and it looks like you already did the core research. Sorry I wasn't more help 😦
  • g
    You should be able to include headers on the initial request that creates the WebSocket. But I believe everything after that is just a raw data channel. So, you can put anything you want in there, but there's no sense of "headers" in the messages in either direction.
  • g
    We might consider looking at various standards that people implement on top of WebSockets, but that might be better as an extension (or hyperscript library). Here's a start that I found down that rabbit hole: https://dev.to/idanarye/are-there-any-api-specification-formats-for-websockets-2mkk
  • s
    Why not split htmx from websocket handling? So that websocket support is provided by a plugin, and the htmx core does not know anything about websockets. Then the plugin can build upon a stable library like socket.io. What do you think?
  • m
    not a bad idea, but it isn't an area that is super amenable to being split out
  • t
    So I guess the two main options for adding more functionality to the websocket support are either to use some sort of protocol on top of websockets, or to split websockets out into an extension that uses another library that already can do some of this stuff. Does that sound right? Both of them sound like a decent chunk of work.
  • s
    My gut feeling is that 95% developers using htmx don't use websockets. But I can wrong. It would be nice to have numbers here.
  • m
    yes, I think a halfway point would be to write an extension that allowed for a JSON protocol format: https://github.com/bigskysoftware/htmx/blob/665fc4bda76f97c0a023f96e65fba3527fec6a3b/src/htmx.js#L1120
  • m
    that would keep the default web socket support simple, but allow you to do some more advanced protocols when necessary
  • m
    lol not sure why I keep sticking you with the websocket stuff 🙂
  • t
    I will have a go at this at some point :). I'm working on this as part of an internal prototype for a new product we're building where I work, so it might be a few weeks before I get round to having anything working!
  • m
    no prob, when you start in on it check back and we'll assist as best we can
  • a
    Hello ! I'm new there, and I'm Ux Designer. I have this idea of creating a game dev in js, this tool could help ? Naive question thanks 🙂
  • g
    Howdy @User - it would depend on the game. I think htmx would work great for a map- or story-based game. It's definitely going to let you down if you're making a 3D shooter like Halo or Team Fortress 🙂
  • a
    i was thinking more like agar.io maybe mix with three.js
  • g
    Cool examples. I'm not an expert with them, so it's hard for me to say. But, htmx is great for loading dynamic data -- specifically DOM nodes -- into your page based on browser events.
  • g
    You can usually integrate with client-side libraries pretty well, though you usually have to write a little bit of "glue" code so that each library knows when things have been changed by the other.
  • g
    If you're making an online game like agar, you might also look into WebSocket support (in both htmx and hyperscript) for real-time communication between all of the different players.
  • g
    Good luck!
  • g
    htmx might not be appropriate for the gameplay, but it's great for a login page or leaderboard
  • a
    ok thanks Deniz
  • a
    hyperscript neither ?
  • g
    i'm not sure if it's performant enough for that, but it's surprised me before
  • g
    if you want to do a similar paradigm of html over the wire, but performant enough for live gameplay rendering, phoenix liveview is explicitly being used for such things
  • s
    There is a new question at StackOverflow: https://stackoverflow.com/questions/67198443/settling-in-htmx
  • r
    So I was just testing out hotwire turbo and one of the things I like about it is that when content gets swapped out and the body replaced, the entire head element gets diffed in the dom and so not only is the title tag replaced but all the other parts in the head that change from page to page as well. Like for example meta descriptions and open graph properties which are are important for SEO and social media. From what I tested a while back with HTMX, this wasn't the case using hx-boost on the body element. Has that changed or was I doing something wrong?
  • m
    that's right, they do a much better job with the header. HTMX is more focused on straight HTML fragment swapping. Simpler, but not as nice an experience if you are just putting it on top of a regular web site. I'd like to look at that functionality and add it over time, if it doesn't blow htmx complexity out
  • r
    That would be awesome!
  • m
    I just want to keep the complexity under control
1...226227228...1146Latest