4 ms·

How is it a good idea for every user interaction to hit the server?

kureikain 5y ago
it helps debugging and avoid any issue with cache(old JavaScript, unexpected JS error etc).
sodapopcan 5y ago
Websockets are crazy fast and the BEAM has crazy fast IO (at the expense of slower CPU-bound tasks, but that is another story). LiveView also minimizes (to an obsessive degree) the amount of data that flows over the socket. The payload is about exactly the size as the exact diff being rendered in the DOM (often times this is simply the `innerHTML` of a node). The advantage is stack simplicity. As stated in the beginning of the article, LiveView completely removes your need for any kind of API between your front and backend. It also makes it very easy (through JS hooks) to offload any interactions you want to the client if that makes more sense. But of course, if you end up offloading EVERY interaction to the client, you should be using a frontend framework--LiveView is very clear about not being suitable for every need--if you are building a super UI heavy app (like a text editor or painting app or the like), LiveView probably isn't going to cut it.
michalg 5y ago
This is not the idea. Interactions that don’t influence server-side state are suggested to be handled by JavaScript. Docs give an example for integrating AlpineJS, but you can use vanilla js or other libraries with little plumbing.
mrkurt 5y ago
A server round trip is a cost. It's not a good idea or a bad idea. I will pay the cost of a round trip if (a) it simplifies my life and (b) the cost is low enough. LiveView simplifies interactive app development (for me). Since I can run my Phoenix servers close to people, the round trip cost is usually very low.
erinan 5y ago
Whether it's a good idea or not really depends on your app, what you're trying to do, and who your users are. Now if you want to avoid round trips to the server for interactions such as opening a modal, you can! There are at least two ways to handle this - Javascript hooks that let you attach JS to your DOM, or the light AlpineJS framework. The latter is a perfect fit for Liveview and it's part of the unofficial go-to stack name PETAL - Phoenix Elixir Tailwind AlpineJS Liveview.
karmajunkie 5y ago
The first 20-odd years of the web were mostly this way... somehow we managed.

it helps debugging and avoid any issue with cache(old JavaScript, unexpected JS error etc).

Websockets are crazy fast and the BEAM has crazy fast IO (at the expense of slower CPU-bound tasks, but that is another story). LiveView also minimizes (to an obsessive degree) the amount of data that flows over the socket. The payload is about exactly the size as the exact diff being rendered in the DOM (often times this is simply the `innerHTML` of a node). The advantage is stack simplicity. As stated in the beginning of the article, LiveView completely removes your need for any kind of API between your front and backend. It also makes it very easy (through JS hooks) to offload any interactions you want to the client if that makes more sense. But of course, if you end up offloading EVERY interaction to the client, you should be using a frontend framework--LiveView is very clear about not being suitable for every need--if you are building a super UI heavy app (like a text editor or painting app or the like), LiveView probably isn't going to cut it.

michalg 5y ago

This is not the idea. Interactions that don’t influence server-side state are suggested to be handled by JavaScript. Docs give an example for integrating AlpineJS, but you can use vanilla js or other libraries with little plumbing.

mrkurt 5y ago

A server round trip is a cost. It's not a good idea or a bad idea. I will pay the cost of a round trip if (a) it simplifies my life and (b) the cost is low enough. LiveView simplifies interactive app development (for me). Since I can run my Phoenix servers close to people, the round trip cost is usually very low.

erinan 5y ago

Whether it's a good idea or not really depends on your app, what you're trying to do, and who your users are. Now if you want to avoid round trips to the server for interactions such as opening a modal, you can! There are at least two ways to handle this - Javascript hooks that let you attach JS to your DOM, or the light AlpineJS framework. The latter is a perfect fit for Liveview and it's part of the unofficial go-to stack name PETAL - Phoenix Elixir Tailwind AlpineJS Liveview.

karmajunkie 5y ago

The first 20-odd years of the web were mostly this way... somehow we managed.