Hacker News Reader

Comment by mike1o1 | Hacker News Reader

LiveView is super exciting and extremely productive developer experience. One thing that I hope future versions can help address is what I call the "elevator" problem, in that if I'm using a LiveView app on an elevator (or in my case at Costco), it becomes unusable as the connection gets too flakey. While I get offline support will never happen, maybe better support for unreliable connections would be fantastic, though I get how that could be against the ethos of what LiveView is trying to do.

View on HN

I haven't had bandwidth to explore the implementation deeply yet, but this seems almost too relevant: "Working in Elevators: Offline-Enabled Realtime Apps with LiveView, Svelte, & Y.js"

https://liveview-svelte-pwa.fly.dev/

Genuine question: wouldn’t server-based frontend JS apps be susceptible to the same issue?

Of course, if your JS app isn’t server-based and can run non-trivial logic on the client, then it’s going to work better than a LiveView app.

Yes it would, it’s just not as noticeable in my experience. For example, I have a Todo app with my shopping list. Every time I unlock my phone to look at it, I need to wait for the socket to reconnect. Either I lost it due to poor reception, or my mobile browser killed the socket connection (but not the tab process).

I don’t really have that with a traditional SPA, since the view is “dead”. Of course, interactions might be slow, but I can at least still browse the data already on the screen.

You can use a JS service worker and local storage.

This is how Firestore works, for example

Someone made a PoC app (todo list) that integrates LiveView with offline support and conflict resolution via CRDTs.

https://liveview-svelte-pwa.fly.dev/

It's a toy app obviously, but I was impressed with the potential of so many technologies being integrated with each other (It even has Svelte in the mix via LiveSvelte[1]).

[1] https://github.com/woutdp/live_svelte

Agreed! I am hopeful that future versions might help address these challenges at the framework level. It’s the Achilles heel to LiveView. As soon as the connection gets unreliable or has some latency a lot of the magic goes away. Most of the time the productivity boost from working in LiveView more than makes up for it, though.

I'm grossly over simplifying but I've always thought a cut down version of Replicache[1] functionality would be an amazing logical progression for LiveView. With Phoenix.Component[2] introducing attributes it's perhaps closer to being feasible.

[1] https://replicache.dev [2] https://hexdocs.pm/phoenix_live_view/Phoenix.LiveComponent.h...

There’s more support for doing some various JS events locally without waiting for the server. It also improves the offline connection support as well AFAICT. The `JS.push` stuff was new to me and makes it easy to do simple functionality like switching tabs without needing to wait for the server, or for the server to keep that state at all.

>While I get offline support will never happen

You can in theory compile part of your elixir app to wasm, run it on the client, threat is a just another process and mutate the state of live view from there. It's a question of fitting all the pieces of tooling together

Reply on news.ycombinator.com