Use QuickJS as a Javascript Engine #4448

nickva · 2023-02-27T21:09:36Z

It might a be a nice fallback, at least, if SM is missing or cannot be built for a particular OS/arch combination. RHEL 9 had stopped including the SM package, so we'd be back into building and maintained our own separate RPM for it. #4154

Moreover, SM keeps deprecating versions fairly aggressively and new stable versions keep changing the C++ API, which makes it unfriendly for embedding. For instance: #4305

QuickJS has a few nice things going for it:

Codebase is much smaller than SM
Built for embedding and is already a popular WASM (JS-in-JS) target.
Supports ES2020 syntax
We can include/re-compile it right into couchjs and not have to depend on SM
It's possible to selective remove various ES6+ features when compiling it (Promises, Workers support etc).
It's possible to patch its parser to easily accept CouchDB map/reduce functions without the need for a full on parse-ast-transform-re-compile slowdown Performance regression on CouchDB v3 while using custom reduce function #3517

pgj · 2023-02-27T21:19:27Z

Great initiative @nickva! According to its web site, the last release of QuickJS was almost 2 years ago. Would not it cause problems or is this actually an advantage (because it suggests stability)?

nickva · 2023-02-27T21:23:09Z

@pgj a stable and simple API geared for embedding would be an advantage as opposed chasing a fast moving API made for Web browsers.

nickva · 2023-02-27T22:14:34Z

https://gist.github.com/nickva/08f6100af20d23cde6dbdd65911c02e0

A very quick and dirty benchmark of basic startup and init differences between QuickJS and SM 91. It just times initializing an empty runtime and context. then free-ing and exiting the process.

Some example runs from the gist (see that for actual patches) and more run times:

SM91

% ./configure --dev --spidermonkey-version 91 && make
% TIMEFMT=$'Total (sec): \t%*E\nMax RSS(kb): \t%M\n'
% time ./couchjs

Init (usec): 	755.000000
Free (usec): 	772.000000
Total (sec): 	0.016
Max RSS(kb): 	3336

QuickJS

% ./configure --dev --spidermonkey-version quickjs && make
% TIMEFMT=$'Total (sec): \t%*E\nMax RSS(kb): \t%M\n'
% time ./couchjs

Init (usec): 	372.000000
Free (usec): 	102.000000
Total (sec): 	0.008
Max RSS(kb): 	980

Time-wise it looks about 2x as fast to initialize and takes about 3x less memory so at least is shows some promise there.

fsync times can vary widely, especially on a remote block storage, so add a histogram and count for fsync calls. At a higher level, we can coalesce similar update doc requests from multiple clients, so add metrics to track that as well. Improving couch_proc_manager, and experimenting with quickjs js engine [1], noticed we lacked metrics in that area. Add metrics to track query process acquires, start/stops (including crashes) as well as how many prompt and prompt errors we have. These should help gain some confidence when upgrading to a new engine version or engine type by comparng the before and after metrics output. Trying to test some of these new metrics, noticed couch_file tests did most of the test logic in the setup part, which resulted in plenty of log noise during the test runs about started/stopped applications, so updated a few tests which were affected by this PR to use the ?TDEF_FE macro. That should make test output a bit smaller and neater. [1] #4448 (comment)

fsync times can vary widely, especially on a remote block storage, so add a histogram and count for fsync calls. At a higher level, we can coalesce similar update doc requests from multiple clients, so add metrics to track that as well. Improving couch_proc_manager, and experimenting with quickjs js engine [1], noticed we lacked metrics in that area. Add metrics to track query process acquires, start/stops (including crashes) as well as how many prompt and prompt errors we have. These should help gain some confidence when upgrading to a new engine version or engine type by comparing the before and after metrics output. Trying to test some of these new metrics, noticed couch_file tests did most of the test logic in the setup part, which resulted in plenty of log noise during the test runs about started/stopped applications, so updated a few tests which were affected by this PR to use the ?TDEF_FE macro. That should make test output a bit smaller and neater. [1] #4448 (comment)

https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Only tested on MacOS and Linux. All `make check` tests pass there. Issue: #4448

nickva · 2023-08-09T21:35:05Z

Updated PR #4627 with a wip skeleton of a couch_scanner app.

couch_scanner is an applications which knows how to scan databases/design_docs in the background, at a low rate, with periodic checkpointing. The idea, as discussed during the dev meeting a month or two ago, is to use it compare quickjs engine output with sm output and report discrepancies/incompatibilities as an extra safety for users to verify they can switch to the new js engine. Other uses could be to accumulate some cluster-wide states: total index sizes, some ddoc features (any docs using lists or shows) etc.

nickva · 2023-09-05T19:16:15Z

To avoid managing a new data state directory (config option, checking for disk space, handling read-only or other errors), it would be a lot simpler to manage the checkpoints as simple _local docs in _dbs. There is precedent for using that exact mechanism for shard splitting job management.

The general idea is that there is a general mechanism to traverse databases and ddocs. Periodically it will update its checkpoint in _dbs/_local/scanner_checkpoint doc with the current db and ddoc (and some job id, start time, initial settings, and a few other bits if needed).

Then, as the traversal happens, a call is made to each of the configured callback modules(scanner_quickjs_compact_check, 'scanner_size_stats`, ...) with the db and ddoc in turn. After all the callbacks are called the context for each individual module will be updated. It can be a simple map (json object). Then each module can do its own processing: write to some database, write to disk, log a report, etc.

The configuration could look something like:

[scanner]
enable = true | false
schedule_period = once | every_week | every_day | ...

[scanner.$module] ...
enable = true | false
... $module specific settings ...

For instance:

[scanner.quickjs_compat_check]
enable = true | false
sample_docs = 100
check_reduce = true | false
log_report_level = warning

nickva · 2023-09-11T22:32:57Z

The callback API for each scanner module might look like:

{ok, Ctx} = start_scan(#{session_id => Uuid, start_timestamp => UnixTs})
{ok, Ctx1} = start_db(Ctx, DbName)
{ok, Ctx1} = ddoc(Ctx, DbName, DDoc = #doc{})
{ok, Ctx1} = shard(Ctx, Db)
{ok, Ctx1} = end_db(Ctx, DbName)
ok = end_scan(Ctx)

This flow would be initialized and kept for each module individually. The scanner server process would hold a context that looks like:

#state{modstates = #{Module1 => Ctx1, Module2 => Ctx2} ....}

The scan would be run on all the nodes. During scanning only the dbs with the first shard copy on that node would be scanned. The API doesn't call per-document callback. The idea would be that each plugin them may choose to sample only some docs or process all the docs or simply return {ok, Ctx} and move on.

A few events might stop or pause scanning:

cluster membership changes (or just nodelist changes?)
configuration change (should .ini configuration changes stop and reset the scan?)

https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Only tested on MacOS and Linux. All `make check` tests pass there. Issue: #4448

https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/quickjs/ Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` Tested on MacOS and Linux. All `make check` tests pass there. Issue: #4448

https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual view, without making the default use the `javascript_quickjs` language in design docs. Tested on MacOS and Linux. All `make check` tests pass there. Issue: #4448

https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. Tested on MacOS and Linux. All `make check` tests pass there. Issue: #4448

https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448

mozjs-91 does not support python 3.12.x, thus couchdb for meta-erlang can't usemozjs-91 anymore. So, this commit is trying to use (an under development branch) quickjs as an alternative [1] to mozjs. 1: apache/couchdb#4448

https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448

nickva · 2024-05-01T21:11:48Z

As discussed in one of the CouchDB dev meetings, the last two required features for #4627 support were:

Windows support
A way to scan and find compatibility issues vs current Spidermonkey

Now both of those features are implemented in PR.

https://bellard.org/quickjs Some benefits over SM: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already. (see #4154). * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so. (see #4305). * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Configurable runtime feature set - can disable workers, promises and other API and features which may not work well in a backend JS environment. Some users may want more, some may want to disable even Date(time) features to hedge again Spectre-style attacks (spectreattack.com). * Allows granular time (reduction) tracking if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448

Some benefits over Mozilla Spidermonkey: * Small. We're using 6 or so C files vs 700+ SM91 C++ files. * Built with Apache CouchDB as opposed having to maintain a separate SM package, like for RHEL9, for instance, where they dropped support for SM already [1]. * Embedding friendly. Designed from ground-up for embedding. SM has been updating the C++ API such that we have to keep copy-pasting new versions of our C++ code every year or so [2]. * Easy to modify to accept Spidermonkey 1.8.5 top level functions for map/reduce code so we don't have have to parse the JS, AST transform it, and then re-compile it. * Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. * Seems to be faster in preliminary benchmarking with small concurrent VDU and view builds: https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758 Results seem promising: - 4x faster than SM 1.8.5 - 5x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) * Allows compiling JS bytecode ahead of time a C array of bytes. QuickJS can be built alongside Spidermonkey and toggled on/off at runtime: ``` ./configure --dev --js-engine=quickjs ``` This makes it the default engine. But Spidermonkey can still be set in the config option. ``` [couchdb] js_engine = spidermonkey | quickjs ``` To test individual views, without switching the default use the `javascript_quickjs` language in the design docs. To keep using Spidermonkey engine after switching the default, can use `javascript_spidermonkey` language in design docs. However, language selection will reset the view and the view will have to be rebuilt. It's also possible to build without Spidermonkey support completely by using: ``` ./configure --disable-spidermonkey ``` Issue: #4448 [1] #4154 [2] #4305

The couchdb build is broken because the version of mozjs supported by couchdb is not compatible with python 3.12.x ar greater. That brings a difficult situation where the best thing for now is to remove couchdb and wait couchdb developers to integrate a new JS engine [1]. In meta-erlang, patches exist in order to bring back couchdb with new JS engine [2]. But it's not time to integrate it yet. 1: apache/couchdb#4448 Use QuickJS as a Javascript Engine 2: #293 couchdb: move to main branch and remove mozjs

nickva added javascript viewserver discussion enhancement labels Feb 27, 2023

nickva mentioned this issue May 20, 2023

Add a few more commit and query engine metrics #4608

Merged

nickva mentioned this issue May 25, 2023

Add QuickJS as a Javascript engine option #4622

Closed

nickva mentioned this issue May 30, 2023

Add QuickJS as a Javascript engine option #4627

Merged

nickva mentioned this issue Oct 30, 2023

Spidermonkey 91 is EOL and unsupported #4825

Open

nickva changed the title ~~Investigate using QuickJS as a Javascript Engine~~ Use QuickJS as a Javascript Engine May 2, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use QuickJS as a Javascript Engine #4448

Use QuickJS as a Javascript Engine #4448

nickva commented Feb 27, 2023

pgj commented Feb 27, 2023 •

edited

Loading

nickva commented Feb 27, 2023 •

edited

Loading

nickva commented Feb 27, 2023

nickva commented Aug 9, 2023

nickva commented Sep 5, 2023

nickva commented Sep 11, 2023 •

edited

Loading

nickva commented May 1, 2024

Use QuickJS as a Javascript Engine #4448

Use QuickJS as a Javascript Engine #4448

Comments

nickva commented Feb 27, 2023

pgj commented Feb 27, 2023 • edited Loading

nickva commented Feb 27, 2023 • edited Loading

nickva commented Feb 27, 2023

nickva commented Aug 9, 2023

nickva commented Sep 5, 2023

nickva commented Sep 11, 2023 • edited Loading

nickva commented May 1, 2024

pgj commented Feb 27, 2023 •

edited

Loading

nickva commented Feb 27, 2023 •

edited

Loading

nickva commented Sep 11, 2023 •

edited

Loading