what you have in mind is something like lumen being downloaded and run on client side, and then connecting to other “nodes” running on other clients? sort of peer to peer network of beam nodes? decentralized “backend” apps? 
talking specifically about liveview, I sounds to me it’s going in the exact opposite direction than you are wishing for - you want thicker client, liveview promises to have some of the cool features of thick clients with actually super thin (almost none) client, doesn’t it?
You should think if you really need offline features or not. If you make LiveView WebSocket reconnects robust meaning important state that can’t be restored from database etc. is restored from client/browser state experience should still be quite good. If users need to able work while their connection is offline then you need to use some other client tech.Making app work offline and sync changes back to server when it’s online again is another level of work. Think hard what your actual requirementa are.
You should be able to test LiveSocket reconnects by liveSocket.disconnect() and then liveSocket.connect() from browser console.
So having been around for several discussions on Lumen (I’ve worked on the site) I don’t think Erlang distribution is intended for client-server communication there.
For one thing Erlang distribution lets nodes run code on each other. Remote Code Execution as a service
Lumen could, when ready, certainly let you write Elixir for your frontend or potentially re-use your server side logic on your client. I think that could be an addition to LiveView. I doubt it would be inside of LiveView.
There are serious challenges to overocme anytime you want to do good offline and good online. If/when Lumen ships it could be part of making that possible by writing only Elixir.
For now I’d look at what can be done using LiveView JS commands. I haven’t dug into it though.
Gleam compiles to JS as well. Haven’t tried it for anything yet.
Thank you all for your replies.
I have learnt much more than I anticipated.
Is this documented somewhere? I’d like to reference this if possible. 
This is going to sound crazy and I haven’t spoken to @chrismccord about this yet but I suspect the only actual offline mode that will work is the same solution that we’re developing for LiveView Native.
At ElixirConf Garth Hitchens gave me the great idea of using Elixir Desktop on native mobile to compile a running Phoenix LV app and using LVN to manage a localhost websocket connection. All interactions and UI renders happen in the Elixir Desktop compiled native app on device. Then that acts as a Node to an Erlang cluster to manage data sync. When network connectivity is down or is spotty you can still work locally and your data is staged waiting for the eventual sync step. If this sounds over-engineered then you’re right, it probably is but this is the only method that will allow us to retain the LiveView programming model and provide graceful offline mode support. In total Elixir Desktop will weigh in around 35 MBs which is still far below the 50 MB of a React Native app.
Now let’s pivot over to LiveView. If we can get Firefly WASM compilation robust enough we could compile a Phoenix LV web app to WASM and run in-browser with a similar behavior as I described above for Elixir Desktop. I don’t know yet what our actual footprints will be but I’m hoping far below 5MBs.
All other solutions I’ve seen for offline support in LV end up being work arounds and parallel programming model efforts. This is the only path towards offline mode support I’ve seen that doesn’t ask the developer to write something twice. Assuming the model described above is sound and the compilation budget is acceptable it will come down to the ergonomics of what it will take to package this up for distribution. It would be great if we could get the first render / double render speed of LV then hydrate the experience with a side-loaded WASM compiled Phoenix app that would be loaded via a Service Worker so if connectivity is lost it falls back to it.
Yes, there will be a millions “what about X” questions and just general push back as this can feel like a complex solution. But I will again emphasize that I think the only offline mode solution that will win for LV is one that doesn’t ask for duplication of effort.
I have turn to Ruby because it’s what has more available positions, and this time when I got laid off, it’s pretty clear, and given all signals that will be hard to find jobs, seems that Ruby will be my safe haven.
This is such a fantastic reply, thank you @bcardarella! I have been thinking about this topic a lot lately. This isn’t even an old thread and already the terminology is shifting away from “offline first” towards “local first”. The strategy I was mulling over in my head had to do with the (naive) assertion that the only state that needs preservation is the assigns. It can be saved to local, updated local, and merged remotely. I wasn’t entertaining the idea of a server-on-client solution until I saw a LV Native talk. My approach, of “just” tracking assigns changes locally led me to CRDTs and then I got delightfully lost in that rabbit hole and haven’t climbed back out yet, and so I’m not sure how CRDTs could interact with LiveView (and particularly assigns).
Server-on-client solutions like LVNative are a lot like CRDT solutions “beneath” normal data-layers. For example, running SQLite locally, beneath which is a transparent sync layer to a remote postgresdb. I believe this is what the elixir-loving ElectricSQL team is doing.
It will be exciting to see what happens! Good luck to the LiveView Native team <3
I love the term “local first” and I may steal it 
to be clear, I don’t think CRDTs would be used within the LiveView endpoint. But whatever the datastore layer being used should probably be syncing with CRDTs in this scenario. Then on inbound updates when connectivity is present the LV endpoints are notified with the new dataset
yes steal it! Local-first I believe was coined by the same people that coined offline-first to begin with. If you haven’t yet been proselytized, this is the seminal blog post: Local-first software: You own your data, in spite of the cloud
© Copyright Elixir Forum | Terms | Privacy & Cookies
