JIT JS engine pipeline vs Hermes pipeline

The speaker describes a typical JIT pipeline: parse JavaScript into bytecode, interpret it, then compile frequently used functions into machine code. Hot functions may receive further speculative optimization, with deoptimization if an assumption fails. These stages cost CPU and memory, and can leave multiple code versions in memory.

Hermes compiles source on the developer’s machine, optimizes an SSA intermediate representation, and produces a bytecode bundle for the device. At runtime, the executable is memory-mapped and run without a JIT. The speaker says this is a deliberate choice for the React Native workflow.

The speaker connects Hermes to React Native’s need for better time to interactive, especially on low-end devices. Facebook’s Marketplace tab was an example where slow initial loading and interactivity were a concern. Since React Native code is generally bundled with the app, its runtime environment is more controlled and its bytecode can be prepared ahead of time.

Browser JavaScript varies widely, so browser engines use multiple JIT tiers to handle diverse workloads. Node.js often runs repetitive work for longer periods on powerful machines, which can justify paying a warm-up cost for optimized code. React Native workloads are typically more ephemeral: most startup functions run zero or one time, and later activity mainly responds periodically to user interactions.

The speaker adds that mobile memory constraints can make JIT compilation less attractive. They say React Native apps using JavaScriptCore typically do not use its JIT, while noting they do not have the full context for that behavior.