Correct. This is not a LiveView specific problem and it is going to happen on whatever app running between EU<->NZ. The LiveView specifics to this discussion are:

1. The initial request is rendered twice: once with a regular HTTP requests and another one over WebSockets

2. All upcoming live_patch/live_redirect happen on the established connection. This improves UX because we don’t send the layout again nor the browser has to load it again (this is similar to what you get with SPA, Turbolinks, unpoly, etc)

3. LiveView automatically caches and reuses templates in the client - so it sends less data than other server-rendered HTML solutions (similar to what you get with SPA)

4. LiveView runs on WebSockets, which means we don’t need to parse headers, authenticate user on the DB and so on on every request which improves response times (you can get similar with SPA if you are running on WebSockets)

So besides the initial request, LiveView should be helping with the user experience, but the discussion is definitely more general. So it probably makes more sense to open the discussion beyond the context of LiveView.

EDIT: Oh, you can also call liveSocket.enableLatencySim(200) in your browser console to have LiveView simulate latency so you can see which part of your app is not providing proper UX under high latencies.

Interesting! Thanks for contributing, Jose.

Apologies for taking so long to reply, I got lost in a data engineering hole…

I think our problem is clearly that we’ve fallen too much in love with LiveView. We get away with it because we’re UK only, so latency is fine, but will need to refactor. We just really like the programming model.

For some context, we used to lean heavily on react, and now we’ve almost replaced all of our react with liveview, except for our main configurator (Stitched | Curtains and Blinds for reference). We’re doing some new UX though, and the intention is that this process will be modified and the new version will be LiveView. We definitely drank the koolaid. I feel a blogpost coming on, if someone on my team (probably me) ever finds the time

As a programming model, it’s unlocked a lot of productivity for us, even if we’ve clearly abused it by building things like our nav in it. I appreciate the points raised in this discussion, and can see an audit in the not too distant future where we assess how we’re using LiveView and move a few things back to the client. If anything though, this ability for progressive enhancement just shows the strength of the programming model and is reassuring me that we made a good choice. Thanks for taking part, everyone, has thoroughly answered my questions!

Imo this is not really a promise LiveView tries to make, exactly for that reason. It’s always been marketed to solve (primarily) those problems, where the server needs to be involved anyways. As mentioned before there is overlap (e.g. in pagination), but generally one should use client side tooling for purely client side interactions. Nobody wants latency in opening dropdowns or simple accordions.