undefined | Better HN

0 pointsbcardarella1y ago0 comments

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.

0 comments

2 comments · 1 top-level

oompaloo1y ago· 1 in thread

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.

bcardarellaOP1y ago

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.

j / k navigate · click thread line to collapse