4 ms·

trying to figure out how this compares to Phoenix's frameworks LiveView, does HTMx use websockets to communicate state change? Seems like I could just end up us

trying to figure out how this compares to Phoenix's frameworks LiveView, does HTMx use websockets to communicate state change? Seems like I could just end up using HTMx in lieu of learning Elixir and Phoenix

sixhobbits 5y ago
HTMx supports web sockets [0], but my understanding is that it isn't really an alterantive to something like LiveView. HTMx is more about simplicity - an easy alternative to AJAX that doesn't require a full-blown front-end framework. It isn't really designed for optimized real-time communication and long-running connections, but you could probably use it for that if you wanted. [0] https://htmx.org/extensions/web-sockets/ https://htmx.org/extensions/web-sockets/
- tomatowurst 5y ago
  I see its more fair to compare to AJAX...then I'm curious in what ways does liveview create "magic" over HTMx here, to my knowledge the mechanics here with HTMx seem a lot simpler and less bloat doing the same things. With LiveView, it seems to be just sending application state up and down the websocket wire, does HTMx not do this as well if it was setup that way with WS?
  - sixhobbits 5y ago
    Good question - if you do some digging, I'd love to read about how they stack up!
recursivedoubts 5y ago
htmx is a lower-level extension of HTML, with no server-side component to it it tries to extend HTML as a hypermedia, which makes it more general (it can be used with any backend that produces HTML) but also more work to achieve things that, in live view, work magically
- tomatowurst 5y ago
  what sort of magic does LiveView do here that HTMx doesn't? seems like the difference here is that the article sends a server rendered partial HTML down the wire with HTMx sprinkled on it that gets rendered on the client side. From my basic understanding, LiveView sends HTML to client first, establishes bi-directional WS connection, and proceeds to send JSON data to the client and synchronizes the app state via sending diffs over WS.
  - recursivedoubts 5y ago
    yep, exactly, so LiveView needs to have that web socket doing diffs between the client and server side htmx is just html++: any element can make any sort of HTTP request (GET, DELETE, etc.) based on any event and replace any other element in the DOM. much simpler and "dumb" when compared w/ liveview, with no particular server-side implementation implied
deniz-a 5y ago
The way I think about it is htmx takes the "full page refresh" user experience & programming model, and expands it to "partial page refresh" and goes from there. It also patches some annoying gaps in html, like forms only being able to GET and POST. Finally, it lets you trigger these requests with things other than clicking a link/submitting a form. LiveView tries to replicate the architecture of a native app toolkit and slap a network boundary in the middle of it, whereas htmx tries to keep the programming model of Web 1.0 apps while radically expanding the user experience possibilities

sixhobbits 5y ago

HTMx supports web sockets [0], but my understanding is that it isn't really an alterantive to something like LiveView. HTMx is more about simplicity - an easy alternative to AJAX that doesn't require a full-blown front-end framework. It isn't really designed for optimized real-time communication and long-running connections, but you could probably use it for that if you wanted. [0] https://htmx.org/extensions/web-sockets/ https://htmx.org/extensions/web-sockets/

tomatowurst 5y ago
I see its more fair to compare to AJAX...then I'm curious in what ways does liveview create "magic" over HTMx here, to my knowledge the mechanics here with HTMx seem a lot simpler and less bloat doing the same things. With LiveView, it seems to be just sending application state up and down the websocket wire, does HTMx not do this as well if it was setup that way with WS?
- sixhobbits 5y ago
  Good question - if you do some digging, I'd love to read about how they stack up!

recursivedoubts 5y ago

htmx is a lower-level extension of HTML, with no server-side component to it it tries to extend HTML as a hypermedia, which makes it more general (it can be used with any backend that produces HTML) but also more work to achieve things that, in live view, work magically

tomatowurst 5y ago
what sort of magic does LiveView do here that HTMx doesn't? seems like the difference here is that the article sends a server rendered partial HTML down the wire with HTMx sprinkled on it that gets rendered on the client side. From my basic understanding, LiveView sends HTML to client first, establishes bi-directional WS connection, and proceeds to send JSON data to the client and synchronizes the app state via sending diffs over WS.
- recursivedoubts 5y ago
  yep, exactly, so LiveView needs to have that web socket doing diffs between the client and server side htmx is just html++: any element can make any sort of HTTP request (GET, DELETE, etc.) based on any event and replace any other element in the DOM. much simpler and "dumb" when compared w/ liveview, with no particular server-side implementation implied

deniz-a 5y ago

The way I think about it is htmx takes the "full page refresh" user experience & programming model, and expands it to "partial page refresh" and goes from there. It also patches some annoying gaps in html, like forms only being able to GET and POST. Finally, it lets you trigger these requests with things other than clicking a link/submitting a form. LiveView tries to replicate the architecture of a native app toolkit and slap a network boundary in the middle of it, whereas htmx tries to keep the programming model of Web 1.0 apps while radically expanding the user experience possibilities