// the take
Hermes is Meta's JS engine built specifically to make React Native app startup fast, via ahead-of-time compilation to a compact bytecode instead of parsing/JIT-ing JS at launch. It's for RN app developers and native mobile engineers who need to build or patch the engine itself, not for anyone building a general-purpose JS runtime.
AOT bytecode compilation genuinely moves the needle on cold-start time on low-end Android, which is the actual problem it was built to solve. It ships JSI for native interop plus a maturing Node-API (napi) layer, so native modules aren't locked into one binding style. CDP support (API/hermes/cdp) means you get real Chrome DevTools debugging instead of a bespoke protocol. It's also the default RN engine, so it's exercised by an enormous number of production apps, not a toy.
The README flags that Hermes releases are pinned to specific RN versions and a mismatch can hard-crash your app in production — that's a real operational hazard, not a theoretical one. Building it from source needs the full native toolchain (cmake, Ninja, platform-specific toolchains for Android/iOS/Windows), so hacking on the engine itself has a steep setup cost compared to most JS tooling. It optimizes for startup latency, not sustained throughput, so it's the wrong engine if you're running anything long-lived or CPU-heavy outside the RN app lifecycle. Documentation is almost entirely build/integration instructions — there's no clear map of which JS/ECMAScript features or proposals are actually supported versus V8/JSC.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →