Mimic react-native-web

[ozyman42]

I'd be open to helping contribute to this repo if there's a willingness to add an implementation of the react-native API.

Why? In the react-native-web project, it reimplements the react native API in DOM components, and then app creators add a webpack alias configuration to change an import from react-native to react-native-web at build time, allowing react native component code to be shared between RN and web projects. See react-native-paper for example with nearly 11k stars on GitHub. This would allow react native developers to switch to NativeScript while keeping all of their platform agnostic component code which could increase adoption substantially. Also the leading deployment mechanism for React Native apps, Expo, uses react native for web too so maybe this interop would make it possible for Expo to begin offering NativeScript support as well which would mean lots of visibility for NativeScript.

We could add this compatibility without making a breaking change. For example I could implement this in a special directory such that the import would be react-nativescript/react-native-interop while the main exports directly from react-nativescript remain unchanged.

[ozyman42]

Ah I just read the readme and saw https://github.com/shirakaba/react-nativescript-compat-react-native

[shirakaba]

Not going to happen, I'm afraid.

• To seamlessly migrate from RN to React NativeScript (RNS) you need a lot more than just View and Text. The rabbit hole goes very, very deep. As I said on the README, it's a project on the same scale as React Native Web (RNW), that took full-time paid engineers at Twitter years to build.
• It would be a huge maintenance burden – I'd have to keep catching up with React Native (RN).
• RN developers haven't shown much interest at all in switching to NativeScript since I begun this project.
• Expo have doubled-down on RN. A few years ago, I built an adapter for Expo Unimodules so that NativeScript could use Expo Unimodules. In fact, they'd made an adapter for Flutter, too. However, due to lack of interest, Expo decided to sunset Unimodules in favour of Expo Modules, which focuses on (and is coupled to) RN. I don't think they'll ever want to offer an Expo NativeScript.
• Even with API-compatible components via react-nativescript-compat-react-native, and when using the very same layout engine as RN via nativescript-yogalayout, NativeScript Core is missing a lot of fundamental features to match RN. Things like being able to nest a View inside a Text.

Ultimately, I want to combine the mature ecosystem of RN together with the native API access of NativeScript, and there are many ways to achieve that. In fact, I am not satisfied with RN's UI model (I much prefer React DOM's, and indeed the web platform's) and so I'm more interested in investigating that nowadays.

Most recently, I've been making NativeScript HTML (example screenshot and repo) and watching Osei's progress on bringing proper web layout (block, flex, grid, and more) to NativeScript. We're also rethinking NativeScript from the ground up to better align with the web.

RN has always been popular due to its web-inspired APIs, but it's still far behind the web platform. So I think NativeScript can offer more value by being even more web-like than RN. Yeah, we may not be able to become ecosystem-compatible with RN, but the web's ecosystem is far bigger!

Though, on that note, I did help bring RN native module support to NativeScript and it works really well: https://github.com/OpenNative/open-native

[ozyman42]

Thanks for a detailed reply. That strategy makes a lot of sense. If you add usage and contribution docs to https://github.com/shirakaba/nativescript-html I could try and help to implement some features.

[ozyman42]

I do wonder, would reimplementing the DOM leave the solution with performance comparable to webview which hybrid apps use, or would there be ways to ensure the interop layer has far less overhead than embedding a web browser, and feels more native to end users?

EDIT: Based on reading into it all more looks like the answer is that Happy DOM doesn't implement the rendering portion of the browser, just the API and JS runtime.

[shirakaba]

If you add usage and contribution docs to https://github.com/shirakaba/nativescript-html I could try and help to implement some features.

Thanks for the offer, though I'm pausing work on it as I found NativeScript Core just doesn't offer enough functionality (at present) to make it a framework worth using. Things like inline text layout are very limited at the moment, and CSS is far too slow, at least in a DOM-based events model. I'm currently focusing on a ground-up rewrite of NativeScript to resolve this. It'll be a while before it's ready.

And yeah, we don't reimplement any rendering logic. Using happy-dom does mean that our DOM is in JS rather than C++, which is a shame, but I wanted to make the framework anyway to assess how well it would perform in practice.

[ozyman42]

Perhaps there's a way I could use nativescript-html as-is with CSS disabled? I wouldn't mind going the route of setting the style attribute directly for now

[shirakaba]

If I’m remembering correctly, NativeScript HTML delegates all CSS to NativeScript Core’s existing CSS implementation and basically doesn’t make use of Happy DOM’s CSS implementation.

Same for some other things like XHR and fetch – I use what NativeScript Core offers where possible.

So whenever you use the className or style attributes in NativeScript HTML, it should be the same as using them in NativeScript Core. Though I admit there may be some bugs in the pass-through logic because I don’t fully understand Core’s approach.

If you’re happy to use just style and ignore className, then that’s supported (though again, there may be bugs – I stopped working on it after getting a proof of concept for styling running).

[ozyman42]

If I were to do a ground-up rewrite of NativeScript I'd probably try and build it on top of Tauri mobile or cargo-mobile so I could write in Rust rather than C++. Hope you're able to get lots of help on that rewrite.

[shirakaba]

Wouldn’t make much sense.

• NativeScript provides JS bindings to the Obj-C runtime.
• Cargo-mobile is a toolchain for compiling Rust on iOS/Android.
• Tauri is a Rust framework giving you an app that hosts a WebView.

Neither really offer anything to be built on top of. If you want to make a WebView-based app, that’s possible already in NativeScript (as it can instantiate WebViews).