Offline Support for LiveView Features

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.

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: Building Local-First apps for Windows, MacOS, Linux, iOS and Android using Phoenix LiveView & Elixir! · GitHub 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.

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.

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:

1. Being able to keep state on the client-side to be used during disconnections
2. 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.

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.

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”