6 ms·

How about an (actually small but ES6 feature complete) JS engine for general computers? QuickJS showed so much promise (especially given the pedigree) but it's

How about an (actually small but ES6 feature complete) JS engine for general computers? QuickJS showed so much promise (especially given the pedigree) but it's been dead for a year and it never really delivered on the promise of being small (I guess the code is small, but at runtime it takes more memory than engines with full JIT like V8 or Chakra). Hermes looked interesting, but it's clear it will never be an actual JavaScript engine, it's more like a React Native engine that interprets some subset of JavaScript. Duktape struggles with larger bundles and especially with deep call stacks (same as QuickJS) and the C API gives me strong Lua vibes (which may be a positive for some).

ricardobeat 4y ago
The last commit on QuickJS is from March. Do you have a source for that memory use comparison with V8? I haven’t had first-hand experience with it. I do have experience using Duktape and haven’t had any issues with large call stacks, but also haven’t tried to run anything like a React app in it. The C API was indeed very enjoyable to use.
deleted 4y ago
[deleted]
juancampa 4y ago
> never really delivered on the promise of being small I wonder why you say this. I just ran both qjs and node's REPL and qjs is taking 2.4MB vs 21.5MB for node. Are you referring as QuickJS running with a specific workload? Do you happen to have more info on this measurement?
- juancampa 4y ago
  Here's a list of features not supported by Microvium. AFAIK, QuickJS supports all of those (except maybe Intl) https://github.com/coder-mike/microvium/blob/main/doc/supported-language.md#not-supported https://github.com/coder-mike/microvium/blob/main/doc/suppor...
- gigel82 4y ago
  I don't have anything in Open Source for this, but ran an internal test on a large bundle a while back (7Mb of minified JavaScript with a fairly complex execution pattern) and after the test setup idles, I was seeing 67Mb with V8, 94Mb with Chakra and 109Mb with QuickJS on used memory (also, QuickJs needed a stack increase because it's passing large arguments as values). This was on x64 Windows, it's possible results differ on other platforms.
ridiculous_fish 4y ago
I worked on Hermes and I would say it's absolutely an actual JavaScript engine, targeting the ES spec. Its focus on startup performance means it makes different tradeoffs than other engines.
- gigel82 4y ago
  I respectfully disagree. In order to debug Hermes, you need to build React Native (the inspector / CDP component is not part of the Hermes Git repo). There are React Native features inside Hermes (like drain microtasks, etc.). And you need special Metro bundler configs to produce bundles that are compatible with Hermes (somewhat ES5, definitely not ES6).

ricardobeat 4y ago

The last commit on QuickJS is from March. Do you have a source for that memory use comparison with V8? I haven’t had first-hand experience with it. I do have experience using Duktape and haven’t had any issues with large call stacks, but also haven’t tried to run anything like a React app in it. The C API was indeed very enjoyable to use.

deleted 4y ago

[deleted]

juancampa 4y ago

> never really delivered on the promise of being small I wonder why you say this. I just ran both qjs and node's REPL and qjs is taking 2.4MB vs 21.5MB for node. Are you referring as QuickJS running with a specific workload? Do you happen to have more info on this measurement?

juancampa 4y ago
Here's a list of features not supported by Microvium. AFAIK, QuickJS supports all of those (except maybe Intl) https://github.com/coder-mike/microvium/blob/main/doc/supported-language.md#not-supported https://github.com/coder-mike/microvium/blob/main/doc/suppor...
gigel82 4y ago
I don't have anything in Open Source for this, but ran an internal test on a large bundle a while back (7Mb of minified JavaScript with a fairly complex execution pattern) and after the test setup idles, I was seeing 67Mb with V8, 94Mb with Chakra and 109Mb with QuickJS on used memory (also, QuickJs needed a stack increase because it's passing large arguments as values). This was on x64 Windows, it's possible results differ on other platforms.

ridiculous_fish 4y ago

I worked on Hermes and I would say it's absolutely an actual JavaScript engine, targeting the ES spec. Its focus on startup performance means it makes different tradeoffs than other engines.

gigel82 4y ago
I respectfully disagree. In order to debug Hermes, you need to build React Native (the inspector / CDP component is not part of the Hermes Git repo). There are React Native features inside Hermes (like drain microtasks, etc.). And you need special Metro bundler configs to produce bundles that are compatible with Hermes (somewhat ES5, definitely not ES6).