Shortcomings in LiveView - are there any I should look out for?

[chrismccord]

@toberoni

Latency

I’m currently in South East Asia while most servers are located in the US or Europe - each time the UX of a full page reload is horrible. The static HTML gets rendered and it seems I can use the website - but then LiveView connects to the server again and I have to wait another 1+ sec until I can interact.

Thanks for the feedback! High-latent clients are definitely a UX concern, but one thing I want to highlight is we take these considerations seriously, and since the LV contest we have added features to ensure users are provided feedback while awaiting page loads and event acknowledgements. This happens through three features:

1. we dispatch phx:page-loading-start and phx:page-loading-stop events. This allows you to use tools like nprogess to show page loading state before users can interact with the page, which is critical for proper UX on a fast or slow connection. New projects using --live have nprogress out of the box. For “page-level” events, such as submitting a form, we dispatch phx:page-loading-start and stop, and you can annotate other bindings with phx-page-loading to trigger your page loading feedback for events you expect to be page-level
   NProgress: slim progress bars in JavaScript

2. We apply css loading state classes to interacted elements (phx-click’d els, forms, etc) and those elements maintain the class until an acknowledgement for that interaction is returned by the server. The classes will be maintained even if any in-flight updates from the server are received. Projects using --live have basic css classes to show you how to use these (we simply dim the inputs).

3. We have phx-disable-with for optimistic UI on the client to swap out the client content while awaiting an acknowledgment for immediate feedback beyond css classes. Likewise, you can make use of the css loading states to toggle content, but disable-with is handy for quick feedback.

Proper UX is one of our biggest concerns. We want LiveView apps to be good citizens on the web, and you can see this desire in our live routes, where we enforce live navigation maintains reachable URLs, so things like open in new tab and sharing links just work without breaking the model like SPAs often do. We also have a enableLatencySim() function on the client to test drive your LiveView apps with simulated latency exactly to ensure proper UX.

I hope that gives some insight. These features have been around for some time now, but it’s possible your experience predates their usage, or predates --live so folks didn’t use them by default. If folks aren’t these features today, then they are doing it wrong