React-native-web: [question] react-native-web tradeoffs
apologies if you think this is the wrong place to pose a question like this (if so, feel free to close this issue) but I'd be great to know what are the common trade-offs/problems devs face when using react-native-web?
possible questions to consider:
- How much size does this library add / what's the performance cost for a web application?
- To what extent do most devs end up sharing the majority of their UI code (such that it's worth mixing dependencies versus using something like react-primitives)?
- Won't the usage of non-semantic elements hurt SEO?
I also found this issue comparing react-native-dom/web https://github.com/vincentriemer/react-native-dom/issues/17 and another one comparing react-native-primitives/web https://github.com/lelandrichardson/react-primitives/issues/31 which both help to shed light on some tradeoffs.
alidlorenzo
>All comments
The documentation introduces many of the problems the framework solves for developers, and the constraints it requires to do so. It's not meant to create problems :)
These React abstractions remove some capabilities in order to create new ones. Certain product features that you can implement with React DOM + CSS Modules can still be done with this GUI framework, but not in the same way. Part of the cost is in learning how to think about old things in new ways. And how to make the best use of new tools. There is ongoing work to fill in more of the gaps in React Native (mainly components and props), and I'm working on communicating some of what the web still needs built into the core APIs (so I can close some of the temporary escape hatches here). Fortunately many of those things are also being worked on by teams who need them for iOS, Android, FireOS, VR, and Windows apps.
How much size does this library add
It depends on which modules you import. You can find out exactly by comparing the bundle size differences in your app. IIRC, it's about 15k for the core of StyleSheet, I18nManager, View.
what's the performance cost for a web application?
IMO, the perf is acceptable. And you get a lot for a relatively small upfront cost. We ran an experiment on Twitter Lite replacing CSS modules with StyleSheet and saw no negative change in perf or user metrics, including in geographies where people are more constrained by CPU and network. The implementation has gotten faster since then. I think there's more we can eventually do for runtime perf and build size using compilers and moving some of the concerns of this library into React DOM (and removing some functionality from React DOM too, by design and/or compiler).
To what extent do most devs end up sharing the majority of their UI code
With native? Some teams say 90%. But whatever makes sense. At Twitter we didn't care about native and just used it to build better web apps.
Won't the usage of non-semantic elements hurt SEO?
I don't think semantic elements have a relationship to SEO, but the accessibility docs explain that the components render to various HTML5 elements as can be inferred from the accessibility props.
What about RNDOM? It's currently an experiment and not a viable option in production. RPrimitives? I think it's unmaintained and you get better API compatibility and smaller bundles by aliasing package names at the moment.
necolas
on 25 Dec 2018
Related issues
roryabraham
路
3Comments
Mactub07
路
3Comments
passion0470
路
3Comments
tgh
路
3Comments
ndbroadbent
路
3Comments
Most helpful comment
The documentation introduces many of the problems the framework solves for developers, and the constraints it requires to do so. It's not meant to create problems :)
These React abstractions remove some capabilities in order to create new ones. Certain product features that you can implement with React DOM + CSS Modules can still be done with this GUI framework, but not in the same way. Part of the cost is in learning how to think about old things in new ways. And how to make the best use of new tools. There is ongoing work to fill in more of the gaps in React Native (mainly components and props), and I'm working on communicating some of what the web still needs built into the core APIs (so I can close some of the temporary escape hatches here). Fortunately many of those things are also being worked on by teams who need them for iOS, Android, FireOS, VR, and Windows apps.
It depends on which modules you import. You can find out exactly by comparing the bundle size differences in your app. IIRC, it's about 15k for the core of StyleSheet, I18nManager, View.
IMO, the perf is acceptable. And you get a lot for a relatively small upfront cost. We ran an experiment on Twitter Lite replacing CSS modules with StyleSheet and saw no negative change in perf or user metrics, including in geographies where people are more constrained by CPU and network. The implementation has gotten faster since then. I think there's more we can eventually do for runtime perf and build size using compilers and moving some of the concerns of this library into React DOM (and removing some functionality from React DOM too, by design and/or compiler).
With native? Some teams say 90%. But whatever makes sense. At Twitter we didn't care about native and just used it to build better web apps.
I don't think semantic elements have a relationship to SEO, but the accessibility docs explain that the components render to various HTML5 elements as can be inferred from the accessibility props.
What about RNDOM? It's currently an experiment and not a viable option in production. RPrimitives? I think it's unmaintained and you get better API compatibility and smaller bundles by aliasing package names at the moment.