The first engines for JavaScript were mere interpreters of the source code, but all relevant modern engines use just-in-time compilation for improved performance. [1] JavaScript engines are typically developed by web browser vendors, and every major browser has one. In a browser, the JavaScript engine runs in concert with the rendering engine via the Document Object Model and Web IDL bindings. [2] However, the use of JavaScript engines is not limited to browsers; for example, the V8 engine is a core component of the Node.js runtime system. [3] They are also called ECMAScript engines, after the official name of the specification. With the advent of WebAssembly, some engines can also execute this code in the same sandbox as regular JavaScript code. [4] [3]
The first JavaScript engine was created by Brendan Eich in 1995 for the Netscape Navigator web browser. [5] It was a rudimentary interpreter for the nascent language Eich invented. [6] (This evolved into the SpiderMonkey engine, still used by the Firefox browser. [5] )
Google debuted its Chrome browser in 2008, introducing the V8 JavaScript engine that was at the time much faster than its competition. [7] [8] This sparked a race between browser vendors to deliver ever-faster JavaScript engines. [9] The key innovations around this era were switching from basic tree-walking interpreters to stack- and register-based bytecode VM interpreters, just-in-time compilation (JIT), inline caching (hidden classes) and generational GC. Apple released the JIT-enabled Nitro engine in June 2008 for its Safari browser, which had 30% better performance than its predecessor. [10] [11] Mozilla followed the suit in August 2008 with TraceMonkey, the first JIT compiler for SpiderMonkey engine, released in Firefox 3.1. [12] Opera joined the performance race with their register-bytecode based and JIT-enabled Carakan engine, announced in February 2009 [13] and released in April 2010. [14] Microsoft's first JIT-enabled Chakra engine, in development since 2008, [15] debuted as part of Internet Explorer 9 in 2011. Its major rewrite appeared in Microsoft Edge Legacy in 2015 and open-sourced as ChakraCore in 2016.
Further performance gains in major JavaScript engines were later achieved with the introduction of multi-tiered JIT architectures. Progressively advanced JIT compilers are used to optimize hotspots in user code, with each next tier delivering ever more performant native code at the cost of slower compile time. Chrome was the first to implement it in V8 in 2010 with the introduction of Crankshaft, a 2-tiered JIT compiler. [16] By 2023, architecture of V8 evolved into 4 tiers: Ignition – register-based bytecode interpreter, Sparkplug – a fast non-optimizing JIT compiler, Maglev and TurboFan – slower optimizing JIT compilers. [17] JavaScriptCore today has a similar 4-tier architecture, [18] while Firefox's SpiderMonkey and ChakraCore have 3 tiers (interpreter and 2-tiered JIT). [19] [20] This ever-increasing complexity of JIT compilers, however, has been criticized as a rich source of browser bugs, prompting some browser vendors to disable JIT altogether, such as Microsoft Edge's "Super Duper Secure Mode", introduced in 2021 and reportedly with minor performance impact for daily browsing. [21]
V8's influence expanded beyond browsers with the release of Node.js in 2009 and its package manager npm in 2010. As their popularity exploded, V8 also became the engine powering vast amounts of server-side JavaScript code. [22] [23] In 2013, Electron framework appeared that let developers create desktop apps with web technologies as well, using Chromium with V8 and Node.js under the hood. [24]
Taking advantage of performance improvements in JavaScript engines, Emscripten C/C++-to-JavaScript compiler appeared in 2010-2011 and allowed running existing complex C/C++ code, such as game engines and even whole virtual machines, directly in the browser. asm.js, a highly optimizable low-level subset of JavaScript for such compilers emerged in 2013, with Firefox being the first to implement specific optimizations for it with OdinMonkey module. [25] Eventually asm.js and NaCl (a competing Google's technology) evolved into WebAssembly standard in 2017, with all major engines adding support for it. [4]
The six-year gap between ECMAScript 5 (2009) and ES6 (2015) marked a major inflection point for JavaScript engine development. Whereas ES5 was a relatively compact language with straightforward basic implementation, ES6 introduced foundations of modern JavaScript, with substantially increased complexity, as well as an annual release cycle for new specification versions. This put the focus not only on performance optimization, but also on keeping pace with the rapidly evolving standards (of both ECMAScript and wider web ecosystem) and led to a consolidation around engines that had the resources to do it. Many smaller projects did not end up fully implementing ES6 spec, and Opera and Microsoft both ceased developing their engines and adopted V8 in 2013 and 2021. [26] [27] Nashorn engine was dropped from OpenJDK over a similar concern about ECMAScript's rapid development. [28]
Engine | License | Standard | JIT | WASM | Written in | Description |
---|---|---|---|---|---|---|
V8 | BSD-3-Clause | ESnext | Yes | Yes | C++ | JavaScript engine of Google Chrome and Chromium/Blink-based browsers, such as Microsoft Edge. Also used in Node.js and Deno runtimes, Electron framework and numerous other projects. Currently has a register-based bytecode interpreter (Ignition) and three tiers of JIT compilers (Sparkplug, Maglev and Turbofan). |
SpiderMonkey | MPL-2.0 | ESnext | Yes | Yes | C++ | JavaScript engine of Firefox and other Mozilla Gecko applications. The engine currently includes interpreter, 2-tier JIT for JavaScript (Baseline Compiler and WarpMonkey), and a separate 2-tier JIT for WebAssembly (WASM-Baseline or RabaldrMonkey, and WASM-Ion or BaldrMonkey). [19] Previously, the engine included components such as the TraceMonkey compiler (first JavaScript JIT), JägerMonkey, IonMonkey, as well as OdinMonkey optimization module notable for pioneering asm.js. [25] |
JavaScriptCore | LGPL-2.0, parts under BSD | ESnext | Yes | Yes | C++ | JavaScript engine of Safari and WebKit-based browsers. Also used in Bun runtime. Started out in 2001 as a fork of KJS engine. In 2008 the engine was rewritten to use a direct-threaded register-based bytecode interpreter, codenamed SquirrelFish. Shortly after, SquirrelFish Extreme (Nitro in Apple's marketing terms) [29] was released, achieving over 2x speedup over it by using polymorphic inline caching and context threading [30] – a basic form of JIT. [31] These components later became LLint bytecode interpreter and Baseline JIT. [32] In 2011, the first optimizing compiler was added – DFG ("Data Flow Graph") JIT. [32] [33] In 2014, an advanced LLVM-based compiler was added, dubbed Fourth Tier LLVM (FTL) JIT. [34] In 2016, FTL was rewritten to use a newly built B3 backend instead of LLVM. [35] [18] |
Mocha | Proprietary | JS1.1 | No | No | C++ | The first JavaScript engine. Prototyped by Brendan Eich in a 10-day sprint in May 1995 and shipped in September 1995 in Netscape Navigator 2.0b1. [36] Due to feature freeze in August 1995, it was incomplete relative to the envisioned language design. Version 1.1 was released with Navigator 3.0 in 1996, completing the initial development of the language and served as the basis for the first edition of ECMAScript standard in 1997. The engine had a recursive descent parser that directly emitted bytecode, a stack-based virtual machine, used reference counting instead of GC and represented primitives as discriminated unions rather than tagged pointers. Source code as part of Navigator 3.0.2 is available from Internet Archive. [37] For Navigator 4.0, the engine was completely rewritten and renamed SpiderMonkey. [38] |
KJS | LGPL-2.0+ | ES5 | No | No | C++ | The engine originally used in Konqueror, and one component of KHTML. Predecessor to JavaScriptCore, which forked it in 2001 and significantly diverged since. Originally an AST-tree-walking interpreter, upgraded to a bytecode interpreter (FrostByte) in 2008. [39] Development largely stopped as Konqueror transitioned from KHTML first to QtWebKit (JavaScriptCore) and then QtWebEngine (V8). KDE Plasma 6 finally removed KJS/KHTML engine altogether. [40] |
JScript | Proprietary | ES3 | No | No | The engine that is used in Internet Explorer for versions up to IE9, and one component of the MSHTML (Trident) browser engine. | |
JScript .NET | Proprietary | ES3 | via CLR | No | A .NET Framework JScript engine developed by Microsoft and used in ASP.NET based on Common Language Runtime and COM Interop. Support was dropped with .NET Core and CoreCLR so its future looks questionable for ASP.NET Core. | |
Chakra (JScript9) | Proprietary | ES5 | Yes | No | C++ | A JScript engine used in Internet Explorer. It was first previewed at MIX 10 as part of the Internet Explorer 9 Platform Preview. [41] |
ChakraCore | MIT | ES6 (partial) | Yes | Yes | C++ | JavaScript engine of Microsoft Edge Legacy. [42] Open-sourced under the name ChakraCore in 2016. Microsoft discontinued maintenance in 2021, leaving it to the community, but it has received little attention since then. It features a register-based bytecode interpreter and a two-tier JIT compiler. [20] |
Linear A, Linear B, Futhark | Proprietary | ES3 | No | No | C++ | A series of early JavaScript engines of Opera browser. Unnamed engine in Opera 3 (1997–2000). Linear A in Opera 4-6 (2000–2002). Linear B in Opera 7-9.27 (2002–2007) – implemented complete ECMAScript support. Futhark in Opera 9.50-10.20 (2007–2010). [43] |
Carakan | Proprietary | ES5 | Yes | No | C++ | JavaScript engine of Opera from 10.50 release in 2010 until the switch to V8 with Opera 15 in 2013. [13] [44] [26] It featured register-based bytecode and JIT. [13] |
LibJS | BSD-2-Clause | ESnext | No | Yes (LibWASM) | C++ | JavaScript engine of the SerenityOS and Ladybird browser. [45] Initially a basic AST tree-walking interpreter, later upgraded to a register-based bytecode VM interpreter. [46] [47] [48] [49] |
Rhino | MPL-2.0 | ES6 (partial) | via JVM | No | Java | JavaScript engine from Mozilla for the Java platform. Development started at Netscape in 1997. Originally it compiled JavaScript to JVM bytecode, but the implementation was inefficient and it was mainly used in interpreter mode. [50] Bundled in JDK 6 (2006) as javax.script. In JDK 8 (2014) it was replaced by the faster Nashorn engine. [51] Despite this, the project continues development and implemented support for parts of newer standards. Used in RingoJS runtime. |
Nashorn | GPL-2.0 | ES6 (partial) | via JVM | No | Java | JavaScript engine from Oracle used in JDK 8–14. [52] Generates more efficient JVM bytecode than Rhino, taking advantage of the new invokedynamic instruction introduced in JDK 7. [53] Deprecated in JDK 11 (2018) due to maintenance challenges owing to fast evolution of ECMAScript standard, [28] and removed in JDK 15 (2020). [54] Development continues till today as a standalone library. [55] |
GraalJS | UPL-1.0 | ESnext | via GraalVM | No | Java | JavaScript engine of GraalVM for JVM platform. Implemented with Truffle, a novel language framework for automatically deriving high-performance code from interpreters, based on the idea of partial evaluation of interpreters (Futamura projection). [56] [57] Generally much faster than both Rhino and Nashorn, with performance comparable to major browser engines. [58] |
Hermes | MIT | ES6+ (partial) | No | No | C++ | Developed by Facebook for React Native mobile apps, [59] but can also be used independent from React Native. Precompiles JavaScript to optimized bytecode ahead-of-time to improve app start-up time. [60] [61] [49] |
Duktape | MIT | ES6 (partial) | No | No | C | A small footprint, easily embeddable ES5 engine with some features from ES6 and later. [62] [63] [64] [65] Used by NetSurf browser. |
XS | LGPL-3.0+, Apache-2.0 | ESnext | No | No | C | JavaScript engine for microcontrollers with limited resources, compliant with latest ECMAScript versions. [66] [67] [65] [49] [68] Originally developed by Kinoma and first open-sourced in 2015 as a key component of their KinomaJS IoT framework. Now maintained by Moddable as part of the Moddable SDK. [69] |
MuJS | ISC | ES5 | No | No | C | A lightweight ECMAScript interpreter library, designed for embedding in other software to extend them with scripting capabilities. Originally developed for MuPDF. [70] [63] |
QuickJS | MIT | ES2023 | No | No | C | A lightweight ECMAScript engine by Fabrice Bellard and Charlie Gordon, currently featuring almost complete support of ES2023. [71] [63] [60] [72] [49] Implements a stack-based bytecode VM interpreter and a single-pass AST-free direct-to-bytecode compiler. Can precompile .js to bytecode ahead-of-time and produce a binary executable with no external dependencies. Used in WinterJS and Amazon's LLRT runtimes, CouchDB, nginx (as alternative to njs). |
QtScript | LGPL, GPL, Qt | ES5 dialect | No | No | C++ | Originally developed by Trolltech, now owned by The Qt Company. First appeared in Qt 4.3, deprecated in Qt 5.5 in favor of QML's V4 and then dropped in Qt 6.5. Based on JavaScriptCore engine and featured a few Qt-specific ECMAScript extensions, such as QObject-style signal and slot connections. |
V4 (QJSEngine) | LGPL, GPL, Qt | ES2016 | Yes | No | C++ | Qt's newer ECMAScript engine, powering QML and Qt Quick. [73] [74] [75] Initially appeared in Qt 5.0 (2012) as a wrapper for V8, [76] later replaced by Qt's lightweight home-grown "V4" engine in Qt 5.2 (2013) [77] [78] ES7/ES2016-compliant [79] and JIT-enabled, using macroassembler code borrowed from JavaScriptCore. [80] [81] Only used for QML, not for the embedded browser engine modules: QtWebKit module used JavaScriptCore, later succeeded by Blink/V8-based QtWebEngine. |
Espruino | MPL-2.0 | ES5 (subset) | No | No | C | A very small footprint interpreter specifically for microcontrollers. [64] Can run in less than 8 kB of RAM by executing from source (rather than bytecode). |
JerryScript | Apache-2.0 | ES2022 (mostly) | No | No | C | Ultra-lightweight JavaScript engine by Samsung for microcontrollers with less than 64 KB RAM. [63] [65] Supports ES5 and large parts of recent standards up to ES2022. |
Escargot | LGPL-2.1 | ESnext | No | Yes | C++ | A newer lightweight JavaScript engine by Samsung for resource-constrained environments, targeting mid-range devices like phones and TVs. Under active development, fully supports latest ECMAScript standard except a few minor features, as well as WebAssembly. [82] [63] [83] Implements a register-based VM interpreter. |
otto | MIT | ES5 | No | No | Go | JavaScript engine in pure Go, implementing ES5 but with non-compliant regex engine from Go. |
Goja | MIT | ES6+ (partial) | No | No | Go | JavaScript engine in pure Go, inspired by otto, fully implementing ES5 and parts of newer standards. Used by Ethereum's official Go implementation (Geth). [84] |
Boa | MIT, Unlicense | ESnext | No | No | Rust | A JavaScript engine written in Rust. [85] [86] |
Kiesel | MIT | ESnext | No | No | Zig | JavaScript engine by Linus Groh written in Zig. [87] [88] [89] [90] |
engine262 | MIT | ESnext | No | No | JavaScript | A JavaScript engine written in JavaScript for development and exploration, intended essentially as a reference implementation of the language. [49] |
Epimetheus | MPL-1.1 GPL-2.0+ LGPL-2.1+ | ES3, ES4 (draft) | No | No | C++ | Netscape's experimental "JavaScript 2.0" implementation towards ES4 proposal. [38] [91] |
Tamarin | MPL-2.0 | ES3, ES4 (draft) | Yes | No | C++ | ActionScript and ECMAScript engine used in Adobe Flash Player 9. Implemented ES4 proposal. |
Narcissus | MPL-1.1+ GPL-2.0+ LGPL-2.1+ | ES5 | No | No | JavaScript | JavaScript engine implemented in JavaScript (a meta-circular evaluator) by Brendan Eich, the creator of JavaScript. Used for experimentation with new language features for ES6 efforts. [38] |
Links | GPL-2.0+ | No | No | No | C | Links browser had a basic JavaScript implementation until version 2.1pre28. Removed in 2.1pre29 for being "very buggy". [92] |
Voyager | GPL-3.0 | ES3 | No | No | C | Voyager, another web browser for Amiga in the late 1990s – early 2000s, had its own JavaScript engine. |
ScriptEase | Proprietary | ES3 [93] | No | No | C++ | An old proprietary engine last updated in 2003. Only notable for its use in the James Webb Space Telescope. [94] |