switch to deno_core?

[amitu]

We are currently using quick-js as our JS engine. We can switch to Deno, which is built on top of V8?

https://deno.com/blog/roll-your-own-javascript-runtime

Reason: speed https://bellard.org/quickjs/bench.html:

[amitu]

Direct v8 is better instead of Deno core.

[harshdoesdev]

I was working on an issue related to QuickJS and thought of experimenting with other JavaScript runtimes as well. The quickjs crate was failing to evaluate large JavaScript files with a stack overflow error, and there was no documented way of increasing the stack size. So, I tried increasing the stack memory limit of the rquickjs crate and removed the quickjs crate. I tested it on a fork of fastn, and the tests were passing, but the speed was 5x slower than V8.

So, I tried using V8 as a runtime using the v8 crate, but it too was failing to eval large JavaScript code with a segmentation fault error. It worked on the spellcraft project but failed to completely build fastn.com. Then, I tried deno_core, and the speed benefit was clear. It took 4 seconds to build the spellcraft project vs. 24 seconds using rquickjs. I did some more optimizations like removing the Deno object from the global scope (as suggested in this discussion).

The following table shows the amount of time it took to build these fastn projects using different JavaScript runtimes:

Project	Runtime	Build Time
Spellcraft	rquickjs	24 seconds
Spellcraft	deno_core	4 seconds
fastn.com	deno_core	~16 minutes 31 seconds
fastn.com	rquickjs	~20 minutes 49 seconds

I was wondering whether we can temporarily switch to deno_core until I am able to make V8 work with fastn, which we were going to do anyway.

cc: @amitu @Arpita-Jaiswal

[amitu]

Good job! Let's use deno core for now.