4 ms·

I am not familiar with LiveView, so I'm curious. Looks like it processes UI actions server side. So, are all client interactions sent through the websocket? I

I am not familiar with LiveView, so I'm curious. Looks like it processes UI actions server side. So, are all client interactions sent through the websocket? I remember years/decades ago we used to do that with ASP.NET, where every single component interaction was handled by the server. How is this different / better?

bcardarella 3y ago
I never used ASP.net so I cannot offer a comparison about what is "better" but your assumption is correct that diffs are through a WS and merged client-side. What this has resulted in is actual order of magnitude of implementation time reduction over the crazier SPA complexity available today. Less time to build, less cost to the company, less bugs in the long run, and a single place to manage and reason about state. It's a win.
- bornfreddy 3y ago
  But isn't there a delay in UI responses because of latency then?
  - cess11 3y ago
    Sure, it's not for a smooth user experience over 2G connection, if that's your audience you'd use ordinary template rendering with Phoenix, or use it for a JSON API and build a JS client that talks to it.
    - bornfreddy 3y ago
      I can see the next big thing coming: no latency! Render in client! :)
      - cess11 3y ago
        Seems maybe messy to have templating in the client but I'd take a look if someone has done it.
        swarm_commerce 2y ago
        https://github.com/dwyl/phoenix-liveview-todo-list-tutorial https://github.com/dwyl/phoenix-liveview-todo-list-tutorial
  - cmoski 3y ago
    You keep frontend UI changes that don't affect state in the frontend. If you don't need the server then you don't waste your user's time with trips to the server. If you need server, you can do things on the frontend at the same time you send the request, e.g. hide something, add/remove a class.
cess11 3y ago
This is run on the BEAM VM, so a LiveView is a lightweight process hooking up the view to the bells and whistles of the BEAM, including relatively easy Pub/Sub, soft-realtime monitoring and so on. Some people think it's kind of nice to have one programming language for everything, including queues, cache, database queries, client layout, business logic.
victorbjorklund 3y ago
You could do that but in general no not in production. If you just have a UI update that server doesnt need to know about (for example opening a menu) then you do it with javascript.
Muromec 3y ago
Vanilla live view does exactly that, but I think the point of trowing svelte (or any other frontend) into the mix is to keep some updates frontend-only. It seems to go against the wisdom of the last few decades, but the network latency seems to permit it now. Throw some edge computing to the mix and maybe it's all a good idea.

bcardarella 3y ago

I never used ASP.net so I cannot offer a comparison about what is "better" but your assumption is correct that diffs are through a WS and merged client-side. What this has resulted in is actual order of magnitude of implementation time reduction over the crazier SPA complexity available today. Less time to build, less cost to the company, less bugs in the long run, and a single place to manage and reason about state. It's a win.

bornfreddy 3y ago
But isn't there a delay in UI responses because of latency then?
- cess11 3y ago
  Sure, it's not for a smooth user experience over 2G connection, if that's your audience you'd use ordinary template rendering with Phoenix, or use it for a JSON API and build a JS client that talks to it.
  - bornfreddy 3y ago
    I can see the next big thing coming: no latency! Render in client! :)
    - cess11 3y ago
      Seems maybe messy to have templating in the client but I'd take a look if someone has done it.
      - swarm_commerce 2y ago
        https://github.com/dwyl/phoenix-liveview-todo-list-tutorial https://github.com/dwyl/phoenix-liveview-todo-list-tutorial
- cmoski 3y ago
  You keep frontend UI changes that don't affect state in the frontend. If you don't need the server then you don't waste your user's time with trips to the server. If you need server, you can do things on the frontend at the same time you send the request, e.g. hide something, add/remove a class.

cess11 3y ago

This is run on the BEAM VM, so a LiveView is a lightweight process hooking up the view to the bells and whistles of the BEAM, including relatively easy Pub/Sub, soft-realtime monitoring and so on. Some people think it's kind of nice to have one programming language for everything, including queues, cache, database queries, client layout, business logic.

victorbjorklund 3y ago

You could do that but in general no not in production. If you just have a UI update that server doesnt need to know about (for example opening a menu) then you do it with javascript.

Muromec 3y ago

Vanilla live view does exactly that, but I think the point of trowing svelte (or any other frontend) into the mix is to keep some updates frontend-only. It seems to go against the wisdom of the last few decades, but the network latency seems to permit it now. Throw some edge computing to the mix and maybe it's all a good idea.