React Native's `<Text>` and `<View>` are JS wrappers around lower-level native components. Under the hood, they handle a lot of edge cases. However, most apps hit those edge cases rarely, and the wrapper's cost (extra work per render, plus an extra fiber) is paid on every component, every commit.
React Native Boost is a Babel plugin that statically analyzes the source code and rewrites `<Text>`/`<View>` into their native counterparts (`NativeText`/`NativeView`) wherever it can prove it's safe. No imports or code changes required. You add the plugin to `babel.config.js` and that's it. Runtime overhead is effectively zero.
Safety is the hard part, so most of the work is in the bailout logic: each element is only rewritten if it passes every check (blacklisted props, structural conditions, ancestor analysis, and a lot more). There's a differential parity test & fuzzing harness that compares Boost's compiled output to what the JS wrapper components would produce and asserts they are equal.
Honest disclaimer: RN core is trying to make this superfluous. RN 0.78 (with React 19) shrank the initial-mount advantage considerably, and 0.82 added a `reduceDefaultPropsInText` flag (default since 0.85) explicitly aimed at this overhead. The RN team's stated goal is to make these wrappers cheap enough that using the underlying native components like this is unnecessary. Where it still pays off today is re-render-heavy screens. On a constantly-benchmark constantly updating a lot of `<Text>`, stock RN drops to ~32 FPS at the heaviest load while Boost holds 60, ~69% faster on iOS and ~55% on Android. As RN lands more of these optimizations I expect that gap to close, and the benchmark is built to track exactly that.
mfkrause•1h ago
React Native Boost is a Babel plugin that statically analyzes the source code and rewrites `<Text>`/`<View>` into their native counterparts (`NativeText`/`NativeView`) wherever it can prove it's safe. No imports or code changes required. You add the plugin to `babel.config.js` and that's it. Runtime overhead is effectively zero.
Safety is the hard part, so most of the work is in the bailout logic: each element is only rewritten if it passes every check (blacklisted props, structural conditions, ancestor analysis, and a lot more). There's a differential parity test & fuzzing harness that compares Boost's compiled output to what the JS wrapper components would produce and asserts they are equal.
Honest disclaimer: RN core is trying to make this superfluous. RN 0.78 (with React 19) shrank the initial-mount advantage considerably, and 0.82 added a `reduceDefaultPropsInText` flag (default since 0.85) explicitly aimed at this overhead. The RN team's stated goal is to make these wrappers cheap enough that using the underlying native components like this is unnecessary. Where it still pays off today is re-render-heavy screens. On a constantly-benchmark constantly updating a lot of `<Text>`, stock RN drops to ~32 FPS at the heaviest load while Boost holds 60, ~69% faster on iOS and ~55% on Android. As RN lands more of these optimizations I expect that gap to close, and the benchmark is built to track exactly that.
Repo: https://github.com/kuatsu/react-native-boost Benchmarks + methodology: https://react-native-boost.oss.kuatsu.de/docs/information/be...
Feedback genuinely welcome!