4 ms·

Is it a good experience for folks with high latency internet?

by diob 3y ago

lewantmontreal 3y ago
With higher latency the experience suffers. As an example liveview page navigations work via websocket which is not cacheable so navigating back/forward always needs to make a request. You really need some edge setup like fly, or only serve a geographically local audience.
- HappMacDonald 3y ago
  Unfortunately no matter how local you push the CDN: somebody with a crappy connection to their ISP, or a crappy router in their home, or on a tenuous wifi link in their back room or at a coffee shop will drown in the input lag all the same and inexperienced users (those whom this is more likely to happen to) will be the ones to fall into unstable interaction orbits with the UI such as spam clicking the button that doesn't appear to have acknowledged their press. The real best solution for this one major drawback I am aware of would be for Liveview to be able to generate some JS handling in their front-end widgets, more like Lambdera. That, and/or run a BEAM on the user's machine via WASM so that they don't have to dirty up their hands in even the slightest amount of javascript lol! xD
gangstead 3y ago
It can be pretty bad especially for UI updates that you are used to being handled client side. Example: You click on an upvote button and it changes color, but there's 1 second of latency. SPA: Color updates immediately, the "upvote pressed" http/websocket call to the server arrives one second later. LiveView: liveview.js sends "upvote pressed" over the web socket, one second later the liveview process on the server gets the message, patches the dom and replies, one more second later the button changes color. Meanwhile the user has pressed the button 2 more times wondering why the color isn't updating. There are phx-hooks (https://hexdocs.pm/phoenix_live_view/js-interop.html#client-hooks-via-phx-hook https://hexdocs.pm/phoenix_live_view/js-interop.html#client-...) to address this with small targeted bits of js where you can add event listeners but it can get messy quickly.

Is it a good experience for folks with high latency internet?

by diob 3y ago

Is it a good experience for folks with high latency internet?

With higher latency the experience suffers. As an example liveview page navigations work via websocket which is not cacheable so navigating back/forward always needs to make a request. You really need some edge setup like fly, or only serve a geographically local audience.

HappMacDonald 3y ago
Unfortunately no matter how local you push the CDN: somebody with a crappy connection to their ISP, or a crappy router in their home, or on a tenuous wifi link in their back room or at a coffee shop will drown in the input lag all the same and inexperienced users (those whom this is more likely to happen to) will be the ones to fall into unstable interaction orbits with the UI such as spam clicking the button that doesn't appear to have acknowledged their press. The real best solution for this one major drawback I am aware of would be for Liveview to be able to generate some JS handling in their front-end widgets, more like Lambdera. That, and/or run a BEAM on the user's machine via WASM so that they don't have to dirty up their hands in even the slightest amount of javascript lol! xD

gangstead 3y ago

It can be pretty bad especially for UI updates that you are used to being handled client side. Example: You click on an upvote button and it changes color, but there's 1 second of latency. SPA: Color updates immediately, the "upvote pressed" http/websocket call to the server arrives one second later. LiveView: liveview.js sends "upvote pressed" over the web socket, one second later the liveview process on the server gets the message, patches the dom and replies, one more second later the button changes color. Meanwhile the user has pressed the button 2 more times wondering why the color isn't updating. There are phx-hooks (https://hexdocs.pm/phoenix_live_view/js-interop.html#client-hooks-via-phx-hook https://hexdocs.pm/phoenix_live_view/js-interop.html#client-...) to address this with small targeted bits of js where you can add event listeners but it can get messy quickly.