Glossary / Language editions and compatibility
Language editions and compatibility
ECMAScript editions describe standardized additions to JavaScript over time; compatibility describes whether a particular syntax feature or runtime API works in the environments an application supports. These are related but distinct questions: a feature may be standardized yet missing in an older browser, supported natively by one runtime but not another, or transformed by a build while its required API remains absent.
Editions, proposals, and support
ECMAScript 2015 (ES6) introduced major syntax and runtime features, followed by annual editions. Modern code often uses features from many editions, but feature support must be assessed per engine version. TC39 proposal stages describe the maturity of ideas; proposals can change before standardization, and experimental engine flags do not establish production portability.
Compatibility has multiple layers:
- Parsing: Can the engine parse the syntax at all?
- Semantics: Does it implement the specified behavior correctly?
- Runtime APIs: Are the required built-ins and host APIs available?
- Build tooling: Can bundlers, minifiers, test runners, and linters parse and preserve the feature?
- Operational targets: Do browsers, embedded webviews, server runtimes, and extensions match the declared support policy?
Transpilation, polyfills, and feature detection
Transpilation rewrites syntax (for example, optional chaining) into older syntax. A polyfill supplies missing runtime behavior (for example, a collection or web API) where feasible. Some capabilities cannot be faithfully polyfilled, and built-ins may have performance or semantic differences. Feature detection tests the needed capability directly; user-agent sniffing is brittle because browser labels do not reliably indicate enabled features.
if (typeof globalThis.structuredClone === "function") {
return structuredClone(value);
}
return appSpecificClone(value); // Explicit fallback policy
A fallback must preserve the application's required data semantics; silently using JSON round-tripping is lossy for many values.
Engineering workflow
Set a documented target matrix based on users, analytics, customer contracts, embedded clients, and support lifetime. Configure Babel/TypeScript/Vite targets and test environments consistently. Use tools such as compatibility tables and automated builds, but verify actual feature behavior in representative devices. Minimize polyfills to reduce bundle size and supply-chain surface. When dropping a target, communicate the change and measure affected traffic first.
Interview questions
- Transpiler versus polyfill? A transpiler rewrites syntax; a polyfill implements a missing API at runtime.
- Why is “ES2022 support” not a complete compatibility statement? Different environments implement features and host APIs at different versions; the actual target matrix matters.
- Why prefer feature detection to user-agent detection? It checks the capability needed rather than inferring it from a browser string.
- Can a transpiler make any new API work on old browsers? No. Syntax can often be transformed, but runtime APIs need polyfills and some capabilities cannot be reproduced.