The document discusses the performance of React Native compared to native development, highlighting its advantages in cross-platform compatibility and reduced development time, while also addressing its limitations in achieving native-level performance due to the asynchronous nature of its architecture. It explores the challenges related to the communication bridge between JavaScript and native code, proposing improvements with 'Bridge 2.0' to minimize overhead during data transfers. The future of React Native is seen as a balance between utilizing native capabilities and the efficiency of JavaScript processing.

1. React-Native Performance
Be more likes the natives
9th March 2018

2. Native
The good
● Fast
● Responsive
● Smooth animations
● Adhere to guidelines by Google and Apple
● Latest innovations from their large in-house dev teams
● Works well with the device hardware

3. Native
The not so good
● Different SDK tools
● Different frameworks
● Tend to bring out new languages e.g. Swift, Kotlin
● Costly $$
○ x2 teams with specific knowledge
○ x2 design, development, testing
● Little or no code sharing
● Takes time to develop

4. Hybrid
● Phonegap. Html5
● Cordova.
● Intel. Html5
● Xamarin. C#
● etc..
Majority uses Html5 and the reason they struggled was performance.. This was a bad
user experience and made no use of any shiny new tech your phone might have.
Always tough to talk to the hardware properly

5. React-Native
● Cross platform
● Write once
● Single code base
● Underpinned by React to only update the components it needs to
● Re-use existing skills from web development
● Less time to develop
● Single entry point for testing
● Debugging using Chrome debugger
● Hot-reloading
○ Native you need to spin up the emulators each time. Slow. Time consuming
.

6. RN - Component mapping to Native

7. RN - Architecture
NativeJS
JS Engine called
JSCore.
Single Thread
Obj-C, Swift. Java.
Single Thread +
Background threads

8. But wait…
Think about “the performance”
Where’s my 60fps

9. Performance
● We simply can’t call native functions in a synchronous manner.
○ User would be left waiting and wastes time which we could use to do more useful stuff

10. Performance
● Asynchronous is out too.
○ It’s better, but having lots of asynchronous calls would all add up
○ So what to do?

11. JS
Fast

12. Native
Fast

13. RN - Architecture
Native
Fast
JS
Fast
Slow
The Bridge

14. Another Bridge

15. Problems with the Bridge
● We’re dealing with 2 different realms
● Vars declared on one side cannot be accessed on the other side
● Traversing the bridge needs to be kept to a minimum
● JS is running on a single thread
● Native is running on a single thread… although may have background threads
● For each frame, we don’t want to be crossing the bridge

16. Bridge 2.0 - The RN Approach
● Their bridge is Asynchronous, Batched and Serializable
● Keeps traversing over the bridge to a minimum
● Let the JS side batch up what needs to happen and send over the Bridge to Native.
● It does this by batching events for transportation
○ E.g. If there a list of animation events, these are batched and sent over the bridge for processing at
Native side. Native can handle it faster. You’re still doing Native - just less.
● A message queue is created, serialised and passed over the bridge.
● Holy grail is to declare what your intention is in JS and send once over to a native
driver

17. Bridge 2.0 - The RN Approach
● If you debug in Chrome you can see the JSON packets that are passed around
between layers using websockets. This is the serialised JSON
Caveats
● Writing the drivers is complex.
● Large part of RN is to provide suitable drivers to handle what comes across the
bridge
● If some functionality does not exist, you need to get your hands dirty and write
native drivers

19. Future
● Less bridge walking
● RN is constantly updating their API
● More heavy lifting on the Native side
● You can ask the native side to do a lot of the processing but this can be less
productive than doing it on the JS side.
○ Sometimes unavoidable due to limitations of libs or functionality that is not yet supported.