Glossary / Polyfills
Polyfills
A polyfill is runtime code that implements a missing API or behavior in an environment that does not provide it natively. Polyfills can extend compatibility, but they add download and execution cost, may be incomplete, and cannot reproduce every browser capability or native security boundary.
Syntax transforms are not polyfills
A transpiler can rewrite unsupported syntax, while a polyfill supplies runtime API behavior such as Promise, URL, or an array method. Some features cannot be faithfully polyfilled (for example, syntax or host capabilities requiring browser internals). A polyfill should implement the relevant specification semantics for the supported use cases, not merely expose a same-named function.
Polyfills can be global (patching built-ins) or scoped/module-based. Global patches may conflict with native implementations, other polyfills, realms/iframes, or security policies. Selective injection based on a documented browser target can reduce cost, but detection and chunk delivery must be reliable.
Engineering guidance
Define a support matrix first. Add only required polyfills, prefer well-maintained implementations, test behavior and edge cases, and measure impact. Consider feature detection and graceful fallback instead of global patching. Keep polyfills early enough for dependent code and verify CSP, load order, and worker/iframe realms as applicable.
Interview questions
- Polyfill vs transpile? A polyfill adds runtime API behavior; transpilation rewrites syntax.
- Can every feature be polyfilled? No; some depend on syntax, browser internals, or privileged capabilities.
- Why can global polyfills be risky? They mutate shared built-ins and may conflict across versions or realms.
- How choose polyfills? From the support matrix and actual APIs required, then measure and test.
- Does a polyfill guarantee native-equivalent behavior? Not necessarily; compatibility and semantics must be evaluated.