Hermes and JSI: runtime versus interface
Prerequisites: 01-hermes-pipeline, 03-module-interface-map
Runtime and interface
Mental model verified
Hermes executes JS and owns the JS heap. JSI defines an engine-independent C++ interface through which React Native and native libraries can expose functions and host objects. A host object reference is a capability with lifetime and thread constraints, not free shared memory.
[S03] [S04]Worked flow synthesis
A native image decoder can keep an image buffer native and expose a small JS-visible handle, avoiding repeated huge JS payloads. The design still needs ownership rules and a copy/convert audit. This is an illustrative architecture.
[S04] [S13]Engineering decision synthesis
Prefer an established module abstraction unless you need lower-level behavior. If using JSI directly, document which thread accesses the runtime, when native objects are released and whether values are copied.
[S04] [S12] [S13]Failure mode and improvement verified
Retaining a JS runtime value and touching it on a native worker can crash. Expo specifically restricts JavaScriptValue access to synchronous JS-thread functions. Keep worker payloads native or converted, then return through the module API.
[S12]Check yourself: Does a JSI host object imply every value transfer is zero-copy?
No. It can hold native references, but a particular API may still allocate or convert payloads.