5 ms·

Livewire, of course, having been heavily inspired by Phoenix LiveView https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html https://hexdocs.pm/phoenix_live

Livewire, of course, having been heavily inspired by Phoenix LiveView https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html

bnt 6y ago
Tho, LiveWire is AJAX, while LiveView and Stimulus Reflex are Sockets. LW is a pleasure to work with for small pieces of interactivity.
- dnautics 6y ago
  I believe (but could be wrong) that liveview degrades to http long poll.
  - deleted 6y ago
    [deleted]
  - sodapopcan 6y ago
    It does indeed!
    - dnautics 6y ago
      still not sure if the degrading code is there, but you can definitely configure it to USE long-poll.
banjomet 6y ago
How does Hotwire compare to Phoenix LiveView?
- flixic 6y ago
  For one, LiveView doesn't send HTML over the WebSocket channel. It sends a highly optimized diff structure that is applied to HTML.
- nickjj 6y ago
  > How does Hotwire compare to Phoenix LiveView? It seems the same to me. It's much different based on a preliminary reading of Hotwire's docs. Live View uses websockets for everything. If you want to update a tiny text label in some HTML, it uses websockets to push the diff of the content that changed. However you could use LV in a way that replaces Hotwire Turbo Drive, which is aimed at page transitions, such as going from a blog index page to contact form. This way you get the benefits of not having to re-parse the <head> along with all of your CSS / JS. However LV will send those massive diffs over websockets. Hotwire Turbo Drive replaces Tubolinks 5, and it uses HTTP to transfer the content. It also has new functionality (Hotwire Turbo Frames) to do partial page updates too instead of swapping the whole body like Turbolinks 5 used to do. Websockets is only used when you want to broadcast the changes to everyone connected and that's where Hotwire Turbo Streams comes in. IMO that is a much better approach than Live View, because now only websockets get used for broadcast-like actions instead of using it to render your entire page of content if you're using LV to handle page transitions. IMO the trade off of throwing away everything we know and can leverage from HTTP to "websocket all the things" isn't one worth making. Websockets should be used when they need to, which is exactly what Hotwire does. I could be wrong of course but after reading the docs I'm about 95% sure that is an accurate assessment. If I'm wrong please correct me!
  - sb8244 6y ago
    Fwiw, you can use long polling for LiveView if you wanted. That could completely remove websockets as everything happens over http. Hotwire will benefit from caching better than LiveView, because frames are distinct URLs. But I haven't personally need that.
    - nickjj 6y ago
      > Fwiw, you can use long polling for LiveView if you wanted. How does that work for page transitions? The docs don't mention anything about this or how to configure it. With Turbolinks or Hotwire Turbo Drive, the user clicks the link to initiate a page transition and then the body of the page is swapped with the new content being served over HTTP. With Turbo Frames the same thing happens except it's only a designated area of the page. In both cases there's no need to poll because the user controls the manual trigger of that event. How would LV do the same thing over HTTP? Everything about LV in the docs mentions it's pretty much all-in with websockets. Then there's progressive enhancement too as another difference. Turbo is set up out of the box to use controllers which means you really only need to add a tiny amount of code (2-3 lines) to handle the enhanced experience alongside your non-enhanced experience. For example you could have a destroy action remove an item from the dom when enhanced using Turbo Stream or just redirect back to the index page (or whatever) for the non-enhanced version. There's an example in the Turbo docs for that at https://turbo.hotwire.dev/handbook/streams https://turbo.hotwire.dev/handbook/streams if you search for "def destroy". But with LV wouldn't you need to create both a LV and a regular controller? That's a huge amount of code duplication. Although to be fair I would imagine most apps would require JavaScript to function so that one is kind of a non-issue for most apps, but it's still more true to the web to support progressive enhancement and the easier you can do this the better.
mstipetic 6y ago
I've just been getting into it, and am completely loving it, especially the elixir part. It feels like the whole OTP/erlang part of it (basically single codebase microservices and patterns that come with it) has proper engineering and principles behind it, and it's something I've been missing for a long time in our profession

Livewire, of course, having been heavily inspired by Phoenix LiveView https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html

bnt 6y ago

Tho, LiveWire is AJAX, while LiveView and Stimulus Reflex are Sockets. LW is a pleasure to work with for small pieces of interactivity.

dnautics 6y ago
I believe (but could be wrong) that liveview degrades to http long poll.
- deleted 6y ago
  [deleted]
- sodapopcan 6y ago
  It does indeed!
  - dnautics 6y ago
    still not sure if the degrading code is there, but you can definitely configure it to USE long-poll.

banjomet 6y ago

How does Hotwire compare to Phoenix LiveView?

flixic 6y ago
For one, LiveView doesn't send HTML over the WebSocket channel. It sends a highly optimized diff structure that is applied to HTML.
nickjj 6y ago
> How does Hotwire compare to Phoenix LiveView? It seems the same to me. It's much different based on a preliminary reading of Hotwire's docs. Live View uses websockets for everything. If you want to update a tiny text label in some HTML, it uses websockets to push the diff of the content that changed. However you could use LV in a way that replaces Hotwire Turbo Drive, which is aimed at page transitions, such as going from a blog index page to contact form. This way you get the benefits of not having to re-parse the <head> along with all of your CSS / JS. However LV will send those massive diffs over websockets. Hotwire Turbo Drive replaces Tubolinks 5, and it uses HTTP to transfer the content. It also has new functionality (Hotwire Turbo Frames) to do partial page updates too instead of swapping the whole body like Turbolinks 5 used to do. Websockets is only used when you want to broadcast the changes to everyone connected and that's where Hotwire Turbo Streams comes in. IMO that is a much better approach than Live View, because now only websockets get used for broadcast-like actions instead of using it to render your entire page of content if you're using LV to handle page transitions. IMO the trade off of throwing away everything we know and can leverage from HTTP to "websocket all the things" isn't one worth making. Websockets should be used when they need to, which is exactly what Hotwire does. I could be wrong of course but after reading the docs I'm about 95% sure that is an accurate assessment. If I'm wrong please correct me!
- sb8244 6y ago
  Fwiw, you can use long polling for LiveView if you wanted. That could completely remove websockets as everything happens over http. Hotwire will benefit from caching better than LiveView, because frames are distinct URLs. But I haven't personally need that.
  - nickjj 6y ago
    > Fwiw, you can use long polling for LiveView if you wanted. How does that work for page transitions? The docs don't mention anything about this or how to configure it. With Turbolinks or Hotwire Turbo Drive, the user clicks the link to initiate a page transition and then the body of the page is swapped with the new content being served over HTTP. With Turbo Frames the same thing happens except it's only a designated area of the page. In both cases there's no need to poll because the user controls the manual trigger of that event. How would LV do the same thing over HTTP? Everything about LV in the docs mentions it's pretty much all-in with websockets. Then there's progressive enhancement too as another difference. Turbo is set up out of the box to use controllers which means you really only need to add a tiny amount of code (2-3 lines) to handle the enhanced experience alongside your non-enhanced experience. For example you could have a destroy action remove an item from the dom when enhanced using Turbo Stream or just redirect back to the index page (or whatever) for the non-enhanced version. There's an example in the Turbo docs for that at https://turbo.hotwire.dev/handbook/streams https://turbo.hotwire.dev/handbook/streams if you search for "def destroy". But with LV wouldn't you need to create both a LV and a regular controller? That's a huge amount of code duplication. Although to be fair I would imagine most apps would require JavaScript to function so that one is kind of a non-issue for most apps, but it's still more true to the web to support progressive enhancement and the easier you can do this the better.

mstipetic 6y ago

I've just been getting into it, and am completely loving it, especially the elixir part. It feels like the whole OTP/erlang part of it (basically single codebase microservices and patterns that come with it) has proper engineering and principles behind it, and it's something I've been missing for a long time in our profession