Learn Hermes JS Engine - History, Background & Why Use Hermes

#Introduction

In episode 0 we set up our environment — Node.js, React Native, and the Hermes repo. Now it's time to answer the most fundamental question: why does Hermes exist?

Episode 1 covers the background behind Hermes' birth at Meta, compares it with other engines, and dissects its main advantages. By the end of this episode, you'll know when Hermes is the right choice — and when you should avoid it.

#The Problem That Sparked It

Before Hermes, React Native on Android used JavaScriptCore as its engine. This initially made sense: one engine for both iOS and Android. But as React Native began to be used for large-scale apps on cheap devices, Meta discovered real problems:

• Slow startup: parsing thousands of lines of JavaScript on low-end devices takes hundreds of milliseconds — it feels like lag.
• Memory-hungry: the JIT (Just-In-Time) compiler creates large memory overhead for apps with a small RAM budget.
• Heavy apps: the complex Facebook feed made the first render feel slow.

JIT is indeed fast once functions are warmed up, but that warming-up process is exactly the problem. On mobile devices with 1-2 GB of RAM, the cost of parsing, compiling, and JIT warmup during cold start is very expensive.

#The Birth of Hermes at Meta

Hermes was developed internally by the React Native team at Meta starting in 2016, with a single philosophy: an engine optimized for mobile-first JavaScript, not a port from desktop. The team prioritized two things above all else: short startup time and a small memory footprint.

Hermes was announced publicly at React Native EU in July 2019 and immediately open-sourced. Adoption moved fast:

• React Native 0.64 (2021): Hermes became the default engine on Android.
• React Native 0.70 (2022): Hermes became the default on Android and iOS.
• Next: Hermes expanded to Node.js and edge runtimes, which we cover in episode 9.

The big design decision in Hermes was removing the JIT at runtime. All compilation happens before the app runs. The result? The engine stays a pure interpreter on device — fast to start, RAM-efficient, and predictable.

#Comparison with Other Engines

To understand Hermes' position, compare it with the three major engines:

engine:        V8
pembuat:       Google
strategi:      JIT penuh (TurboFan, Maglev)
fokus:         Desktop, server, Chrome
pakai_di:      Node.js, Chrome, edge
 
engine:        JavaScriptCore
pembuat:       Apple
strategi:      Interpreter + JIT (FTL, B3)
fokus:         Mobile, browser
pakai_di:      Safari, WebKit
 
engine:        SpiderMonkey
pembuat:       Mozilla
strategi:      Interpreter + JIT (Ion, Warp)
fokus:         Browser, Firefox
pakai_di:      Firefox, embedded
 
engine:        Hermes
pembuat:       Meta
strategi:      AOT bytecode + interpreter murni
fokus:         Mobile, embedded, edge
pakai_di:      React Native, edge runtimes

The most striking difference is in strategy. V8 chases peak throughput with sophisticated JIT; Hermes rejects JIT and chases deterministic startup. For mobile apps that only live a few minutes, peak throughput matters less than the first 300 ms that the user actually feels.

Example: a pure interpreter starting without JIT warmup

// In Hermes, this function runs immediately once the bytecode is loaded.
// There is no "JIT warmup" phase like in V8.
function renderHome() {
  const items = fetchInitialFeed();
  return items.map((item) => <FeedItem data={item} />);
}

On V8, the first call to renderHome is still interpreted before being JIT-compiled. In Hermes, all of this is already compiled bytecode from the start — deterministic and fast.

#Main Advantage: Startup Time

Hermes' first advantage is predictable startup time. Because the source is already compiled to bytecode at build time, the runtime doesn't need to parse and compile JavaScript when the app launches. Meta's internal measurements recorded a significant drop in React Native app startup time on low-end Android devices. In episode 5, we'll optimize this startup even further with bytecode prepackaging.

#Main Advantage: Memory Footprint

The second advantage is a small memory footprint. Without JIT, no memory is allocated for compiled machine code at runtime. Hermes also uses string compression techniques and a lightweight object model. Property hashes are computed once at compile time, so the object layout stays compact. On devices with limited RAM, this difference can determine whether an app stays alive or gets killed by the operating system.

#Main Advantage: Bytecode Precompilation

The third advantage is bytecode precompilation. JavaScript source is converted into a Hermes bytecode file (HBC format) during the build process, and this file ships with the app. The benefits are twofold:

• Faster execution because parsing happens only once at build time.
• Bundles can be signed and have their integrity verified, reducing tampering attacks. We cover this in episode 13.

Try compiling right away with the compiler you cloned in episode 0:

cd hermes
echo "print('hello hermes');" > hello.js
build/bin/hermesc -emit-binary hello.js -out hello.hbc
build/bin/hermes hello.hbc

The command build/bin/hermesc -emit-binary turns the source into bytecode, then build/bin/hermes hello.hbc runs it. We'll cover the full instructions for building the hermesc binary in episode 3.

#When Hermes Is Not the Right Choice

To be honest: Hermes doesn't excel in every scenario. Avoid Hermes when:

• The app is very compute-heavy with long math loops, because a pure interpreter loses to JIT engines in throughput.
• You need the latest ECMAScript compatibility, because Hermes adopts features more slowly than V8.
• You need Node.js with a complex ecosystem of native libraries — Hermes on the server is still niche.

For the majority of React Native apps, this trade-off is very favorable. For typical server workloads, V8 remains the champion.

#Conclusion

Now you know where Hermes comes from and its competitive advantages. Here's what you must take away:

• Hermes was born from Meta's need for fast startup and small memory on low-end mobile devices.
• With no JIT at runtime, all compilation happens at build time — startup becomes deterministic.
• Hermes wins on startup time and memory footprint, but loses to V8 on peak throughput.
• Bytecode precompilation (HBC format) is Hermes' main architectural differentiator.
• Hermes became React Native's default on Android since 0.64 and on iOS since 0.70.

Next, in episode 2 we dissect Hermes' internal architecture: the parser, bytecode compiler, garbage collector, and interpreter — how the four work together to execute JavaScript. See you there!