Phoenix LiveView for a site with 90% mobile usage?

I have a little side project called that was built in pre-liveview times. I am now adding a new design to it and want to update everything to the latest way of doing phoenix apps.

One question I have is that 90% of the users of the site are using mobile browsers. Would it be wise to use liveview with this? Does anyone have experience in actual deployed products in this kind of scenario? I am a bit worried about the re-mounting if the connection gets lost.

1 Like

I think you need to distinguish between just mobile browser users and mainly mobile users with flaky network. If your users are in the second scenario it’s probably not the right decision going with LiveView. Other then that mobile browser are also fine with LiveView.

PS: The latest way of doing Phoenix apps is still up to you - using LiveView or not.
Have fun and cool project by the way.

1 Like

The question is not so much about mobile or not; it is about how frequent your app interact with your backend.If your app make api calls back to the backend every few seconds then changing to LiveView is obviously a good idea. On the other hand, a websocket connection that has long period of idling is wasteful.

For my usecase it’s basically two views that I would do in liveview. The one editing wishlists and the one where people can claim things. Both have interactive elements on them that are currently done via Stimulus.JS … which is kinda okaish. With liveview the developing experience would be way nicer, though. Those do a ton of calls to the website.

The other stuff would stay in deadview land.

I suspect that most users have stable internet, they will sit on a couch and get a link to the site via chat messages from their peers.

So looks like I should try it :smiley: . I mean if everything fails I can switch back to the old deadview style of doing things.


Yah, for mobile connections the only thing you need to watch out for is making sure the state is up to date after a socket reconnection.

1 Like