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

Hard time understanding the use case for this #27

abacaj opened this Issue May 18, 2018 · 8 comments


None yet
8 participants

abacaj commented May 18, 2018

Maybe I'm a bit behind in web trends and totally missing the point, I have a few questions someone may be able to answer.

Q1. What is the point of a mobile framework being ported to web?
Q2. Why aren't we just optimizing react.js for the web?
Q3. It feels like we are confusing the frontend landscape with even more frameworks, like my previous question - why not just contribute to react.js...
Q4. Don't we have electron + react.js for web to native desktop experience? What is the purpose of this?


This comment has been minimized.

darthtrevino commented May 18, 2018

The author's talk at React-Europe is worth watching to understand his motivations. It's an experimental technology to see how react in the web performs under the multithreaded react model on mobile.

It's not production-ready, but it looks like it's promising in terms of eliminating jank in rendering and animations. Because your application is thread-isolated from rendering, then rendering should never really be blocked theoretically.

For example, check out this tweet from the author describing the performance characteristics of animations with these different architectures (


This comment has been minimized.

kripken commented May 19, 2018

I believe another use case (also mentioned and demoed in the talk) is if you happen to have an existing React Native app already, this project gives you an easy way to run it on the web with the exact same layout and so forth.


This comment has been minimized.

jhohlfeld commented May 20, 2018

@abacaj I have to respond to your points, because I strongly feel for rapid evolutionary development in all areas, especially software.

There’s not much to gain in asking „why do we need this“ or „wouldn’t it just make sense to instead keep X“? Somewhere somebody will find this useful and interesting and good ideas will always prevail. You simply don’t know what this particular idea or strain of development will be. I have one plea: keep your mind open. If it doesn’t suit your needs, it sure will suit somebody else‘s.


This comment has been minimized.

jhohlfeld commented May 20, 2018

By the way narrowing the gap in terms of layout between mobile and web would be a huge win. Does anybody have experience how the javascript-driven layouting performs compared to DOM done by the browser? I assume there will be some major perf issues lurking, right?


This comment has been minimized.

peacechen commented May 20, 2018

A single code base that runs on both native and web is huge. Previous technologies worked the other way around -- write a web app and run it in a web view on native devices. That has fallen out of favor because it looks and performs terribly. React Native brings native performance while allowing developers to use React.js.

@jhohlfeld vincentriemer ported the Yoga layout engine to Web Assembly. That should offer a noticeable improvement over React.js's web layout rendering.


This comment has been minimized.

slorber commented May 23, 2018

Note that big players like Twitter, AirBnB and MLS are already using stuff like react-native-web and react-primitive in productions, and they share their React components across platforms (React, RN, VR, Sketch...) with great success. You can also check this issue about the differences between currently used solutions to achieve that and this new solution here.


This comment has been minimized.

peacechen commented May 23, 2018

It's great that they've been able to get react-native-web working for their projects. But they use it because that was the only solution available, not because it works so well. It does an admirable job trying to map RN components to their DOM equivalents, but there's a ton of infrastructure missing. The key point that you made is that the've used pieces of their app with react-native-web, not the whole app.

react-native-dom OTOH has the potential to run the entire app as-is in the browser.
Platform differences will always arise (e.g. Android vs iOS in RN). Each platform needs some small amount of accommodation, but the overall app infrastructure is retained.

Edit: you've done a better job than I of listing the technical differences in the other thread :)


This comment has been minimized.


motiz88 commented Jun 3, 2018

Some good answers in this thread (thanks everyone) - Closing this as the README already links to the talk for the overall "why?" and we have #17 for more focused discussion of RNDom vs RNWeb.

@motiz88 motiz88 closed this Jun 3, 2018

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