In what ways it differs from React Native and Turbo Native?
Similar to LiveView itself, we manage state and event handlers server-side.
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.
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.