Create your first LiveView Native (Elixir) Application | Hacker News Reader

Create your first LiveView Native (Elixir) Application

dockyard.com

68 pointsbcardarella10 comments

I'm the lead on the LiveView Native (LVN) project. Happy to answer any questions here. I'll get a few FAQs out of the way:

* it's not a WebView - we render actual native UI

* we do not push for 100% server-side rendering. An upcoming post will discuss optimistic UI strategies for LVN

* Android support is coming, possibly before EOY

* offline mode is not yet implemented but coming

In what ways it differs from React Native and Turbo Native?

LVN actually wraps the 1st class native UI framework. So we are not rendering out our own UI or using a WebView to render HTML/CSS with a JS bridge.

Similar to LiveView itself, we manage state and event handlers server-side.

React Native does not use a webview to render HTML/CSS with a JS bridge. The markup in RN maps to native iOS (UIKit) and Android (View) components. And even the JS bridge is not much of a topic anymore with RN new architecture using JSI which allows to process something like 10MB frame buffers (or 1 GB of data per second) with only couple of milliseconds of overhead.

Considering that for RN there is https://rise.tools/ for SDUI which is made by people who have worked on SDUI in Meta etc prior what is the competitive edge of using LVN which does not seem to benefit from the same sort of institutional first hand experience?

Also there seems to be a need to learn at least two different DSLs to cover both native targets vs RN's one.

It has taken RN almost a decade to be considered pretty good. Heck there was a period in Facebook/Meta where RN had the status of do-not-use for in-house projects. I'm wondering how do you aim to avoid the arduous journey that RN has had with much less resources than Meta has at its disposal and to avoid common SDUI pitfalls with no SDUI specialists.

I was not referring to React Native, I was referring to Turbo Native. We've often been mistaken as a WebView and not actually "native".

Our position is the build once, run anywhere isn't ideal for many use cases. When we target the actual UI frameworks we are automatically opted into a huge ecosystem that is already built for us. We allow Apple and Google to do all of the work of building and documenting the UI framework and developing apps that feel best on each platform. The other advantage is we can target every single device. For example, LiveView Native already supports iPhone, iPad, MacOS, AppleTV, AppleWatch, Apple Vision Pro. We can build for anything that SwiftUI can target. The same will be the case with Android/Jetpack.

As far as the implementation cost, our position is that managing the state on each device is a big time sink. We remove this repetition. Also, we can abstract above the markup with LiveView function components. The components compile out to the platform-specific markup. As we develop that I feel most people will be working mostly in the higher abstraction.

This might be answered elsewhere but how does LVN in its current state handle server disconnects (and for prolonged periods of time, in say no coverage zones)?

We have the same strategy as LiveView. We attempt to reconnect when network is lost. There are methods for restoring your state as well that work in LiveView and LiveView Native

Is the idea for offline mode still running Phoenix on the device with something like Elixir Desktop?

This tops my list for one of the new releases I'm most excited about this year. Can't wait to build something with LVN

LVN GO is really great. My mac is on lifesupport until the M4 launches soon. Cant handle anything more than a couple of browser tabs so even trying to open Xcode is suicide.

Reply on news.ycombinator.com