6 ms·

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.
    - sb8244 6y ago
      It uses long polling over http. To be clear it's not restful http, but it's not websockets. I believe that Chris doesn't believe it's important for most people so there are no directions right now. Could be wrong there, I'm not Chris. Page changes are still initiated by the client in LiveView (although can be server initiated) LiveView is just channels under the hood. Once you consider that, long polling may seem more obvious
      - chrismccord 6y ago
        Since LiveView is built on phoenix channels, it's the same story. Simply pass the `transport: LongPoll` option to the LiveSocket constructor and you're now using long polling with LV :)

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.
  - sb8244 6y ago
    It uses long polling over http. To be clear it's not restful http, but it's not websockets. I believe that Chris doesn't believe it's important for most people so there are no directions right now. Could be wrong there, I'm not Chris. Page changes are still initiated by the client in LiveView (although can be server initiated) LiveView is just channels under the hood. Once you consider that, long polling may seem more obvious
    - chrismccord 6y ago
      Since LiveView is built on phoenix channels, it's the same story. Simply pass the `transport: LongPoll` option to the LiveSocket constructor and you're now using long polling with LV :)