I think a lot about building a web app friendly from desktop to mobile. I’m convinced by the fact managing the state as much as possible in the back-end is a very nice approach to minimize work and bugs. Maybe you guessed, I think about LiveView to communicate between the back-end and the user UI.
- on desktop, the experience is nice via web browser
- on mobile, the experience is nice via web browser
- on mobile, the experience is nice and encouraged via a mobile app (main topic of this post)
I see two different approaches to design the mobile experience via a mobile app reusing the Phoenix Liveview powered views:
- building a PWA (Progressive Web App), however I’m not sure it is pragmatic with LiveView SSR
- building two minimal hybrid mobile apps (Android and iOS), with features written natively for tiny generic features (like splash screen, notifications, no network behavior, etc.) and pushing the main content as a web view (see this exemple or this other one I found writting this)
Do you have some experience feedbacks on this in the Phoenix/LiveView ecosystem?
The second option take inspiration from this talk by Sam Stephenson from Basecamp about how they used Turbolinks (now named Turbo) to serve their web app from desktop to mobile via Rails SSR.
PS: note I already watched about LiveView Native which is seems considered as R&D right now, my point here is web based content.
You are describing something very much like this
What did you end up going with? Doing some research for my projects as well!
To me the most promising solution right now looks to be using liveview and svelte together.
Svelte is a disappearing framework with none of the react framework overhead or virtual dom inefficiencies and includes an excellent approach to transitions, animations, scoped styles and client side state management. I think it’s a perfect match to enriching liveview based apps. Even if I was doing pure JS apps or native apps (i.e. Svelte Native) I would be reaching for Svelte regardless.
Anyone who would indulge using JS hooks or alpine.js in Liveviews should seriously look at live-svelte as a superior approach. Live-svelte is not doing anything mysterious or magical and merely matures the very straightforward liveview approach as described in the blog post by Ryan Cook.
Another framework that is at the very early development stage is Hologram. It is likely to be some time before it is truely viable but the approach is certainly very interesting and it is being used by the developer for a production site. Definitely worth watching.
I did this several months ago, using Flutter.
I have the code on GitHub (I’m on mobile now), but it’s buried in a branch and I can get you the code if needed, but I don’t have a working implementation. I would like to resurrect it though, for situations like this.
I made a basic app with nav buttons at the bottom (it was a todo list). One for Todos, one for User stuff. Above that, was a WebView widget that contained that actual Phoenix/LV application.
In the Phoenix application, I could detect a custom HTTP header sent by the mobile WebView to know if it was in a “mobile native” environment. (There were other ways, but that’s what I settled on.)
If you go down this route, note the first-party Flutter WebView dependency is laggy and under-featured. There a popular third-party dependency that does the WebView thing much better. You’ll recognize it when you see it.
Actually, Hologram is in the final stages of development The roadmap page is not up to date, and the project has been completely overhauled.
Its a huge undertaking but damn cool.
It would be great to understand what’s needed before it can be a full liveview replacement as it opens up a range of possibilities that are not possible with the liveview design.
What are the current language and runtime restrictions of your implementation? Eg can you spawn processes, genservers, supervisors on the client?
Regardless, I think if you manage to get some traction and people succeeding with real world production apps using Hologram then it could be one of the next big things for developing Elixir web applications.
In the initial version, the complete Elixir syntax will be available, excluding elements related to processes (e.g. the “receive” keyword), supervisors, and anything specifically tied to the server, such as filesystem access. Besides the Elixir syntax, you’ll have access to the standard Elixir library, automatically transpiled for your convenience. In later stages, I plan to delve into parallelism using the Web Workers API. However, in my opinion, due to Hologram’s architecture (action/command), processes won’t be as beneficial, and 99% of the work you perform won’t require them. This is because, on the client side, it primarily involves input processing and state updates. Parallelism/concurrency would be more beneficial if you intend to process files on the client. For asynchronous tasks, you can simply employ Hologram commands, running on the server with full access to Erlang VM functionality.
That is very interesting, however do you think that introducing a subset of elixir that gets transpiled is beneficial?
I mean having a functional language on frontend is great, however missing so many crucial features makes it a completely different language, this also includes libraries that use supervisors/processes that will be incompatible.
Bit of a necro, but IMO, from recent experience this is probably the most pragmatic approach to get started. I added PWA support to a LV app recently, and it took maybe a weekend.
The PWA Builder report card was very helpful, and their docs are ok. That helps you craft a single
web_manifest.json file, and the rest is getting a no-op service worker registered correctly in your app’s assets and build process. That’s all it takes to have a trivial-to-execute mobile/desktop experience.
The LV SSR experience works as fine as any backend-state-heavy application on mobile, which is to say, it degrades fast based on network connection. But I would say the value of getting something onto mobile quickly, and then validating if your actual users even have connectivity constraints, or actually require full OS integration, is very valuable.
Diving into a radically more expensive and complicated approach to application development is still on the table, but PWAs can get a Phoenix and LV app out there much quicker, cheaper, and are easier to maintain. Worth trying!