Learn Hermes JS Engine - Core Concepts & Main Architecture

#Introduction

In episode 1 we learned that Hermes excels because of bytecode precompilation and a JIT-free design. Now we go one level deeper: how does Hermes work from the inside?

Episode 2 dissects the compilation and execution pipeline: the parser, bytecode compiler, garbage collector, and interpreter. Then we cover the HBC bytecode format and its serialization, plus the three runtime modes that make Hermes fast.

#The Overall Hermes Pipeline

Hermes works in two clearly separated phases: compile time and runtime.

source.js --> Parser --> AST --> BytecodeCompiler --> .hbc (bytecode)
                                                          |
                          [compile time]                   v
                          [runtime]                     Interpreter
                                                            |
                                                            v
                                                       Garbage Collector

At compile time, the source is compiled once into bytecode. At runtime, Hermes just executes that bytecode with the interpreter — no parsing and no JIT. All of this is done by four main components.

#Parser: From Source to AST

The first component is the parser. Its job is to turn source code into an AST (Abstract Syntax Tree) — a hierarchical representation of the code's structure. Hermes' parser is designed to be fast and memory-efficient, because in React Native parsing happens at build time, not when the user opens the app.

The parser also does light semantic analysis: detecting syntax errors, storing line locations for source maps, and preparing the data the compiler needs. In Hermes, the parse result flows directly into the bytecode compiler without keeping the full AST in memory for long.

#Bytecode Compiler: From AST to HBC

The second component is the bytecode compiler (which lives in the hermesc binary). It takes the AST and produces bytecode — simple instructions consumed by the interpreter. Unlike JIT, which produces machine code per CPU architecture, Hermes bytecode is portable: a single .hbc file can run on both ARM and x86.

The compiler also performs optimizations such as static property resolution: a property name like obj.length is resolved at compile time, so the interpreter doesn't need a hash lookup at runtime.

#Hades Garbage Collector

The third component is the garbage collector (GC), called Hades in modern Hermes. Hades is a generational and concurrent GC:

• Generational: young and old objects are managed separately. Minor GC only sweeps young objects, which usually die quickly — the process is lightweight.
• Concurrent: most of the GC work runs on a background thread, so the app doesn't stop entirely during collection.
• Snapshot-at-the-beginning: a marking technique that ensures a consistent heap snapshot without blocking the main thread for long.

The result: low and predictable pause times — critical for UI that must stay responsive. In episode 6 we'll dissect the GC more deeply.

#Interpreter: The Execution Tailor

The fourth component is the interpreter. It reads bytecode instructions one by one and executes them: arithmetic operations, function calls, property access, and control flow. The Hermes interpreter is a register machine, not a stack machine — every function has its own local register slots, which makes execution faster and bytecode more compact.

Because it's a pure interpreter without JIT, its performance indeed doesn't rival V8 for compute-heavy work. But for mobile workloads, the advantages of determinism and memory are far more valuable.

This pattern makes Hermes unique among modern engines: no JIT, but with bytecode already optimized at compile time. The result is predictable runtime behavior — no gradual warm-up that degrades performance in the first seconds like in JIT engines.

#Bytecode and Serialization

Hermes bytecode is stored in the HBC (Hermes Bytecode) format. This file is the result of serialization — the in-memory bytecode structure is written out as a stream of bytes that can be stored or transmitted. This serialization carries important consequences:

• Portability: a single HBC file can be shared across CPU architectures.
• Deterministic: the bytecode output is stable for the same input, supporting reproducible builds.
• Integrity: the bytecode can be signed, because the file is already final at build time. We cover this in episode 13.

Take a look at the bytecode output of a simple file using a debug flag:

echo "const a = 1; print(a + 2);" > test.js
build/bin/hermesc -dump-bytecode test.js

The -dump-bytecode output shows instructions like LoadConstInt, Add, and Call — the compact machine language the interpreter understands.

One note: this bytecode isn't human-friendly — there are no variable names, only register locations and constants. That's why debugging Hermes code usually uses source maps rather than reading bytecode directly.

#Runtime Mode: Full AOT

The first mode is full AOT (Ahead-Of-Time). In this mode, the entire source is compiled to bytecode at build time, and the runtime only executes .hbc files. This is the default in React Native: the JavaScript bundle is compiled by hermesc before it goes into the APK. Its advantage is minimal startup — no parse work at all when the app launches.

#Runtime Mode: Lazy Compilation

The second mode is lazy compilation. Hermes doesn't always compile all functions at once. Large functions that haven't been called yet can have their compilation deferred until actually needed. This technique reduces initial memory allocation and speeds up startup even further — code that's never executed never needs to be compiled. The trade-off is that the first call to such a function is slightly slower.

#Runtime Mode: Inline Caching

The third mode is inline caching. The interpreter caches property lookup results at specific access sites. If user.name is accessed repeatedly at one spot, the interpreter remembers the property's location from the first call, so subsequent accesses don't repeat the search from scratch. This is the main compensation because Hermes has no JIT — the interpreter performs small dynamic optimizations without changing machine code.

Property access that benefits from inline caching

// If the user shape is consistent, accessing user.name becomes cheap
// after the first call because it's cached by the interpreter.
function getNames(users) {
  const names = [];
  for (const user of users) {
    names.push(user.name);
  }
  return names;
}

Remember one condition: a consistent object shape. If user changes shape on every iteration (runtime polymorphism), the cache can't be used and performance drops — we cover this in episode 15.

#Conclusion

Hermes' architecture is now clear in your head. Here's what you must take away:

• Hermes pipeline: parser → bytecode compiler → interpreter, with the Hades GC running alongside execution.
• Parser and compiler work at build time; the interpreter only executes bytecode at runtime.
• Hades is a generational and concurrent GC that keeps pause times low.
• HBC bytecode is a serialized format that is portable, deterministic, and ready to be signed.
• Three runtime modes: full AOT for the fastest startup, lazy compilation to save initial allocation, and inline caching to speed up repeated property access.

Next, in episode 3 we get hands-on: adding Hermes to a React Native project, setting up the Android/iOS build environment, and verifying Hermes runs in the emulator. See you there!