~180% performance overhead vs react-native

[affectful]

Describe the issue

On android in production I'm getting these results rendering a table. On web it's really fast compared to other options but on react-native it's the opposite story.

Platform: android, Version: 35, Env: production
30 runs of each table variant at size 100 x 12.

Variant	Avg (ms)	Relative to RN
react-strict-dom	344.30	286%
react-native	120.44	100%
tamagui	349.05	290%
emotion	177.37	147%
styled-components	165.55	137%
rn-css	403.14	335%

Expected behavior

Performance without too much overhead

Steps to reproduce

https://github.com/affectful/bench-repro

yarn android:release

or

yarn ios

Test case

https://github.com/affectful/bench-repro

Additional comments

No response

[necolas]

This actually looks positive for RSD, since you're comparing apples to oranges.

1. You're comparing libraries that do different things.

• Emotion & SC don't do much except add a different style syntax for RN.
• RSD adds features otherwise not supported/possible in RN or when using SC etc.

2. Comparing to RN doesn't capture the capabilities RN doesn't provide

• Your benchmarks render View for almost every library, except RSD which renders HTML element polyfills
• If you tried to manually build a table that worked on web and native the same way using those other libraries, you'd probably be at least 2x slower than RSD.

So your benchmarks show that using RSD to render HTML polyfills that also support CSS inheritance etc is still faster than using a library like Tamagui or RN CSS.

[affectful]

I see. It's a different goal I guess, this library would be useful mostly for porting from web to native with minimal changes in behavior. If I'm writing from scratch for both platforms I wouldn't need to be concerned with lots of web feature parity.

It's a bit of a tricky question wether one would want to use this for a new project over react-native-web for a cross platform app. RNW trades off web performance while RSD trades off native performance. Mobile processors are usually slower than desktop processors, however mobile screens are much smaller and have less to render (not counting for tablets).

I guess I was hoping for a library that would be even more strict about the cross-platform api to introduce as little overhead as possible for both platforms.

[affectful]

I've seen @nandorojo around working on relevant issues, would love to get your input too

[necolas]

If I'm writing from scratch for both platforms I wouldn't need to be concerned with lots of web feature parity.

You can't produce a good (or EAA compliant) web app with RN as the starting point.

RNW trades off web performance while RSD trades off native performance.

Yeah that's right. Something else to consider is that the cost of extra JS in the bundle is high for initial load on web. And on mobile, web perf is even more limited - so having RSD for mobile web is a big improvement. There is a lot of underpowered hardware out there for desktop too, outside of the Apple ecosystem.

Unfortunately, RN itself is a lot slower at element creation than React + browser even before you add more layers of JS. On the flip side, if RN improves and more RSD polyfills move into native, the native perf should improve over time. But with RNW the perf cost for web is essentially fixed for as long as the RN API diverges from web.

There might be some further optimization (build time, React Compiler) we could do here while RSD has to polyfill things.

I guess I was hoping for a library that would be even more strict about the cross-platform api to introduce as little overhead as possible for both platforms.

The problem with this approach is that it's only useful for from-scratch apps, and it prevents a lot of code sharing. We tried this at Meta too, but it didn't really have a good use case. You essentially end up not being able to use existing RN or existing RDOM code.