Enumerating and analyzing 40 non-V8 JavaScript implementations | Hacker News Reader

Enumerating and analyzing 40 non-V8 JavaScript implementations

notes.eatonphil.com

100 pointsEntICOnc29 comments

I am astonished at the omission of ChakraCore, open sourced by Microsoft as what Edge used to use, but sadly abandoned by them after they switched Edge to Chromium: https://github.com/chakra-core/ChakraCore. But it looks like it’s still chugging along as a community effort rather than being completely abandoned.

ChakraCore is definitely one of the most notable and significant implementations after the big three.

It was on my list but missed getting into the post by accident. It will be up shortly!

I would be interested in some spec test suite coverage figures. I have used a few js engines in the past (nashorn, rhino, otto) and all had problems with missing edge cases in the APIs or really weird quirks in the interop with the host environment.

https://github.com/tc39/test262 is the ecma test suite.

rhino for example has extensive gaps: https://github.com/mozilla/rhino/blob/master/testsrc/test262...

It is really frustrating that in the end, there aren't really that many actually compliant implementations. Especially implementing the exact regex behaviour.

EDIT: apparently this exists, at least partially: https://kangax.github.io/compat-table/es6/

The smaller engines are missing however.

I can't imagine writing an interpreter for JS that handles all its autoconversion foibles, and now with several more generations of ECMAScript version features piled on (generally for the better), that's a lot more to handle.

And then have to do all the type inferencing to try to get performance, and then the dynamic compiling...

Qt's ES7 js engine has always been solid for me: https://doc.qt.io/qt-5/qjsengine.html ; it used to use V8 but they rewrote it to be better optimized for Qt's needs AFAIK.

Qt switched so many times I had a hard time following. I didn't want to include every different branch when I did know they were using V8 for a while.

I'll still probably leave them out of this post but totally fair to bring them up.

There were only two switches afaik. The current engine has been used since 2013 (https://www.qt.io/blog/2013/04/15/evolution-of-the-qml-engin...), this is likely longer than some of the other engines mentioned on your page did exist

Ok sweet I see now. They used JavaScriptCore until 2011 or so, switched to V8 until 2013, and have been using their own implementation, q4, since then. The source code seems to be here: https://github.com/qt/qtdeclarative/tree/dev/src/qml/jsrunti....

Thanks! Will add and be live shortly.

Since AssemblyScript counts, I’ll also mention Static TypeScript[1], which I just discovered yesterday. It’s also a subset of TS, which compiles to native machine code.

1: https://makecode.com/language#static-typescript

Ah thanks for the reminder. That could go into the research section too. Will add shortly. Thanks!

Interesting to see a JS implementation written in JS:

https://github.com/engine262/engine262/

(The readme explains what the point of it is.)

And that's only one of two implementations in the post written in JavaScript! The second is "JS-Interpreter".

There is also the abandoned js.js

Oops yes you're right!

Any chance you could add a link for SpiderMonkey? It has its own site now: https://spidermonkey.dev/

I made a toy ECMAScript interpreter a couple of years ago: https://github.com/mras0/mjs

Not really notable, expect perhaps being the only one on the list with an ES1 mode? :) (Can't promise it's accurate though, as it was hard to find examples).

Otherwise pretty boring (C++, hand-written parser, AST interpreter, ES1/ES3/ES5.1 support minus some regexp/timezone/locale stuff).

I'll add it to the toy list. Thanks!

Honored to see that it made the cut in your updated list, but it seems like there's a stray ']' at the end of the link :)

Heh, thanks. Fix should be live shortly.

Also missing is jint, an interpreter in C#

https://github.com/sebastienros/jint

Thanks! Adding and will be live shortly.

It would be nice to see some benchmarks.

Benchmarks for a competent JS that does loop analysis, code emission, and the attendant warmup/dynamic compiling is tough. It's why Java JVMs are endlessly debated on performance vs compiled languages, fairly or not.

I've often wondered why nginx decided to implement their own njs Javascript instead of just embracing lua/luajit which already has a very healthy ecosystem in nginx and, as far as I know, is still orders of magnitude faster than even the fastest Javascript implementations.

According to Igor Sysoev’s 2015 presentation, they disliked Lua’s divergences from the C-style (e.g. begin/end, 1-indexing) as well as the “non-standard” syntax for regex (which would be pretty important for scripting nginx). And while he acknowledged that javascript has its own oddities, as far as he was concerned people are used to those from their use in other contexts.

If you want to watch the entire thing, it’s “A new and powerful way to configure nginx” on youtube.

The article describes a list of engines to embed, so this falls out of scope.

But I still wanted to highlight Opera's Carakan engine which was developed in head-to-head competition with V8 when Opera was still maintaining their own engine.

https://en.wikipedia.org/wiki/Presto_(browser_engine)#ECMASc...

Moddable's XS JavaScript engine is great for low-resource microcontrollers, with 99%+ conformance to the 2020 JavaScript language standard. It's built by a brilliant team of ex-QuickTime and ex-Apple Media Tool engineers.

https://www.moddable.com/faq.php#what-is-xs

Oddly missing the embedded-in-windows Chakra? (And chakracore)

There really doesn't exist js engine on top of lua or implemented in ocaml?

Reply on news.ycombinator.com