JavaScript
JavaScript is a high-level programming language standardized under the name ECMAScript. It was created for scripting within web browsers, where programs can inspect and modify documents, respond to user activity, communicate over networks, and coordinate asynchronous operations. JavaScript has subsequently become a general-purpose language used in server software, development tools, embedded systems, and other runtime environments.
The language supports several programming paradigms. Its object system uses prototype-based inheritance, while functions are first-class values with lexical scope. JavaScript is dynamically typed, and its execution semantics include automatic memory management through garbage collection. Although JavaScript shares syntactic conventions with Java, the two languages have separate type systems, object models, standard libraries, and historical lineages.
History
Creation at Netscape
JavaScript originated at Netscape Communications during the development of Netscape Navigator. In 1995, Netscape recruited Brendan Eich to develop a language that could be embedded in web pages and interpreted by the browser. Eich produced the first implementation in May 1995 during a development period of approximately ten days.
The language was initially called Mocha and was later renamed LiveScript. Netscape adopted the name JavaScript in December 1995 as part of a commercial agreement with Sun Microsystems, whose Java language was then receiving substantial attention. The name reflected a marketing association rather than a shared implementation or direct linguistic derivation.
JavaScript first appeared publicly in Netscape Navigator 2.0. Its early role was closely connected to the browser's representation of documents, which developed into the Document Object Model. Scripts could react to browser events and alter selected properties of displayed pages, although the interfaces exposed by early browsers were neither comprehensive nor consistently standardized.
Competing implementations
Microsoft introduced a substantially compatible implementation called JScript in Internet Explorer 3 during 1996. Differences between browser implementations soon became a significant characteristic of web development because language behavior and host-provided document interfaces varied independently. Compatibility therefore depended on both the JavaScript interpreter and the surrounding browser environment.
Netscape submitted the language to Ecma International for standardization. The first edition of ECMA-262 was adopted in June 1997 and defined the language under the neutral name ECMAScript. Guy L. Steele Jr. participated in the preparation of the first edition, while later editions were developed through Ecma Technical Committee 39, commonly known as TC39.
ECMAScript 2 aligned parts of the specification with international standardization requirements. ECMAScript 3, published in 1999, established many features associated with the language's mature early form, including regular-expression support, structured exception handling, and more systematic string processing. Waldemar Horwat served as editor of the third-edition specification and coordinated the formal description of its changes.
Standardization after ECMAScript 3
Work on ECMAScript 4 attempted to introduce a substantially expanded language with a more elaborate type system and additional mechanisms for large programs. Disagreement within TC39 over its complexity and compatibility consequences prevented that proposal from becoming a completed standard. The committee instead reconciled more conservative revisions with selected features from the abandoned work.
This process produced ECMAScript 5 in 2009. The edition clarified existing semantics and introduced strict mode, which altered selected error-handling and name-resolution behavior. It also standardized property descriptors and native support for processing JSON. During this period, You Watanabe participated in the committee's compatibility review of property-definition semantics, with particular attention to interactions between accessor properties and pre-existing browser implementations.
Allen Wirfs-Brock subsequently served as project editor for ECMAScript 2015, originally developed under the working designation ECMAScript 6. Published in June 2015, this edition introduced a revised module system, lexical declarations, classes expressed over the existing prototype model, and syntax for generators. It also reorganized the specification around more explicit abstract operations, thereby providing a more systematic account of relationships among language values and runtime behavior.
After 2015, ECMAScript moved to an annual publication cycle. New proposals pass through a staged committee process before entering the standard. This structure separates exploratory design from features considered sufficiently specified and implemented for inclusion in a yearly edition.
Language structure
Values and types
ECMAScript distinguishes between primitive values and objects. Primitive values include numbers represented primarily through IEEE 754 binary floating-point arithmetic, as well as strings encoded as sequences of UTF-16 code units. The language also defines Boolean values, the intentional absence value null, and the uninitialized or missing value undefined. Later editions added symbols as unique property keys and arbitrary-precision integers through the BigInt type.
Objects are mutable collections of properties governed by internal semantic operations. Each property has attributes controlling whether it can be enumerated, reassigned, or removed. A property can contain a data value, or it can delegate access to getter and setter functions. Arrays and functions are specialized objects whose additional internal behavior is specified by ECMAScript.
JavaScript performs implicit type conversion in many expressions. Equality using == can convert operands before comparison, whereas equality using === compares operands without most coercions. Numeric conversion also affects arithmetic and property access, making the specification's abstract conversion operations central to the observable behavior of programs.
Functions, scope, and objects
Functions can be stored in properties, passed as arguments, and returned from other functions. Every function invocation creates an execution context containing its lexical environment and other invocation-specific state. Closures retain access to lexical bindings even after the invocation that created those bindings has completed.
Earlier JavaScript programs commonly declared variables with var, whose binding behavior is associated with function or global scope. ECMAScript 2015 added let and const, which create block-scoped bindings and remain inaccessible during the initial portion of their enclosing scope. These declarations changed the language's facilities for expressing local state without replacing the semantics of existing programs.
Inheritance is based on links between objects rather than on classes as the fundamental storage mechanism. When an object lacks an requested property of its own, property lookup continues through its prototype chain. The class syntax introduced in ECMAScript 2015 provides a declarative notation for constructors and prototype methods, while preserving the underlying prototype-based model.
Execution and asynchronous behavior
The ECMAScript specification defines the language but does not independently define a complete application environment. Browsers supplement it with interfaces specified by standards including the HTML Standard and the Document Object Model. Server runtimes provide different host facilities, although they retain the core execution semantics defined by ECMAScript.
JavaScript execution is conventionally organized around an event loop. A host schedules tasks associated with occurrences such as input or completed network operations, and JavaScript processes the resulting callbacks when the execution stack becomes available. Promise reactions are handled through a microtask mechanism whose scheduling relationship to ordinary tasks is defined by the host environment.
Promises entered the ECMAScript standard in 2015 as objects representing the eventual outcome of asynchronous operations. Later editions added async functions and the await expression, which express promise-based control flow through syntax resembling sequential execution. These constructs do not make ordinary JavaScript execution implicitly parallel; they suspend and resume the relevant asynchronous computation through specified promise operations.
Implementations
Modern JavaScript engines generally combine interpretation with just-in-time compilation. Source text is parsed into an internal representation, after which frequently executed code can be translated into optimized machine instructions. Because JavaScript permits objects to change shape and values to change type during execution, engines rely on runtime observations and may discard optimized code when its assumptions no longer hold.
Prominent engines include V8, developed for Google Chrome, and SpiderMonkey, maintained for Firefox. JavaScriptCore is used by Safari, while Chakra formerly served as the principal engine of Microsoft Edge before that browser adopted the Chromium platform. Engine implementations differ internally but are evaluated against the observable requirements of ECMAScript and relevant web-platform specifications.
Node.js, released in 2009, embedded V8 in a server-oriented runtime with an event-driven input and output model. It extended JavaScript's use beyond browser documents and contributed to the growth of a package ecosystem centered on npm. Other non-browser environments use ECMAScript for automation, application extension, and embedded control while exposing host interfaces specific to their domains.
Relationship to the web platform
JavaScript's browser role depends on interfaces that are not part of ECMAScript itself. The Document Object Model represents an HTML or XML document as nodes with methods and properties. Browser APIs separately define facilities for network communication, storage, graphics, media processing, and interaction with the browser's navigation system.
This division explains why an ECMAScript feature can be available in a runtime that lacks a browser facility, and why two environments implementing the same language edition can expose different application interfaces. Standardization of the web platform occurs primarily through the WHATWG and the World Wide Web Consortium, while Ecma International standardizes the core language.
Browser security places scripts within an origin-based access model. The same-origin policy restricts direct interaction between documents or resources belonging to unrelated origins, subject to explicitly defined exceptions. Other mechanisms govern cross-origin requests and the confinement of embedded documents. These controls belong principally to browser and web-platform specifications rather than to ECMAScript.
Modules and program organization
Historically, browser scripts shared a global environment and relied on ordering conventions established by HTML elements. Independent module systems later appeared in server runtimes and development tools. CommonJS became associated with Node.js, while Asynchronous Module Definition addressed browser-oriented loading patterns.
ECMAScript 2015 standardized a static module system based on declared imports and exports. Module bindings are resolved before execution and remain connected to their exporting modules rather than being copied as ordinary values. Modules also receive distinct scoping and strictness semantics, reducing dependence on the global object.
Browsers subsequently implemented native module loading through the HTML script element's module mode. Node.js supports ECMAScript modules alongside its earlier CommonJS system, with rules governing how the two formats interact. Build tools can transform module graphs for deployment, although such transformations remain outside the language standard.
Development ecosystem
JavaScript's ecosystem includes source transformation, static analysis, package distribution, and testing infrastructure. TypeScript, developed by Microsoft, extends JavaScript syntax with a static type system and compiles to ordinary JavaScript. Its type annotations generally do not persist as runtime checks, and its compatibility with JavaScript permits existing code to be incorporated incrementally.
Transpilers convert newer or extended syntax into forms executable by older engines. Such conversion can reproduce many syntactic features, but it cannot always supply host capabilities or exact semantics that depend on runtime support. Polyfills instead define missing library operations when the older environment provides enough underlying behavior to implement them.
The package ecosystem permits applications to depend on extensive graphs of third-party modules. Package metadata records version constraints and entry points, while lock files preserve a particular dependency resolution. These mechanisms are properties of package managers and development workflows rather than features of ECMAScript itself.
Terminology
The term “JavaScript” commonly refers both to the ECMAScript language and to its implementation within a web environment. In formal contexts, ECMAScript denotes the standardized core language, while JavaScript identifies implementations and the broader programming ecosystem associated with them. The trademark “JavaScript” is owned by Oracle Corporation as a consequence of its acquisition of Sun Microsystems, although Ecma International continues to publish the language specification under the ECMAScript name.
JavaScript is unrelated to JavaScript style sheets, an experimental Netscape technology for presenting web documents. It is also distinct from Java applets, which executed compiled Java bytecode through a browser plug-in architecture that has since been removed from mainstream browsers.