List of ECMAScript engines

An ECMAScript engine is a program that executes source code written in a version of the ECMAScript language standard, for example, JavaScript.

Just-in-time compilation engines
These are new generation ECMAScript engines for web browsers, all implementing just-in-time compilation (JIT) or variations of that idea. The performance benefits for just-in-time compilation make it much more suitable for web applications written in JavaScript.


 * Carakan: A JavaScript engine developed by Opera Software ASA, included in the 10.50 release of the Opera web browser, until switching to V8 with Opera 15 (released in 2013).
 * Chakra (JScript9): A JScript engine used in Internet Explorer. It was first previewed at MIX 10 as part of the Internet Explorer 9 Platform Preview.
 * Chakra: A JavaScript engine previously used in older versions of Microsoft Edge, before being replaced by V8.
 * SpiderMonkey: A JavaScript engine in Mozilla Gecko applications, including Firefox. The engine currently includes the IonMonkey compiler and OdinMonkey optimization module, has previously included the TraceMonkey compiler (first JavaScript JIT) and JägerMonkey.
 * JavaScriptCore: A JavaScript interpreter and JIT originally derived from KJS. It is used in the WebKit project and applications such as Safari. Also known as Nitro, SquirrelFish, and SquirrelFish Extreme.
 * JScript .NET: A .NET Framework JScript engine 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.
 * Tamarin: An ActionScript and ECMAScript engine used in Adobe Flash.
 * V8: A JavaScript engine used in Google Chrome and other Chromium-based browsers, Node.js, Deno, and V8.NET.
 * GNU Guile features an ECMAScript interpreter as of version 1.9
 * Nashorn: A JavaScript engine used in Oracle Java Development Kit (JDK) since version 8.
 * iv, ECMAScript Lexer / Parser / Interpreter / VM / method JIT written in C++.
 * CL-JavaScript: Can compile JavaScript to machine language on Common Lisp implementations that compile to machine language.
 * BESEN: A complete JIT-compiling implementation of ECMAScript Fifth Edition written in Object Pascal.
 * Hermes: developed by Facebook for React Native mobile apps Can also be used independent from React Native.
 * Graal.js: An ECMAScript compliant JavaScript engine for GraalVM which supports language interoperability that can also execute Node.js applications.

Runtime interpreter engines
The following engines use runtime interpreters, which do not compile into native machine code and generally run more slowly:


 * Continuum: A self-interpreter that supports older drafts of the ECMAScript 2015 specification. Uniquely, the engine is implemented in ECMAScript 3, which made it possible to run ES2015 in browsers as old as IE6.
 * Futhark: The ECMAScript engine of the Opera web browser versions 9.50 to 10.10.
 * InScript: An obsolete proprietary library used for iCab 2 and 3.
 * JScript: The engine that is used in Internet Explorer for versions up to IE9, and one component of the MSHTML (Trident) browser engine.
 * Jint: Javascript interpreter with integrated engine for .NET
 * KJS: The engine used in Konqueror, and one component of KHTML, a predecessor to JavaScriptCore.
 * Linear B: The ECMAScript engine of the Opera web browser versions 7.0 to 9.50, exclusive.
 * Narcissus: JavaScript implemented in JavaScript (a meta-circular evaluator), intended to run in another JavaScript engine, of theoretical and educational nature only.
 * JS-Interpreter A lightweight JavaScript interpreter implemented in JavaScript with step-by-step execution.
 * QtScript: Originally developed by Trolltech, now owned by The Qt Company. It provides QObject integration with JavaScriptCore.
 * V4 (QJSEngine): Qt's newer ECMAScript engine, powering QML and QtQuick. ES6-compliant and under active development at The Qt Company. V4 is JIT compiled.
 * Rhino: One of several JavaScript engines from Mozilla, using the Java platform.
 * YAJI: 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).
 * Microvium: JavaScript engine for microcontrollers, supporting a restricted subset of the ECMAScript specification, using less than 16kB of flash memory and 64B of RAM while idle.
 * Duktape: A small footprint, easily embeddable Ecmascript E5/E5.1 engine.
 * XS JavaScript Engine: An ECMAScript 2020-compliant engine for microcontrollers with limited resources. XS is maintained by Moddable as part of the Moddable SDK and was formerly part of the Kinoma Platform.
 * Jsish: An ES5.1 subset interpreter with builtin SQLite, JSON, WebSocket, and ZVFS support.
 * Espruino: 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: A lightweight ECMAScript interpreter library, designed for embedding in other software to extend them with scripting capabilities. Originally developed for MuPDF.
 * mJS: Restricted JavaScript engine. Used for Internet of Things (IoT).
 * Tiny-JS: A minimal JavaScript interpreter written in C++.
 * JerryScript: A lightweight JavaScript engine by Samsung for microcontrollers with less than 64 KB RAM.
 * njs: A lightweight JavaScript interpreter optimized for web server scripting and fastest VM context creation; used in nginx.
 * QuickJS: A lightweight ECMAScript 6 interpreter by Fabrice Bellard and Charlie Gordon.
 * engine262: A JavaScript engine written in JavaScript for development and exploration. It is primarily used to validate the ECMAScript specification.
 * Boa: A JavaScript engine written in Rust.
 * ScriptEase: an old proprietary engine last updated in 2003. Only notable for its use in the James Webb Space Telescope.
 * LibJS: JavaScript engine of the SerenityOS and Ladybird project. Initially it was an AST interpreter, but has been upgraded to a bytecode-based one. At some point, the developer Andreas Kling was working on porting it to Just-in-time compilation, but he later changed his mind, citing development/debugging issues while also saying that he is interested to see how far utility and usability of the engine can go without it.