JavaScript engines zoo ## Metadata - Author: [[ivankra.github.io]] - Full Title: JavaScript engines zoo - Category: #articles - Document Note: --- tags: [javascript, engines, performance, programming-languages] author: Ivan Kravets source: Personal Blog reference: https://ivankra.github.io/javascript-zoo/ date created: 2024-12-28 16:45 --- # 🏷️ Title: JavaScript engines zoo ## 🧰 Action Inbox - [H1] Review performance comparison methodology — benchmark selection #performance - [H2] Investigate engine architecture differences — JIT vs interpreter patterns #architecture - [H3] Analyze ES2016+ feature support gaps — compatibility assessment #standards ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [JavaScript engines zoo](https://ivankra.github.io/javascript-zoo/) ## 📝 Summary - Comprehensive comparison of JavaScript engines across performance, architecture, and compatibility metrics - Covers major engines from V8 to alternative implementations with detailed benchmark data - Provides insights into JIT compilation strategies, language support, and ecosystem diversity - Reveals performance trade-offs between different engine architectures and optimization approaches - Essential reference for understanding JavaScript runtime landscape and making informed engine choices ## 📖 Main Content This comprehensive comparison examines the JavaScript engine ecosystem through multiple lenses: performance benchmarks, architectural approaches, ECMAScript compatibility, and development metrics. The analysis covers mainstream engines like V8, SpiderMonkey, and JavaScriptCore alongside alternative implementations including embedded engines and research projects. The performance evaluation uses standardized benchmarks across ARM64 (Mac M4 4.5GHz) and AMD64 (i9-10900K 3.7GHz) architectures, providing cross-platform insights. Each engine is characterized by its JIT compilation strategy, target use cases, standards compliance, and community metrics. Key architectural patterns emerge around JIT vs interpreter trade-offs, with modern engines favoring sophisticated optimization pipelines while embedded solutions prioritize memory efficiency and startup time. ECMAScript feature support varies significantly, particularly for ES2016+ specifications, creating compatibility considerations for developers. ## 🗒️ Notes #### ⏱️ [Initial Analysis](https://ivankra.github.io/javascript-zoo/) — [H1] Performance Architecture Overview - Key idea: JavaScript engines show dramatic performance variations based on JIT compilation sophistication - Evidence: Benchmark scores span multiple orders of magnitude across engine implementations #### ⏱️ [Platform Comparison](https://ivankra.github.io/javascript-zoo/) — [H2] Cross-Platform Benchmarking - Key idea: ARM64 and AMD64 architectures reveal different optimization strengths per engine - Evidence: Mac M4 4.5GHz vs i9-10900K 3.7GHz results show architecture-specific performance patterns #### ⏱️ [Engine Categories](https://ivankra.github.io/javascript-zoo/) — [H3] JIT vs Interpreter Classification - Key idea: Modern engines primarily use JIT compilation for performance optimization - Evidence: JIT-enabled engines consistently outperform interpreter-only implementations in benchmarks #### ⏱️ [Standards Support](https://ivankra.github.io/javascript-zoo/) — [H1] ECMAScript Compatibility Matrix - Key idea: ES2016+ feature support varies significantly across engine implementations - Evidence: Feature compatibility ranges from complete ES1-5 support to partial ES2016+ adoption #### ⏱️ [Development Metrics](https://ivankra.github.io/javascript-zoo/) — [H2] Community and Maintenance - Key idea: Engine development correlates with organizational backing and community size - Evidence: Star counts, contributor numbers, and organizational affiliation indicate project sustainability #### ⏱️ [Binary Characteristics](https://ivankra.github.io/javascript-zoo/) — [H3] Implementation Size Analysis - Key idea: Engine binary sizes reflect architectural complexity and target deployment scenarios - Evidence: Lines of code and binary footprints vary dramatically based on optimization and feature scope #### ⏱️ [Target Applications](https://ivankra.github.io/javascript-zoo/) — [H2] Use Case Optimization - Key idea: Different engines optimize for distinct deployment scenarios and performance requirements - Evidence: Browser engines prioritize different metrics than embedded or server-side implementations #### ⏱️ [Language Implementation](https://ivankra.github.io/javascript-zoo/) — [H3] Implementation Language Impact - Key idea: Engine implementation language affects performance characteristics and development velocity - Evidence: C++ dominance with some Rust and other language experiments showing different trade-offs ## 📚 References - [JavaScript engines zoo](https://ivankra.github.io/javascript-zoo/) - [ECMAScript Specification](https://tc39.es/ecma262/) - [V8 JavaScript Engine](https://v8.dev/) ## 🗣️ Paraphrase - JavaScript engines exhibit vastly different performance profiles based on their architectural decisions around JIT compilation, optimization strategies, and target deployment scenarios - Cross-platform benchmarking reveals architecture-specific strengths, with ARM64 and AMD64 systems showing different optimization patterns across engine implementations - ECMAScript standards support creates a fragmented compatibility landscape, particularly for modern ES2016+ features, requiring careful consideration for cross-engine compatibility ## 📰 Newsletter The JavaScript engine landscape offers fascinating insights into runtime optimization and standards implementation. This comprehensive comparison reveals how architectural choices around JIT compilation create dramatic performance differences across engines. For developers, understanding these trade-offs helps inform deployment decisions - whether prioritizing raw performance, compatibility, or resource efficiency. The benchmark data across ARM64 and AMD64 architectures provides practical guidance for platform-specific optimization. Key considerations include ECMAScript feature support variations, particularly for ES2016+ specifications, and the correlation between organizational backing and long-term engine sustainability. Resources: [ECMAScript Spec](https://tc39.es/ecma262/), [V8 Docs](https://v8.dev/docs), [MDN JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript) ## ✅ Action Items #### DevRel - Developer advocacy: Present engine comparison at JavaScript conferences, create decision framework demos - Education: Workshop on engine selection criteria, office hours on performance optimization - Developer experience: Documentation comparing engine APIs, migration guides between engines - Developer marketing: Performance comparison campaigns, engine architecture deep-dive content - Community management: Engine maintainer relationships, feedback collection on compatibility gaps #### OSPO - Policy & Governance: Engine selection criteria, vendor neutrality guidelines - License Compliance: JavaScript engine license compatibility review across implementations - Security Management: Engine vulnerability disclosure coordination, security advisory integration - Software Inventory: Engine dependency tracking, upgrade path documentation - Developer Support: Engine-specific tooling guidance, performance profiling training - Community Engagement: Upstream engine project funding evaluation, technical advisory participation - Strategic Alignment: Engine performance KPIs, compatibility testing OKRs #### Community - Maintainers: Cross-engine compatibility testing templates, performance regression detection - Contributors: Engine contribution pathway documentation, optimization technique sharing - Sponsors: Engine project funding transparency, benchmark infrastructure support - Ecosystem: JavaScript tooling compatibility matrices, engine-specific optimization guides ## 🧪 Hypotheses - JIT compilation sophistication directly correlates with JavaScript execution performance across benchmark suites - ARM64 and AMD64 architectural differences create predictable optimization pattern variations across JavaScript engines - ECMAScript ES2016+ feature adoption rates reflect organizational resource allocation and target market priorities - Engine binary size and lines of code serve as reliable predictors of memory footprint and startup performance ### 📊 Methodology - Cross-platform benchmark suite execution on standardized hardware configurations to test performance correlations - Feature support matrix analysis comparing ECMAScript specification compliance across engine versions and organizations - Statistical correlation analysis between development metrics (stars, contributors, organizational backing) and engine sustainability indicators ### ❓ Questions - How do emerging WebAssembly integration patterns affect JavaScript engine architecture decisions and performance trade-offs? - What factors determine optimal engine selection for specific deployment scenarios beyond raw performance benchmarks? - How will future ECMAScript specification evolution impact engine compatibility fragmentation and development resource allocation? ### 🔮 Future Research - WebAssembly-JavaScript interop performance analysis across engine implementations - Real-world application performance correlation with synthetic benchmark results - Engine security vulnerability pattern analysis and architectural risk assessment ### 💡 Implications - Practice: Engine selection requires balancing performance, compatibility, and long-term support considerations - Policy: JavaScript standards compliance testing needs systematic cross-engine validation - Security: Engine diversity provides ecosystem resilience but complicates vulnerability management - Education: Developer training should cover engine-specific optimization techniques and compatibility patterns - Funding: Open source engine sustainability requires coordinated organizational support and resource allocation ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (technical content with specialized terminology) #### 👀 Visual learners - Present: Performance comparison tables, architecture diagrams, benchmark score visualizations - Improve: Engine architecture flowcharts, performance trend graphs, compatibility matrix heatmaps #### 🔊 Aural learners - Present: Limited audio content available - Improve: Engine comparison podcast, performance analysis narration, expert interview series #### 🗣️ Verbal learners - Present: Technical terminology definitions, architectural explanations, comparative analysis - Improve: Engine analogies to physical systems, step-by-step optimization explanations #### 🧩 Kinesthetic learners - Present: Interactive benchmark tool, engine comparison interface - Improve: Hands-on engine switching exercises, performance tuning labs, compatibility testing workflows #### 🧠 Logical learners - Present: Systematic performance comparisons, feature support matrices, development metrics - Improve: Decision trees for engine selection, causal performance analysis, optimization decision frameworks #### 🧑‍🤝‍🧑 Social learners - Present: Community metrics, contributor statistics, organizational backing information - Improve: Engine maintainer interviews, community discussion prompts, collaborative benchmarking projects #### 🧘‍♀️ Solitary learners - Present: Comprehensive comparison data, self-guided analysis tools - Improve: Personal engine evaluation worksheets, reflection prompts on optimization trade-offs #### 🌿 Naturalistic learners - Present: Ecosystem diversity concepts, engine evolution patterns - Improve: Engine lifecycle analogies, performance ecosystem thinking, sustainability impact analysis ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Table headers for comparison data, clear section structure - Improve: Enhanced alt text for performance charts, ARIA labels for interactive elements #### Keyboard navigation - Present: Standard web navigation, table accessibility - Improve: Skip links for large comparison tables, keyboard shortcuts for filtering options #### Contrast and readability - Present: Standard text contrast ratios - Improve: High contrast mode for performance charts, larger text options for technical details #### Text resizing and reflow - Present: Responsive table design - Improve: Improved table reflow at high zoom levels, collapsible detail sections #### Media and captions - Present: Static comparison content - Improve: Video explanations with captions, audio descriptions for performance visualizations #### Forms and interactions - Present: Basic filtering interactions - Improve: Clear form labels for engine filtering, accessible error messages for invalid comparisons #### Standards reference - Ensure WCAG 2.2 AA compliance for interactive comparison tools and data visualization elements ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global engine development organizations represented - Improve: International performance testing environments, multi-region deployment considerations #### Inclusive language - Present: Technical terminology with explanations - Improve: Plain language summaries, avoid performance hierarchy language that implies superiority #### Neurodiversity support - Present: Structured comparison format, consistent data presentation - Improve: Cognitive load reduction through progressive disclosure, clear information hierarchy #### Representation - Present: Diverse organizational backgrounds in engine development - Improve: Highlight diverse contributor communities, inclusive project governance examples #### Psychological safety - Present: Neutral technical comparison approach - Improve: Avoid engine tribalism, emphasize use-case appropriateness over absolute rankings ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Performance benchmarks logically support architectural conclusions about JIT optimization effectiveness - Inductive strength: Cross-platform testing patterns provide reasonable basis for generalizing engine performance characteristics - Causal reasoning: JIT compilation sophistication plausibly explains performance variations across engine implementations - Analogical strength: Engine ecosystem diversity parallels other software infrastructure maturity patterns #### Fallacies - Hasty generalization: Benchmark performance may not represent real-world application behavior - needs broader application testing validation - False dichotomy: JIT vs interpreter framing oversimplifies hybrid optimization strategies - acknowledge spectrum of approaches #### Tone of voice - Overall tone: Analytical and neutral with appropriate technical precision, maintains objectivity in engine comparisons ### 🛡️ DARVO Analysis - Deny: No significant denial patterns identified in technical comparison content - Attack: No attacks on specific engines or organizations, maintains neutral comparative stance - Reverse victim/offender: No victim/offender dynamics present in technical analysis - Emotional cues and rhetoric: Appropriately technical and objective tone without emotional manipulation ## 🎯 Conclusion The JavaScript engine ecosystem demonstrates remarkable diversity in architectural approaches, performance characteristics, and standards compliance. This comprehensive comparison reveals that engine selection requires careful consideration of performance benchmarks, compatibility requirements, and long-term sustainability factors. For practitioners, the key insight is that no single engine optimizes for all use cases - the choice depends on specific deployment scenarios, performance requirements, and compatibility constraints. The performance data across ARM64 and AMD64 architectures provides practical guidance for platform-specific optimization decisions. Future developments in WebAssembly integration, ECMAScript specification evolution, and engine security considerations will continue shaping this landscape, making ongoing evaluation essential for informed technology decisions. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] JavaScript engines show dramatic performance variations > [!quote] [JavaScript engines zoo](https://ivankra.github.io/javascript-zoo/) by [[Ivan Kravets]] via [[Personal Blog]]. Published 2024. Accessed 2024-12-28. > "Benchmark scores span multiple orders of magnitude across engine implementations." Performance differences reflect architectural choices around JIT compilation sophistication and optimization strategies. [view highlight](https://ivankra.github.io/javascript-zoo/#H1) #xref #articleseed ID:rw_js_engines_performance ### [H2] Cross-platform benchmarking reveals architecture-specific strengths > [!quote] [JavaScript engines zoo](https://ivankra.github.io/javascript-zoo/) > "Mac M4 4.5GHz vs i9-10900K 3.7GHz results show architecture-specific performance patterns." ARM64 and AMD64 platforms expose different optimization characteristics across JavaScript engine implementations. [view highlight](https://ivankra.github.io/javascript-zoo/#H2) #xref ID:rw_js_cross_platform --- ### 🔖 Atomic Split Pad (Zettel Candidates) Purpose: Promote reusable claims into Atomic notes. Split level: H4 #### [Z1] JIT compilation sophistication predicts JavaScript performance - Scope: Applies to mainstream JavaScript engines with comparable feature sets - Pointer: Performance comparison tables and JIT classification data - Links: [[JavaScript-Performance]] [[JIT-Compilation]] [[Engine-Architecture]] #### [Z2] ECMAScript ES2016+ support fragments engine compatibility - Scope: Modern JavaScript engines with different organizational priorities - Pointer: Standards compliance matrix and feature support analysis - Links: [[ECMAScript-Standards]] [[Browser-Compatibility]] [[Language-Evolution]] --- ### ✏️ Fleeting Queue Purpose: Capture quick actions for Fleeting notes. - [F1] Research WebAssembly integration impact on engine architecture — https://ivankra.github.io/javascript-zoo/ #fleeting #inbox - [F2] Investigate real-world vs benchmark performance correlation — engine selection methodology #fleeting #inbox - [F3] Analyze engine security vulnerability patterns across implementations — architecture risk assessment #fleeting #inbox - Document Tags: [[h1]] [[xref]] [[standards]] [[performance]] [[architecture]] - Summary: arm64: Mac M4 4.5GHz - Linux VM - URL: https://ivankra.github.io/javascript-zoo/ 6004 | 4.5M | 116K | C++ | 2016- | ESnext | 100% | 98% | 100% | 319 | 43 | Samsung | LGPL-2.1 | Lightweight JavaScript engine by Samsung for mid-range devices like phones/TVs. | 2686 | 2645 | 4474 | 4556 | 6152 | 778 | 2588 | 3645 | 4986 | 12371 | 2555 | 16673 | 19545 | 38815 | 9906 | 5389 | 24610 | 5383 | 3.9M | 170K | C++ | 2019- | ES2023 | 99% | 78% | 57% | 10.6k | 311 | Facebook | MIT | JavaScript engine from Facebook optimized for running React Native mobile apps. | 2291 | 1960 | 3060 | 3844 | 6854 | 1191 | 6822 | 21158 | 3706 | 9907 | 2347 | 19174 | 15710 | 12413 | 9769 | 2535 | 4877 | 4.9M | 70K | C++ | 2009-2015 | ES5 | 98% | 16% | 1% | 422 | 7 | BSD-2 | JIT-enabled ES5 engine in C++. | 1892 | 2642 | 3503 | 3323 | 5338 | 1090 | 5330 | 5750 | 3098 | 2301 | 14662 | 13014 | 13500 | 7630 | 2756 | 25547 | 4414 | 899K | 74K | C | 2019- | ES2023 | 100% | 97% | 90% | 9.7k | 16 | MIT | Lightweight embeddable JavaScript engine by Fabrice Bellard and Charlie Gordon. | 1539 | 1574 | 2039 | 2335 | 3461 | 508 | 3549 | 11297 | 3314 | 7834 | 1767 | 12494 | 13040 | 25981 | 6398 | 3986 | 22773 | 4234 | 1.1M | 74K | C | 2023- | ES2023 | 100% | 97% | 95% | 2.2k | 74 | MIT | Community-oriented fork of QuickJS. | 1381 | 1539 | 1808 | 2328 | 3417 | 470 | 4955 | 17554 | 2901 | 6763 | 1390 | 9336 | 11302 | 28758 | 6059 | 3333 | 21663 | 3733 | 1.5M | 84K | Java | Y | 1997- | ES2023 | 97% | 65% | 43% | 4.5k | 148 | Mozilla | MPL-2.0 | JavaScript engine from Mozilla for the Java platform, bundled with JDK 6-7. | 2757 | 3045 | 4273 | 4123 | 3642 | 900 | 8149 | 6729 | 3886 | 1610 | 3777 | 39293 | 877 | 4707 | 3506 | 963K | 292K | C++ | 2024- | ES2019 | 100% | 96% | 68% | 1.0k | 9 | Apache-2.0 | QuickJS-based engine from ByteDance for their cross-platform mobile apps framework Lynx. | 1260 | 1400 | 2136 | 3008 | 546 | 4115 | 14052 | 2281 | 6508 | 1275 | 9371 | 8829 | 24354 | 3105 | 3128 | 46M | 73K | C++ | 2020- | ESnext | 100% | 92% | 95% | 55.3k | 1478 | BSD-2 | JavaScript engine of Ladybird browser and SerenityOS. | 1266 | 1182 | 2528 | 1912 | 2746 | 155 | 2909 | 2762 | 3323 | 5007 | 1485 | 9336 | 11490 | 12950 | 5964 | 3993 | 12979 | 3017 | 887K | 59K | C | 2015- | ES6 | 88% | 39% | 27% | 1.5k | 34 | Nginx | BSD-2 | Lightweight embeddable JavaScript engine for use in nginx. | 1317 | 1242 | 2057 | 1784 | 3912 | 3834 | 15996 | 4761 | 2744 | 643K | 73K | C | 2013- | ES5 | 100% | 29% | 8% | 6.1k | 73 | MIT | Embeddable Javascript engine with a focus on portability and compact footprint. | 857 | 977 | 1931 | 1841 | 1901 | 447 | 4172 | 8144 | 2576 | 894 | 8067 | 25800 | 4135 | 1654 | 13388 | 2617 | 28K | JavaScript,TypeScript | Y | 2023- | 74% | 45% | 56% | 4.3k | 20 | MIT | Optimizing AOT compiler for JavaScript/TypeScript targetting WebAssembly and native binaries. | 2617 | 1573 | 974K | 42K | C++ | 1998-2023 | ES5 | 86% | 6% | 4% | 44 | 49 | KDE | LGPL-2.1 | Original JavaScript engine of KDE's Konqueror browser. | 928 | 977 | 1517 | 1427 | 2574 | 1740 | 2201 | 999 | 3042 | 1557 | 1.1M | 6.4K | Lua,JavaScript | Y | 2014-2017 | ES5 | 78% | 9% | 5% | 379 | 1 | LGPL-3.0+ | Self-hosting JavaScript to Lua compiler with a runtime library and eval(). | 587 | 664 | 766 | 3602 | 7013 | 583 | 5044 | 1295 | 5.8M | 14.4K | Go | 2025- | ES2023 | 100% | 97% | 93% | 425 | 3 | MIT | JavaScript in Go with QuickJS and Wazero. | 533 | 566 | 423 | 777 | 1239 | 202 | 2363 | 7712 | 666 | 2098 | 325 | 928 | 2941 | 12251 | 1955 | 710 | 8502 | 1225 | 5.6M | 74K | Rust | 2022- | ESnext | 98% | 94% | 96% | 13 | 1 | no | Javascript engine written in Rust, with nearly complete ES2025 support. | 311 | 469 | 550 | 1004 | 1640 | 321 | 2362 | 4226 | 642 | 281 | 1915 | 2496 | 34520 | 1357 | 1178 | 387K | 18.5K | C | 2013- | ES5 | 92% | 1% | 2% | 863 | 16 | ISC | Embeddable JavaScript engine from MuPDF. | 607 | 842 | 471 | 1317 | 1254 | 2011 | 1911 | 1242 | 2306 | 1169 | 9.0M | 47K | Go | 2024- | ES2023 | 99% | 96% | 66% | 276 | 38 | MIT | Grafana's fork of goja engine. | 432 | 520 | 283 | 698 | 1200 | 389 | 2033 | 8566 | 460 | 1092 | 231 | 1873 | 2073 | 27068 | 1178 | 433 | 6299 | 1056 | 9.0M | 46K | Go | 2016- | ES2023 | 99% | 96% | 66% | 6.5k | 34 | MIT | JavaScript engine in pure Go. Fully ES5 compliant, partially ES6+. | 440 | 524 | 284 | 706 | 1195 | 389 | 2027 | 8552 | 465 | 1115 | 232 | 1846 | 2062 | 27201 | 1184 | 436 | 779 | 36M | JavaScript | 2020-2022 | ES5 | 90% | 3% | 3% | 1.1k | 6 | Custom | Closed-source bytecode-based sandboxed ES5 interpreter in JavaScript. | 284 | 312 | 316 | 561 | 838 | 871 | 999 | 4844 | 410 | 765 | 3683 | 747 | 4.4M | 167K | Go | 2024- | ES2023 | 100% | 94% | 78% | BSD-3/MIT | QuickJS transpiled to pure Go. | 275 | 322 | 306 | 528 | 834 | 188 | 1331 | 541 | 1447 | 278 | 2055 | 12184 | 1167 | 890 | 733 | 322K | 23K | C | 2015 | ES5 | 84% | 3% | 3% | 37 | 2 | BSD-3 | Small footprint embedded ES5 engine. | 589 | 611 | 654 | 1227 | 731 | 23M | 141K | Rust | 2018- | ESnext | 99% | 98% | 89% | 6.1k | 208 | MIT/Unlicense | Embeddable Javascript engine written in Rust. | 313 | 328 | 237 | 710 | 796 | 111 | 894 | 2145 | 541 | 1394 | 211 | 1726 | 1835 | 9031 | 1545 | 323 | 618 | 12.6M | 59K | Zig | 2023- | ESnext | 97% | 92% | 87% | MIT | JavaScript engine written in Zig. | 185 | 175 | 174 | 423 | 415 | 227 | 1009 | 4098 | 331 | 1479 | 7392 | 932 | 609 | 451K | 109K | C | 2014-2024 | ES2022 | 99% | 96% | 70% | 7.3k | 127 | Samsung | Apache-2.0 | Lightweight JavaScript engine for microcontrollers. | 528 | 579 | 658 | 1038 | 264 | 145 | 1451 | 665 | 5051 | 791 | 1656 | 570 | 54 | 556 | 1.9M | 89K | C | 2002- | ESnext | 100% | 98% | 98% | 1.4k | 73 | Kinoma | Apache/LGPL | Lightweight engine for microcontrollers/IoT by Kinoma/Marvell. | 406 | 645 | 627 | 1799 | 628 | 278 | 782 | 2234 | 1544 | 19 | 92 | 3578 | 244 | 202K | 13.7K | C++ | 1995-1996 | JS1.1 | 36% | 0% | 0% | 346 | 4 | Proprietary | The very first JavaScript engine that defined early JavaScript language (JS1.0/1.1), shipped in Netscape Navigator 2.0-3.0. | 244 | 179 | 4.5M | 26K | Go | 2012- | ES5 | 91% | 5% | 6% | 8.4k | 67 | MIT | JavaScript engine in pure Go. | 60 | 56 | 57 | 175 | 193 | 412 | 2749 | 91 | 283 | 163 | 983K | 18.3K | Go,C++,TypeScript | Y | 2025- | ES2019 | 99% | 95% | 69% | 402 | 1 | Apache-2.0 | Embeddable WebAssembly-sandboxed PrimJS fork. | 56 | 56 | 57 | 62 | 118 | 19 | 193 | 1126 | 99 | 258 | 55 | 387 | 419 | 1301 | 200 | 137 | 901 | 162 | 8.3M | 102K | Rust | 2022- | ES6+ | 92% | 86% | 80% | 1.8k | 26 | MPL-2.0 | Experimental JavaScript engine written in Rust with a cache-friendly data-oriented design. | 91 | 99 | 96 | 290 | 195 | 289 | 2121 | 156 | 15 | 65 | 397 | 180 | 147 | 2.2M | 57K | Pascal | Y | 2009-2020 | ES5 | 91% | 226 | 1 | LGPL-2.1 | JIT-enabled ES5 engine written in Object Pascal. | 104 | 62 | 149 | 485 | 143 | 1.7M | 18.0K | D | 2002- | ES3 | 74% | 1% | 2% | 100 | 5 | Digital Mars | BSL-1.0 | ECMAScript implementation by Digital Mars written in D. | 56 | 66 | 358 | 316 | 117 | 263K | 40K | C | 2020- | ❌ | 1% | 0% | 0% | 122 | 21 | OpenWrt | ISC | Interpreter for a small ES6-like language for microcontrollers from OpenWrt project. | 117 | 76 | 96K | 5.0K | JavaScript | 2013- | ES5 | 92% | 3% | 4% | 2.1k | 22 | Apache-2.0 | Sandboxed ES5 interpreter in JavaScript. | 18 | 19 | 16 | 33 | 66 | 3 | 147 | 1224 | 33 | 6024 | 76 | 365 | 31 | 203K | 6.3K | JavaScript | 2007-2012 | ES5 | 90% | 33% | 44% | 917 | 25 | Mozilla | MPL/GPL/LGPL | Metacircular JavaScript interpreter, was used for prototyping new language features in ES6. | 31 | 10 | 1.7M | 42K | C++ | 2025- | ❌ | 46% | 23% | 16% | 5 | 2 | MPL-2.0 | Buggy unfinished interpreter. | 10 | 7 | 1.5M | 39K | TypeScript | 2018- | ESnext | 97% | 96% | 94% | 905 | 24 | MIT | An implementation of ECMA-262 in JavaScript aiming for 100% spec compliance, fast prototyping, validating new spec versions and test262. | 1 | 1 | 3 | 2 | 7 | 66 | 2 | 7 | 1030 | 5 | 5 | 391K | 25K | C | 2013-2017 | ES5 | 70% | 2% | 4% | 1.4k | 24 | GPL-2.0 | JavaScript engine for microcontrollers. | 5 | 1.1M | 28K | C | 2013- | ❌ | 56% | 2.9k | 159 | MPL-2.0 | Interpreter for a subset of JavaScript for Espruino microcontrollers. | 195K | 10.4K | C | 2016- | ❌ | 0% | 0% | 0% | 2.0k | 17 | GPL-2.0 | Interpreter for a subset of JavaScript for microcontrollers. | 66K | 1.2K | C | 2019- | ❌ | 0% | 1.8k | 5 | AGPL | Toy interpreter for microcontrollers for a small JavaScript subset. | 66K | 2.0K | C | 2018 | ❌ | 0% | 143 | 1 | no | Primitive unfinished interpreter. | 195K | 7.1K | C | 2012-2017 | ❌ | 53% | 0% | 1% | 94 | 5 | MIT | Buggy unfinished interpreter. | 2.3M | 51K | C | 2020-2022 | ❌ | 42% | 7% | 3% | 47 | 1 | MIT | Buggy unfinished interpreter. | 195K | 7.9K | C | 2010 | ❌ | 16% | 1% | 1% | 12 | 3 | MIT | Buggy unfinished interpreter. | 478K | 36K | C | 1998-1999 | JS1.4 | 36% | 2 | 1 | LGPL-2.0 | An independent implementation of JavaScript from late 1990s. | 131K | 2.4K | C++ | 2009-2012 | ❌ | 8% | 0% | 0% | 567 | 5 | MIT | Primitive interpreter for a limited subset of JavaScript. | 5.9M | 15.7K | Java | 2023-2025 | ES5 | 37% | 37 | 2 | MIT | ES5 interpreter written in Java. | 401K | 13.8K | Java | 2021- | ❌ | 51% | 37% | 32% | 33 | 1 | Apache-2.0 | Unfinished JavaScript engine written in Java. | 50K | 4.2K | TypeScript | 2019- | ES6 | 75% | 33% | 35% | 172 | 4 | MIT | Interpreter for a limited subset of ES6 for sandboxing untrusted code, preventing access to non-whitelisted functions/prototypes. | 4.2M | 69K | Python | 2014-2022 | ES5 | 88% | 7% | 6% | 2.6k | 29 | MIT | JavaScript interpreter written in Python. | 81K | 1.2K | Python | 2014-2017 | 0% | 59 | 1 | MPL-2.0 | Interpreter for a JavaScript-like language written in Python. | 141M | 7.2K | Python | 2009-2013 | ES3 | 47% | 6 | 5 | no | JavaScript interpreter for PyPy. | 459K | 4.7K | Ruby | 2011-2012 | ES3 | 59% | 302 | 4 | MIT | JavaScript interpreter written in Ruby. | 1.4M | 10.8K | Rust | 2018-2021 | ES5 | 21% | 8% | 2% | 562 | 2 | MIT | JavaScript engine written in Rust, aiming at ES5. | 1.0M | 5.9K | Rust | 2022- | ❌ | 19% | 92 | 1 | MIT | JavaScript interpreter written in Rust with QuickJS-inspired bytecode. | 12.1M | 177K | Rust | 2024- | 76% | 57% | 58% | 31 | 1 | MIT | JavaScript/TypeScript engine written in Rust. |, JavaScript engines zoo, ivankra.github.io, 01ka4d0rdf64tnxebyjzmhxnj2.