4 ms·
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
by Cyph0n 2y ago
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.
- CharlieDigital 2y agoYou can use a JS service worker and local storage. This is how Firestore works, for example
- arcanemachiner 2y agoSomeone made a PoC app (todo list) that integrates LiveView with offline support and conflict resolution via CRDTs. https://liveview-svelte-pwa.fly.dev/ 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 https://github.com/woutdp/live_svelte
- mike1o1 2y agoAgreed! 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.
- mike1o1 2y agoYes 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.