bi-05 — Broader Ideas
Boundaries cost, everywhere
The four costs of crossing the JS↔C++ boundary — crossing, conversion, checks, side effects — generalise to every boundary in your systems:
| Boundary | Conversion cost | Hidden side effect |
|---|---|---|
| JS ↔ DOM | string representations | forced layout |
| App ↔ database | serialisation, type mapping | a query, a lock |
| Service ↔ service | JSON encode/decode | a network round trip |
| Main thread ↔ worker | structured clone | none, but the clone dominates small jobs |
| Native ↔ WASM | memory copies at the boundary | none |
Profile the boundary, not just the function. A JS flame chart cannot show you conversion cost or a style flush triggered by a getter — which is exactly the failure mode this module corrects.
Generated code as a correctness strategy
Thousands of interfaces each needing an unwrap, a security check, spec-conformant coercion, and correct exception translation. No human process gets that right thousands of times, so it is generated.
The pattern to take: when a rule must hold across hundreds of instances, generate or lint it rather than documenting it. Your equivalents: API handler boilerplate, authorisation checks, telemetry instrumentation, serialisation. If you find yourself writing "remember to always…", you have identified a codegen or lint target.
The cost is navigability, and it is real — budget onboarding for it.
Isolated worlds as an isolation primitive
Same objects, different views, no shared expandos. The same idea appears in: database schemas per tenant, namespaced caches, JS realms, container namespaces. Isolation by separate view over shared storage is cheaper than duplicating the storage and stronger than a convention.
Next
bi-11 explains why a microtask-resolved promise does not yield to rendering; fw-11 sends you back
into React's source knowing why Fiber objects initialise every field in the constructor.