Demystifying Hermes: How Meta Re-Engineered JavaScript for Mobile Constraints

Think about how many times you’ve opened an app on your phone to quickly check something, only to sit there staring at a frozen splash screen that takes forever to load. It’s incredibly frustrating. As users, we usually give up and close the app if it doesn’t start instantly. In mobile engineering, beating this cold start delay is one of the hardest performance battles you will face. For a long time, React Native apps suffered from this exact problem because of how traditional JavaScript engines worked. To fix it, the team at Meta did something radical: they built Hermes — a JavaScript engine made specifically for mobile phones. This week, I did a deep dive into how Hermes operates under the hood, handles memory, and completely changes how our code runs.

For years, React Native relied on JavaScriptCore (JSC) — the engine powering Apple’s Safari browser. While JSC is an incredibly fast, highly optimized engine for the web, web architecture does not translate perfectly to mobile constraints.

To solve this, Meta built Hermes: a JavaScript engine purpose-built from the ground up for mobile devices. Let’s look at what makes Hermes fundamentally different from desktop JavaScript engines like Chrome’s V8 or Safari’s JavaScriptCore (JSC).

The Core Battle: JIT vs. AOT Compilation

To understand the genius of Hermes, we must first look at how traditional JavaScript engines operate. Engines like V8 and JSC rely on Just-In-Time (JIT) compilation:

1. The Text Payload: Your application code is bundled and shipped to the device as a massive file of raw JavaScript text strings.
2. On-Device Compilation: At the exact moment your user opens the app, the mobile device must parse that text, generate an Abstract Syntax Tree (AST), convert it to bytecode, and aggressively optimize hot functions into native machine code.
3. The Resource Tax: Because the machine is compiling code while the user is waiting, the device must keep the raw text, the bytecode, the compiler, and the tracking metrics in the device’s RAM simultaneously. This creates a slow startup time and a heavy memory footprint.

How Hermes Flips the Script

Hermes utilizes an Ahead-of-Time (AOT) compilation pipeline via the hermesc compiler.

Instead of waiting for the user’s phone to do the work, compilation happens during your build phase on your laptop or CI/CD server. Your raw JavaScript is compiled directly into low-level binary bytecode before it ever leaves your machine.

• When a user launches a Hermes-backed React Native app: The engine completely skips parsing, AST generation, and runtime compilation.
• It simply maps the pre-compiled binary bytecode straight into memory and executes it via an interpreter loop.
• The application launches instantly, and memory consumption drops significantly because the engine doesn’t need to host a heavy runtime compiler in RAM.

JSC(Left) and Hermes(Right) Flow

Memory Management: Meeting Hades

Garbage Collection (GC) in a user interface is highly sensitive. If a garbage collector blocks your execution thread for more than a few milliseconds to clean up dead objects, the app will drop frames, causing visible stutter or lag.

Hermes addresses this with an optimized garbage collector called Hades. Hades adapts its strategy entirely based on device architecture:

1. Incremental Mode (Legacy 32-bit Constraints)

On older, resource-constrained 32-bit systems, Hades runs incrementally directly on the main JavaScript Thread. It slices memory cleanup into tiny intervals. However, because it shares the execution thread with your app code, it triggers short Stop-the-World (STW) pauses. If the app’s memory heap is bloated, these pauses can lengthen, leading to UI animation stutter. Fortunately, in modern mobile ecosystems, 32-bit architectures are effectively obsolete.

2. Concurrent Mode (Modern 64-bit Systems)

On modern 64-bit devices, Hades runs concurrently, spawning its own dedicated background thread that executes parallel to your JavaScript code. It achieves this via a brilliant 3-step lifecycle:

• Root Marking: Hades triggers a microscopic, microsecond-level STW pause on the JS thread. It takes a rapid, frozen snapshot of the app’s roots — the variables and native C++ pointers actively in use by your running code.
• Concurrent Scanning Phase: Hades immediately unlocks the JS thread so your app can continue running smoothly. On its own background thread, it uses the root snapshot to trace every reachable object in memory. Anything it cannot reach from the roots is safely flagged as inactive garbage.
• Weak Reference Finalization: Once the background scanning concludes, Hades briefly syncs back with the JS thread to execute C++ object destructors and safely sweep away the dead memory objects.

On 64-bit devices, Hades performs most of its marking work concurrently on a background thread. Only short synchronization phases require stopping the JavaScript thread, dramatically reducing pause times compared to earlier collectors. Meta reported pause times up to **30× shorter** on 64-bit devices after introducing Hades.

The Engineering Tradeoff

In software architecture, there is no free lunch. Moving away from a runtime JIT engine comes with a distinct penalty: Peak Compute Performance.

Because Hermes lacks a dynamic JIT compilation loop, it cannot dynamically optimize heavy loops down to bare-metal native machine code at runtime. For standard mobile operations (rendering lists, fetching APIs, and updating states), Hermes is incredibly optimal. However, for CPU-intensive, math-heavy applications (like data visualization or real-time physics calculations), a JIT engine like V8 will outpace it.

Ultimately, Meta designed Hermes with a clear priority: sacrifice raw computational horsepower for an application that starts instantly, uses less battery, and leaves a remarkably small memory footprint on mobile devices.