5 ms·

How would you handle animations and more interactive page elements? Is it possible to reach the same kind of UI as something built with Svelte/Vue/React or are

by POiNTx 5y ago

How would you handle animations and more interactive page elements? Is it possible to reach the same kind of UI as something built with Svelte/Vue/React or are there certain limitations?

mrkurt 5y ago
If you're within ~50ms of the liveview server you can get really close to client side interaction responsiveness. Animations are still better off handled client side, though you can go far with web components and liveview updated HTML: https://github.com/hmans/three-elements https://github.com/hmans/three-elements
- 1_player 5y ago
  Don't need to be so close. AFAIK when Live View was announced, Jose Valim and Chris McCord tested a 60 fps server side rendered animation from across the pond and it was perfectly smooth. Definitely not it's intended use case, but it works perfectly on regular Internet latencies in the 100-300ms ranges.
  - sa1 5y ago
    Server rendered animation sounds less susceptible to latency than interactive elements.
    - 1_player 5y ago
      How so? 60fps means it requires constant updates every 16.6ms or you'd get a very noticeable frame delay or skip. Again, not really the best use of Live View, because it'd be very hard to guarantee that stability for all users in different Internet conditions. Whereas interactive elements just require an update in 100ms or 200ms after the user pressed a button, which is not that hard to achieve.
      - sa1 5y ago
        We’re not measuring latency due to processing here. We’re measuring latency due to round trips. For server rendered animations, all the frames might be delayed due to geographical distance, but the time gap between the arrival of individual frames is not affected by geographical distance. The server is not waiting for the client to request the next frame, it’s always pushing. For the user, it’s similar to watching a streaming video after letting it buffer a bit. For interactive elements, every interaction has to go through the round trip. So the gap between interactions is affected by distance. Server rendered games would suffer much more than server rendered animation.
mcintyre1994 5y ago
The LiveView is just a HTML page so you can have whatever CSS/JavaScript you like on the client side for animations and interactivity. Talking to the server is opt-in and you’d basically do it wherever you’d usually make an API call from React etc. The go-to for JS in LiveView seems to be Alpine (https://github.com/alpinejs/alpine https://github.com/alpinejs/alpine) but I haven’t got around to trying that out myself yet.
- rkangel 5y ago
  I'm not sure it's really 'opt in' - talking to the server is the default way of changing what's on your screen. Adding a whole front end framework is going to conflict with what's going on with the LiveView elements. Alpine is the default because it's good for "sprinkling" little elements of interactivity into an otherwise statically rendered page.
staticelf 5y ago
You can come a long way with css animations or svg-updates. There are limitations and they are mostly connected to the latency part. For example, if you want a 60 fps animation created and the server is far far away, like the other side of the globe that could be an issue or if your connection is bad. With liveview, you cannot create offline apps without javascript for example. That is a big limitation. But since most apps don't really require offline capabilities that is not really a big issue. I have however tried to use a liveview hosted in Sweden from Japan (which is basically on the other side of the globe) and I didn't experience any noticable latency for simple html updates. I think if you're making a game, you'll still need to use javascript. But if you are just making a simple crud app you may not need it for at least most of the stuff. I still think creating modals or things that the user expects to be instant should perhaps still be done in javascript but for all the server requested data liveview is probably faster than your average SPA.

by POiNTx 5y ago

How would you handle animations and more interactive page elements? Is it possible to reach the same kind of UI as something built with Svelte/Vue/React or are there certain limitations?

mrkurt 5y ago

If you're within ~50ms of the liveview server you can get really close to client side interaction responsiveness. Animations are still better off handled client side, though you can go far with web components and liveview updated HTML: https://github.com/hmans/three-elements https://github.com/hmans/three-elements

1_player 5y ago
Don't need to be so close. AFAIK when Live View was announced, Jose Valim and Chris McCord tested a 60 fps server side rendered animation from across the pond and it was perfectly smooth. Definitely not it's intended use case, but it works perfectly on regular Internet latencies in the 100-300ms ranges.
- sa1 5y ago
  Server rendered animation sounds less susceptible to latency than interactive elements.
  - 1_player 5y ago
    How so? 60fps means it requires constant updates every 16.6ms or you'd get a very noticeable frame delay or skip. Again, not really the best use of Live View, because it'd be very hard to guarantee that stability for all users in different Internet conditions. Whereas interactive elements just require an update in 100ms or 200ms after the user pressed a button, which is not that hard to achieve.
    - sa1 5y ago
      We’re not measuring latency due to processing here. We’re measuring latency due to round trips. For server rendered animations, all the frames might be delayed due to geographical distance, but the time gap between the arrival of individual frames is not affected by geographical distance. The server is not waiting for the client to request the next frame, it’s always pushing. For the user, it’s similar to watching a streaming video after letting it buffer a bit. For interactive elements, every interaction has to go through the round trip. So the gap between interactions is affected by distance. Server rendered games would suffer much more than server rendered animation.

mcintyre1994 5y ago

The LiveView is just a HTML page so you can have whatever CSS/JavaScript you like on the client side for animations and interactivity. Talking to the server is opt-in and you’d basically do it wherever you’d usually make an API call from React etc. The go-to for JS in LiveView seems to be Alpine (https://github.com/alpinejs/alpine https://github.com/alpinejs/alpine) but I haven’t got around to trying that out myself yet.

rkangel 5y ago
I'm not sure it's really 'opt in' - talking to the server is the default way of changing what's on your screen. Adding a whole front end framework is going to conflict with what's going on with the LiveView elements. Alpine is the default because it's good for "sprinkling" little elements of interactivity into an otherwise statically rendered page.

staticelf 5y ago

You can come a long way with css animations or svg-updates. There are limitations and they are mostly connected to the latency part. For example, if you want a 60 fps animation created and the server is far far away, like the other side of the globe that could be an issue or if your connection is bad. With liveview, you cannot create offline apps without javascript for example. That is a big limitation. But since most apps don't really require offline capabilities that is not really a big issue. I have however tried to use a liveview hosted in Sweden from Japan (which is basically on the other side of the globe) and I didn't experience any noticable latency for simple html updates. I think if you're making a game, you'll still need to use javascript. But if you are just making a simple crud app you may not need it for at least most of the stuff. I still think creating modals or things that the user expects to be instant should perhaps still be done in javascript but for all the server requested data liveview is probably faster than your average SPA.