Static Hermes: the Next Generation of Hermes

Mikov introduces Joe Native, whose React Native app has fast startup but stutters during demanding work such as scrolling long lists and complex animations. Profiling and rewriting JavaScript cannot overcome the interpreter’s performance limits, while C++ extensions can be difficult to write and maintain. Static Hermes aims to compile selected, typed JavaScript ahead of time, leaving the rest of the app on Hermes bytecode.

JavaScript functions can receive values of many types, making efficient native compilation difficult. TypeScript and Flow annotations alone are unsound: Mikov’s example passes undefined from out-of-range array access into a function annotated to receive numbers. Static Hermes adds opt-in runtime checks that throw a range exception, ensuring values match declared types in compiled code; existing Hermes code can coexist with it.

Mikov demonstrates Static Hermes on the math-heavy nbody.js benchmark. Its initial native version ran in 550 milliseconds, matching Hermes, while a later version was 10 times faster; he said the team saw potential for 20 times the speed. He also shows compact ARM64 output and says other benchmarks achieved up to five times the speed, with further work underway.

Sound types also enable Static Hermes to call native platform functions with no conversions, allocations, or indirections. Mikov reports call overhead 15 to 80 times lower than JSI. He explains that native calls require explicitly marked unsafe sections, then demonstrates JavaScript bindings to SQLite and a call to C’s getenv function, without writing C++.

Mikov says Static Hermes is a work in progress and not yet suitable for general use; it can be difficult to use and some parts are broken. TypeScript support was contributed by Amazon, while the Hermes team had added Flow support. He invites feedback through Discussions on the Hermes GitHub repository and points viewers to benchmark and FFI examples.