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

There is another trick that you can use for private pages only, which is to not render the content on disconnected render. In your live.html.eex, you can do this:

<%= if connected?(@socket) do %>
  <%= @inner_content %>
<% else %>
  <div class="loading">...</div>
<% end %>

Now you don’t send the contents twice and the user has to wait for the page to complete after the initial load (as they would in a SPA). Given how LV optimizes data sending, LV ends-up sending less data over the wire than a complete server render and a similar SPA (which may have to send large parts of the app upfront).

However, keep in mind this means no content is sent on the “disconnected render”. So if you do this for public pages, it means no SEO. But it works fine for private content.

I had high hopes for LiveView and really like the dev experience so far - it’s straightforward to build interactive apps with it. However, after throwing together several small sites I’m doubtful that it will be the next big thing in webdev.

The biggest shortcomings:

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.

For example, the first times I visited any of the Phoenix Phrenzy projects I was often confused whether a website is finished with loading or not - even after the second mount/3.

I’m somewhat used to this behavior now (let it load for some time before I can get full interactivity) but in the beginning it was a very bad user experience. Avoid LiveView on any landing pages.

Limited use cases

Many LiveView examples do it a disservice - I would never use it for anything game-related. Flappy bird might work on localhost or near a data center but it will be nearly unplayable for any user outside your region. Please take latency into your consideration when planning your app and use the built-in latency test.

Flexibility

Adapting LiveView ties most of your views to its logic. This is fine for simple webapps or admin backends, but it will make mobile apps harder down the road. Which brings me to my next point:

Ecosystem

The ecosystems around Vue or React are a lot more mature. More components, more tutorials , more innovation, more mindshare etc. In my opinion these Javascript frameworks offer a lot of benefits for most medium apps with dedicated frontend/backend-teams.

Despite its shortcomings, I’ll continue to use LiveView and I’m excited what the future will bring. As a solo full-stack dev it has made my life a lot easier and allows me to build features that were out of my reach before.

I hope the community will find ways to deal with its shortcomings (e.g. better loading state feedback for users with high latency, client-side transitions to hide loading times…). I’m particularly interested in real-life experiences with different use cases - but I think it will take sometime to see where LiveView is a good fit and where it should be avoided at all costs.