100% agreed.

As a matter of pragmatism however if your team is 90% Elixir people and your user base is exclusively businesses with solid internet though, it might be a fine provisional choice even for eg: confirmation dialogues.

In the long term though what I’d love to see is improved JS / LiveView interop. I’m finding that managing the state of your domain in LiveView to be a much improved experience over Javascript. I haven’t had do debug redux cache issues or anything like it yet, and I don’t miss that experience from the SPA world.

At the same time, we just built a collapsable side nav and to your point, it isn’t good UI / UX to manage that collapsing state via LV. Confirmation dialogues and a host of other “display only” UI interactions probably fall under the same category.

I think the jury is still out on whether LV + some spartan JS can be a solid (online only still required) SPA like replacement. From a “we need to deliver features fast and are a mostly Elixir team” perspective it’s quite nice. If we could hire a half dozen react developers though I’m not sure that we’d stick with it.

Nothing like a real world user experience to reply to your question.

So just jump in a train, car or bus commute and keep using your project with live view and then you will have a first hand experience on it. That’s what I am planning to do when my MVP is ready.

As a train commuter in a country with very bad mobile internet connectivity, even when inside the capital I can say to you, based on using other normal sites, that Live View will perform bad in this scenarios, specially when I am seeing people relying in live view to manipulate everything in the DOM.

While an amazing product the Phrenzy around it made it a disservice, because live view demos floating around are pretty much bad examples of using it in the real world.

My advice is to keep live view to a bare minimum in your web app. Just use it in places where you need to apply business logic to what you are doing, and forget all the other fancy uses. Even so I am to see how bad the user experience will be, and I am doing my app to allow me as much as possible to easily go back to normal Controllers.

So my advice is to cool down our hipe around it and put on the shoes off the end user and go to the terrain and use what we are building with live view.

Ah and remember that not all your users have a powerful laptop or mobile device like yours, thus when going to the field pickup your old laptop and mobile device and use them instead. Nothings beats a real user experience, thus please I ask to everyone to not come back to me to tell that we have tools in the browser to simulate the same or to use the built in Live View debug to throttle it.

YUP. Phrenzy was neat but impractical unfortunately.

Liveview works great when it is used for UI interactions that must involve the server, because that’ll take the same time no matter how you write it. Form interactions are generally fine, live data push updated from the server is great.

No matter how much you use it, you MUST avail yourself of the various status classes the phoenix adds to stuff to provide user feedback. A modal that takes 500ms to pop up can feel completely disfunctional, or it can feel completely fine depending entirely on whether the modal button gets a spinner instantaneously. Phoenix makes this easy, but you do have to do it. There have been really interesting studies on what people perceive latency to be, and you can get away with quite a bit as long as there is some instantaneous feedback that lets people know their click or tap was registered.

And as a last note, we’re doing a wonky thing where all of our live views are actually making GraphQL calls to fetch their data. What this means is that everything they can do a dedicated mobile app can also do without any additional work on the backend. For specific mobile scenarios that need to be highly optimized we just went ahead and built a dedicated mobile app.