New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

react-native-web #17

Hermanya opened this Issue May 17, 2018 · 4 comments


None yet
6 participants

Hermanya commented May 17, 2018

Hello, I'm trying to understand the difference between this project and It would be useful, to have an explanation in the readme.


This comment has been minimized.

idibidiart commented May 17, 2018

For one thing, Yoga, RN's layout engine, is ported to WASM in this project. Not so in RN Web. The advantage is that you get identical layout behavior, guaranteed.

Another thing that is an advantage here is all component logic runs in a worker thread, allowing the UI thread to be exclusively used for rendering.

And I believe this uses Custom Elements, part of the Web Components spec.

And the same build system/packager as RN.

Correct me if I'm wrong.


This comment has been minimized.


motiz88 commented May 17, 2018

Seems like the intro to the README sums it up nicely, only without mentioning react-native-web specifically:

Multithreaded by default
Same layout behavior as React Native on mobile
Built with the same bundler used for existing React Native platforms
Ecosystem compatible escape hatch to the DOM

These are pretty much the main differences between this project and react-native-web. That, and being newer and more experimental.


This comment has been minimized.

slorber commented May 17, 2018

ReactNativeWeb has a babel plugin which replaces at build time all

import { View } from "react-native"


import { View } from "react-native-web"

And the View from ReactNativeWeb is just some custom component with styles and behaviors trying to match the native RN platform components.

For instance, as you know the RN views are by default flex based with column direction, so a simple RNW View implementation could be:

const View = ({style, ...props}) => (
      style={{display: "flex", flexDirection: "column",}} {...props}

So, as you understand, the View element is actually just a regular component, there is no special magic.

With RNW, it's totally working to mix RN components with regular DOM nodes. Obviously this would only work on web platform. This looks weird but you could write:

const MyComp = () => (
      <a href="https//ssd"><Text>link</Text></a>

On the contrary, this project is taking a different approach. Instead of providing custom dom components to replace the RN components at build time (thanks to RNW babel plugin), you actually use the real RN components themselves, and the RN platform now targets the DOM the same way it supports Android and iOS:

  • it has background thread for React rendering in WebWorker
  • it has a background<->UI bridge to send diff update operations to the UI
  • it has a UI thread for dom operations, that you cannot access directly from your React component code

By using the same architecture than on mobile and adding more constraints (ie running in a webworker, unability to mix RN and dom nodes, communication to UI with a bridge, using same layout engine...), we get a system that is much closer to the existing RN mobile apps.

The View of RND is on the native side (UI) and your components on the background side (WebWorker), while the View of RNW is just a custom element on the UI side, and your components are also on the UI side, calling the View components as any regular custom components.

You can probably combine both tools together:

  • Build an universal UI component library (using RNW or react-primitives)
  • Build a RN mobile app, using the component library
  • Use RND to port the mobile app to a mobile website
  • Use regular React to build your desktop website, using the component library

Or you can try to use RND to also build your desktop website, which can probably be a bit more risky and challenging but let's see :)


This comment has been minimized.

Nkzn commented May 26, 2018

I recognize the difference as shown in the figure below.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment