JavaScript · Execution Context · Tech Lead · Architecture
You are designing a plugin system where third-party scripts run in the same page. How would you reason about execution contexts, isolation, and `this`/`globalThis` risk?
Short Interview Answer
Same-realm scripts share the global execution context; isolate via iframes/workers/realms, freeze globals, and avoid relying on ambient `this`.
Detailed Explanation
All classic scripts and modules in the same realm share one Global Execution Context (modules get their own module environment but still share `globalThis`). A plugin can overwrite globals, monkey-patch prototypes, or capture privileged closures. Mitigations: run untrusted code in a sandboxed iframe or Worker (separate realm/global), expose a narrow API via `postMessage`, use `Object.freeze` / compartment patterns (SES) where available, load plugins as modules with explicit imports, and never pass privileged `this` or closures accidentally. Document that arrow functions and modules change `this` expectations. At lead level, discuss threat model: intentional malice vs accidental global pollution, CSP, and which APIs must never be reachable from plugins.
Interview Tip
Show you think in realms and attack surface, not just 'use modules'.
Common Mistake
Claiming ES modules alone sandbox third-party code — they still share `globalThis` and the DOM in the same window.