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, first released in Firefox 3.1. [12] Opera joined the performance race with their register-bytecode based and JIT-enabled Carakan engine, first announced in February 2009, [13] 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 v2 | 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 directly-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 but effective form of JIT. [31] Today, JavaScriptCore has a multi-tier pipeline consisting of LLint bytecode interpreter, template-based Baseline JIT and two tiers of optimizing JIT compilers: DFG and FTL engines. [18] |
KJS | LGPL v2 | 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. [32] 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. [33] |
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. [34] |
ChakraCore | MIT | ES6 (partial) | Yes | Yes | C++ | JavaScript engine of Microsoft Edge Legacy. [35] 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 B | Proprietary | ES3 | No | No | C++ | JavaScript engine of Opera from 7.0 until 9.50 (2003-2007). |
Futhark | Proprietary | ES3 | No | No | C++ | JavaScript engine of Opera from 9.50 until 10.50 (2007-2010). |
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] [36] [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. [37] Initially a basic AST tree-walking interpreter, later upgraded to a register-based bytecode VM interpreter. [38] [39] |
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. [40] Bundled in JDK 6 (2006) as javax.script. In JDK 8 (2014) it was replaced by the faster Nashorn engine. [41] Despite this, the project continues development and implemented support for parts of newer standards. Used in RingoJS runtime. |
Nashorn | GPL v2 | ES6 (partial) | via JVM | No | Java | JavaScript engine from Oracle used in JDK 8-14. [42] Generates more efficient JVM bytecode than Rhino, taking advantage of the new invokedynamic instruction introduced in JDK 7. [43] Deprecated in JDK 11 (2018) due to maintenance challenges owing to fast evolution of ECMAScript standard, [28] and removed in JDK 15 (2020). [44] Development continues till today as a standalone library. [45] |
Graal.js | UPL-1.0 | ESnext | via GraalVM | No | Java | An ECMAScript compliant JavaScript engine for GraalVM and JVM which supports language interoperability that can also execute Node.js applications. Generally much faster than both Rhino and Nashorn, with performance comparable to major engines like V8. [46] |
Hermes | MIT | ES6+ (partial) | No | No | C++ | Developed by Facebook for React Native mobile apps [47] , but can also be used independent from React Native. Precompiles JavaScript to optimized bytecode ahead-of-time to improve app start-up time. |
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. Initially appeared in Qt 5.0 (2012) as a wrapper for V8, [48] later replaced by Qt's lightweight home-grown "V4" engine in Qt 5.2 (2013) [49] ES7/ES2016-compliant [50] and JIT-enabled, using macroassembler code borrowed from JavaScriptCore. [51] [52] Only used for QML, not for the embedded browser engine modules: QtWebKit module used JavaScriptCore, later succeeded by Blink/V8-based QtWebEngine. |
Microvium | MIT | ES6 (partial) | No | No | C | JavaScript engine for microcontrollers, supporting a restricted subset of the ECMAScript specification, using less than 16 kB of flash memory and 64 B of RAM while idle. [53] |
Duktape | MIT | ES6 (partial) | No | No | C | A small footprint, easily embeddable ES5/5.1 engine with some features from ES6 and later. [54] |
XS | LGPL, Apache-2.0 | ESnext | No | No | C | An ECMAScript 2024+ compliant engine for microcontrollers with limited resources. [55] [56] XS is maintained by Moddable as part of the Moddable SDK and was formerly part of the Kinoma Platform. [57] |
Espruino | MPL-2.0 | ES5 (subset) | No | No | C | A very small footprint interpreter specifically for microcontrollers. Can run in less than 8 kB of RAM by executing from source (rather than bytecode). |
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. [58] |
mJS | GPL-2.0 | ES6 (subset) | No | No | C | Restricted JavaScript engine. Used for Internet of Things (IoT). |
JerryScript | Apache-2.0 | ES2022 (mostly) | No | No | C | Ultra-lightweight JavaScript engine by Samsung for microcontrollers with less than 64 KB RAM. 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. [59] Implements a register-based bytecode interpreter. |
njs | BSD-2-Clause | ES6 (partial) | No | No | C | A lightweight JavaScript interpreter optimized for web server scripting and fastest VM context creation; used in nginx. [60] |
QuickJS | MIT | ES2023 | No | No | C | A lightweight ECMAScript engine by Fabrice Bellard and Charlie Gordon, currently featuring almost complete support of ES2023. 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). |
QuickJS-NG | MIT | ES2023 | No | No | C | A fork of QuickJS focused on community development, cross-platform support and latest available ECMAScript features. |
EchoJS | MIT | ES6 | No | No | C++ | LLVM-based ahead-of-time compiler and runtime for ES6. |
Jint | BSD-2-Clause | ES6+ (partial) | No | No | C# | JavaScript interpreter with integrated engine for .NET. |
NiL.JS | BSD-3-Clause | ES6 | No | No | C# | ES6 engine for .NET written in C#, implementing a tree-walking interpreter. |
Topaz | MIT | ES6 | No | No | C# | Multithreaded JavaScript engine for .NET, implementing a tree-walking interpreter. |
YantraJS | Apache-2.0 | ES6 | No | No | C# | JavaScript engine for .NET. |
Jurassic | BSD-2-Clause | ES6+ (partial) | via CLR | No | C# | ECMAScript engine and runtime intended to be integrated in .NET programs as a library. Implements ES5 and parts of newer standards. Compiles JavaScript to .NET bytecode to be run on CLR. |
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.1 and parts of newer standards. |
JS-Interpreter | Apache-2.0 | ES5 | No | No | JavaScript | A lightweight JavaScript interpreter implemented in JavaScript with step-by-step execution. |
engine262 | MIT | ESnext | No | No | JavaScript | A JavaScript engine written in JavaScript for development and exploration. It is primarily used to validate the ECMAScript specification. |
Narcissus | MPL-2.0 | ES5 | No | No | JavaScript | JavaScript implemented in JavaScript (a meta-circular evaluator), intended to run in another JavaScript engine, of theoretical and educational nature only. Originally a proof-of-concept by Brendan Eich, was used a test-bed for rapidly prototyping new language features between ES5-ES6, not maintained since 2012. |
Porffor | MIT | ES6+ (partial) | via WASM | No | JavaScript | JavaScript/TypeScript ahead-of-time compiler that targets WebAssembly instead of bespoke VM bytecode. |
jawsm | Apache-2.0 | via WASM | No | Rust | JavaScript to WebAssembly compiler written in Rust. | |
Boa | MIT | ESnext | No | No | Rust | A JavaScript engine written in Rust. [61] [62] |
Nova | MIT | ES6+ (partial) | No | Yes | Rust | A JavaScript/WebAssembly engine written in Rust, experimenting with a novel cache-friendly data-oriented design for core language data structures. |
Starlight | MPL-2.0 | No | No | Rust | Unfinished engine in Rust featuring a bytecode interpreter and polymorphic inline caches. | |
Kiesel | MIT | ES6+ (partial) | No | No | Zig | JavaScript engine by Linus Groh written in Zig. [63] [64] [65] |
Reeva | BSD-2-Clause | No | No | Kotlin | JavaScript engine for JVM written in Kotlin. | |
Higgs | BSD-3-Clause | Yes | No | D | JIT compiler for x86-64 written in D. | |
Bali | BSD-3-Clause | Yes | No | Nim | JIT-enabled JavaScript engine written in Nim. | |
Elk | AGPL | ES6 (subset) | No | No | C | Tiny embeddable JavaScript engine for a subset of ES6. |
GNU Guile | GPL | ES3 (partial) | No | No | C | Features an unfinished ECMAScript interpreter as of version 1.9. [66] |
Tamarin | MPL-2.0 | ES3 | Yes | No | C++ | An ActionScript and ECMAScript engine used in Adobe Flash. |
iv / lv5 | BSD-2-Clause | ES5 | Yes | No | C++ | ECMAScript 5.1 engine written in C++ with a register-based bytecode VM and context threading JIT. [67] [30] |
CL-JavaScript | MIT | ES5 (partial) | via Lisp runtime | No | Lisp | Can compile JavaScript to machine language on Common Lisp implementations that compile to machine language. [68] |
BESEN | LGPL | ES5 | Yes | No | Pascal | A complete JIT-compiling implementation of ECMAScript Fifth Edition written in Object Pascal. [69] |
Continuum | MIT | ES6 (partial) | No | No | JS | A self-interpreter that supports older drafts of the ECMAScript 2015 specification. [70] Uniquely, the engine is implemented in ECMAScript 3, which made it possible to run ES2015 in browsers as old as IE6. [71] |
YAJI | LGPL | ES5 | No | No | Java | An ECMAScript engine based on the FESI implementation by Jean-Marc Lugrin in 1999, using the Java platform, currently being developed to support the latest standards (ECMAScript spec. 262, v5.1). [72] [73] [74] |
Jsish | MIT | ES5 (partial) | No | No | C | An ES5.1 subset interpreter with builtin SQLite, JSON, WebSocket, and ZVFS support. [75] |
Tiny-JS | MIT | No | No | C++ | A minimal JavaScript interpreter written in C++. | |
ScriptEase | Proprietary | No | No | An old proprietary engine last updated in 2003. Only notable for its use in the James Webb Space Telescope. [76] | ||
InScript | Proprietary | No | No | An obsolete proprietary library used for iCab 2 and 3. |