Going Over The Speed Limit Synchronous Rendering in React Native

Kol describes a “Pepsi Challenge”: build the same simple app in React Native and natively, then see whether users can tell them apart. He says React Native was close but still distinguishable in areas such as animations, navigation, gestures, and interactions. At Wix, flicker when pushing screens and scrolling lists showed that gap in practice.

Kol explains that React Native’s JavaScript and native realms communicate asynchronously over a bridge. When scrolling reveals an uninitialized row, the native side must wait for JavaScript to handle the scroll event, render the row, and send view commands back. That delay can leave a blank area briefly; native lists avoid it by creating and drawing rows synchronously.

Kol proposes a synchronous root view for navigation and lists, with a registry that stores a component’s native view instructions during app initialization. Later, native code could create or update views from those stored instructions without waiting for the bridge. The setup moves some work to startup so screen content or list rows can appear immediately.

The proof of concept records UIManager commands when React renders a template component. Kol describes temporarily replacing UIManager functions with stubs, saving their arguments as a JSON recipe, and executing those commands natively when a synchronous view is needed. This approach only supports declarative components: prop changes cannot add or remove parts of the view tree.

Kol says synchronous rendering excludes JavaScript business logic inside the component and requires its view structure to stay fixed. For a cell that conditionally shows “Hi” or “goodbye,” he suggests preparing display props such as `flex` and `none` in the list’s data transformation. He presents a synchronous ListView proof of concept on Wix’s GitHub account.