Hello.
- Is offline support for LiveView features anywhere in the pipeline for the Pheonix core team?
- Is there somewhere discussions around this are ongoing? I’d love to be part of it.
Thanks.
6 Likes
LiveView will never have offline support. It’s not because no one wants to do it, it’s because way LiveView works supporting offline is impossible. If you need to have offline support you need to use different technology.
Yeah as @wanton7 notes, LiveView is a serverside rendering technology. If the server isn’t available, rendering can’t happen.
2 Likes
Thank you for your responses.
I understand that at the moment, that’s the case- LiveView is strictly a serverside rendering technology.
Whether or not it plans to stay that way is what I wish to know.
Prior to LiveView, taking advantage of Channels with your favourite client-side technology seemed to be how far we could push the edge. Then LiveView happened. Now we don’t need a separate technology for that anymore.
I can imagine a path where the client-side state is maintained by the framework (Phoenix/LiveView) just like reinitiating the stateful connection is. It might be some baked-in JS functionality, but that’s up for discussion.
So, the question is whether that’s currently in consideration or it was and has been discarded.
It’s not strictly server side. You can’t just do offline LiveView web apps. There is this new project GitHub - elixir-desktop/desktop: Elixir library to write Windows, macOS, Linux, Android apps with OTP24 & Phoenix.LiveView that allows you to use LiveView to create mobile and desktop apps. But for strictly web browser based UI you need to have WebSocket connection connected to server for everything to work.
5 Likes
LiveView itself will probably never support client-only directly.
However, there are two developments in this space which might open up interesting possibilities in the future:
- elixir_script which compiles (currently a subset of) Elixir code to JavaScript. With this, someone could make a library that accepts the same syntax as LiveView-behaviour modules but which would compile down to JavaScript and thus be fully client-side.
- lumen, an alternative BEAM (the Elixir/Erlang VM) implementation which could conceivably compile through WebAssembly to run fully in the browser.
7 Likes
Thank you for clearing about being strictly server-side. You’re right about that.
But my question is still not answered.
I’m aware of Elixir-desktop and I follow its progress constantly. In fact, its example todo app illustrates what I’m curious about, albeit in a slightly different domain.
The todo app runs offline (desktop/mobile in this case) and manages its local state successfully.
Imagine the fictitious app developer adding a Phoenix backend to allow users to synchronize their todos across devices.
Can the server-side state be accessible to the app via WebSockets while the local copy takes over when there’s no connection, with both syncing when the connection is restored?
Returning to the web-browser based UI, the features I think are missing for LiveView to support the behaviour I described are:
- Being able to keep state on the client-side to be used during disconnections
- Being able to sync the local and server-side state after reconnection
These are the things that I’m wondering if they’re in the pipeline.
3 Likes
I have checked out lumen more than I have elixir_script but I think both offer up interesting possibilities.
The decision on which tool to use is of course up for discussion.
If the concept is being considered actively in the first place is what I don’t know.
Thank you for your response.
I think the answer is: yes, it plans to stay that way. The premise of LiveView is that you can cover most of the use cases for a web app without writing JavaScript. The basic interactions (navigation, form validation, etc.), require talking to the server. Theoretically I think one could imagine LiveView providing the frontend library that would keep the app working and sync the changes back on reconnect, but I don’t think it’s feasible in a generic way that would address most use cases.
If you need offline support, you need to write JavaScript. If you need to do that, then LiveView is not really what you’re looking for, though it may still be powered by Phoenix.
1 Like
A very clear answer.
Thank you!
Front-end capabilities being “batteries-included” with Phoenix would be great though if it happens in the future.
It would transit Phoenix from being an “Elixir Web Framework” to simply being a “Web Framework”
Keeping state in the browser is already supported. You keep state in the query string or pass state from browser in LiveSocket’s params when it connects. You should do it anyway because WebSocket connection can disconnect any time and when you reconnect you need to recover important state like open panels, active tab and on. LiveView forms already support this recovery.
3 Likes
I hadn’t considered this.
A quick Google search led me here: Saving and Restoring LiveView State · Fly
It’s interesting.
Any other helpful resources will be appreciated.
1 Like
Just to understand, why would you want to do all this in elixir/phoenix in the first place? I feel like you choose elixir/phoenix for apps where the server is a crucial component - i.e. you are basically doing some operations on a centralized database somewhere.
As opposed to predominantly server side apps like google docs, where the server part is, in a sense, mostly about backup/sync. Why not use javascript for this type of apps?
Team size/dynamics basically @josefrichter
Choosing to use JS means:
A. Getting a JS developer (S/he is unable to contribute to the Elixir codebase)
B. Training Elixir developers to be proficient in JS (Longer time to market)
C. Getting JS + Elixir developers (Pricier option)
2 Likes
Frankly speaking, I have never seen one web application that can smoothly transition between online and offline states and works great in both states. If I were offline, I’d rather read a book.
8 Likes
I don’t think there are that many resources about LiveView state management except that one. I’ve only used LiveView in my one of hobby project and I had same questions as you how to store state in the browse and had to find out everything myself. I think there should be official LiveView documentation for this explaining how you can build LiveView projects that can handle WebSocket reconnects and store state in browser for next visit etc.
2 Likes
That’s both funny and true.
Our product’s target users won’t always have great wifi. That’s why it’s important.
I think the Elixir community is well-positioned to solve this.
I hope we can come up with something someday soon.
I don’t really see this as true. A key part of the Elixir / Erlang experience is the BEAM, and all of the proposed answers to running in someone’s browser offline involve not-the-BEAM.
I’m not trying to bash your interest here, but I do think it’s important to have realistic expectations of where these Elixir projects are headed. Offline support is an explicit non-goal from the LiveView core team. Offline versions of the BEAM (or alternative backends) are experimental at best.
The closest would be an electron style thing that bundles the BEAM and a browser into a full desktop app. This is technically offline in that it doesn’t require the internet. Maybe that works for your use case?
3 Likes
The ease of communication between BEAM nodes is what I hope can be extended to clients.
It’s hard to find something that rivals that in other ecosystems.
Perhaps I need to understand the limitations of the BEAM more clearly.
2 Likes
