RFC: WebWorker interface via an N-API module
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Quiet
- Tech stack
- cpp, javascript
- Domain
- backend-api-design, devtools
Research direction
Begin by reading related issues #116, #183, and #185, along with the referenced v7 fork work, to understand the N-API and runtime assumptions. Then evaluate the proposed Worker surface, per-engine threading model, structured-clone and transferable requirements, and lifecycle questions. Done means the open design questions are resolved into an agreed implementation plan.
Written by the indexing model from the issue text.
Description
Intent
Land the N‑API + underlying JS‑runtime updates needed to expose a WebWorker interface as an N‑API module, so the Factotum BabylonJS app can lift‑and‑shift from the browser/PWA into BabylonNative with minimal code change.
Why this matters
- Factotum's data pipeline was moved onto a Web Worker; on‑device that gave a ~10 fps uplift on Quest 1/2, Pico 4, and similar standalone headsets (pulling the pipeline off the render thread).
- To carry that architecture into BabylonNative, BabylonNative needs a Worker‑compatible surface — cleanest delivered as an N‑API module exposing the
Workerinterface (construct,postMessage, transferables,onmessage/onerror,terminate), backed by the runtime's threading/isolate model. - Revenue imperative: in‑app purchases are broken/non‑existent for immersive PWAs on the Meta Horizon Store and Pico Store (even as of June 2026). Shipping as a native (BabylonNative) app is currently the only viable monetization path on those stores, so unblocking Factotum → BabylonNative is business‑critical for BabylonJS‑community devs whose complex BabylonJS apps depend on revenue (and storefront placement).
Why the N‑API track comes first
A Worker‑as‑N‑API‑module needs a solid, modern N‑API surface across the runtimes BabylonNative ships:
- N‑API conformance + cross‑engine parity (the #116 + v7 track) so addons behave the same on V8 / JSC / Chakra.
- A shared
libnapiso in‑process addons resolve modules dynamically, allowing for less hacky build setups to exclude N-API plug-ins that aren't used and align to other runtimes (#183). - On Android specifically, a JSC that can keep up (see the jsc‑android → Bun‑JSC RFC, #186) — Worker payloads use modern JS (structured clone, BigInt, transferables) that 2019 JSC can't even parse.
Proposed shape (for discussion)
- An N‑API module exposing a
Workerclass: construct from a script/module;postMessagewith structured‑clone + transferableArrayBuffers;terminate;onmessage/onerror. - Backed by a second runtime instance/isolate on a worker thread, with a thread‑safe channel (
napi_threadsafe_functionor equivalent). - Reuse BabylonNative's existing JS dispatch / task‑runner where possible.
Open questions
- Per‑engine threading model (V8 isolate‑per‑worker; JSC
JSContextGroup; Chakra runtime‑per‑worker) and whichnapi_*primitives we standardize on. - Structured‑clone + transferable depth (ties into the v7
ArrayBufferdetach work). - Lifecycle/GC ownership across the thread boundary.
Related N‑API track: #116, #183, #185 (+ the v7 work staged as fork PR rebeckerspecialties/JsRuntimeHost#4).
- Dominant language
- C++
- Stars
- 22
- Forks
- 23
- Avg merge
- 4d 8h
- Merged PRs (30d)
- 3
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from BabylonJS/JsRuntimeHost
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
BabylonJS/JsRuntimeHost#234 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
BabylonJS/JsRuntimeHost#173 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
BabylonJS/JsRuntimeHost#241 · 3 comments ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
BabylonJS/JsRuntimeHost#228 ·
Maintainers usually reply within 1 day
-
napi_unwrap does not reject objects that were never wrapped (V8 port faults, QuickJS port confuses types)Possibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 4/5 3-5 days Newbie friendliness 68/100
BabylonJS/JsRuntimeHost#226 ·
Maintainers usually reply within 1 day
All issues in BabylonJS/JsRuntimeHost
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
WebAssembly/binaryen#9207 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
godotengine/godot#124139 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
ChicoState/autovalidate#195 ·