JavaScript's Execution Context and Nature

Key Insight

The practical reality of JavaScript is heavily dictated by its implementation in web browsers, which significantly influences the language's evolution. Occasionally, the official JavaScript specification may propose new behaviors that browser engines refuse to adopt if doing so would break existing web content that relies on historical behaviors. In such cases, TC39 often adjusts the specification to align with the reality of the web, exemplified by renaming `Array.prototype.contains()` to `includes()` and `flatten()` to `flat()` during 'smooshgate' to avoid conflicts. Appendix B of the specification explicitly documents these mismatches, detailing additions and conflicts (e.g., 0-prefixed octal literals, `escape()`, `String.prototype.anchor()`) that are allowed for web JavaScript but should generally be avoided in other environments for future compatibility.

Many functions that resemble JavaScript, such as `alert()`, `console.log()`, `fetch()`, or Node.js's `fs.write()`, are actually environment-specific APIs rather than core components of the JavaScript specification. These APIs adhere to JavaScript syntax rules but their behaviors are controlled by the specific runtime environment. Similarly, browser Developer Tools, while 'JS-friendly', prioritize Developer Experience (DX) over strict specification adherence. This can lead to quirks in how code behaves within the console (e.g., `var` or `function` declarations in global scope, `use strict` activation, `this` binding), meaning the console should not be treated as an exact reflection of strict JavaScript semantics.

JavaScript operates as a compiled language, rather than a purely interpreted one, due to its execution model. The specification requires 'early errors', necessitating that code be parsed into an Abstract Syntax Tree (AST) before execution to catch static errors like duplicate parameter names. This parsed AST is then transformed into an optimized binary bytecode, which a JavaScript virtual machine (VM) executes, often employing Just-In-Time (JIT) compilation and optimization. Web Assembly (WASM), introduced for performance, enables non-JavaScript languages like C to run in JavaScript engines by representing programs in a binary format that largely bypasses JavaScript's typical parsing and compilation steps. WASM augments web capabilities and is not intended to replace JavaScript, which remains a versatile multi-paradigm language supporting procedural, object-oriented, and functional programming styles.