QuickJS JavaScript Engine • Hacker News Board

Re: QuickJS JavaScript Engine

#11

Post by agumonkey » Thu, Jul 11, 2019, 4:46 PM UTC

I wonder how different jslinux (obviously) would behave on it.

Re: QuickJS JavaScript Engine

#12

Post by munificent » Thu, Jul 11, 2019, 4:49 PM UTC

pcwalton wrote: post #10

quickjs.c is a 47,842 line C file. I think that sets the record for the largest handwritten file I've seen.

Is it hand-written as a single file, though? I'm assuming the release is the output of some script that does concatenation.

Re: QuickJS JavaScript Engine

#13

Post by dodo6502 » Thu, Jul 11, 2019, 4:56 PM UTC

Would this be a suitable replacement for SpiderMonkey as an embedded JS engine for a Desktop Application?

Re: QuickJS JavaScript Engine

#14

Post by TAForObvReasons » Thu, Jul 11, 2019, 5:02 PM UTC

dodo6502 wrote: post #13

Would this be a suitable replacement for SpiderMonkey as an embedded JS engine for a Desktop Application?

Many projects use duktape (https://duktape.org/)

Re: QuickJS JavaScript Engine

#15

Post by heapjs » Thu, Jul 11, 2019, 5:04 PM UTC

Would it be possible to compile a nodejs app to a binary with this? If so, would performance be any better?

Re: QuickJS JavaScript Engine

#16

Post by bobajeff » Thu, Jul 11, 2019, 5:09 PM UTC

I'm curious as to how the reference counting works in this. Is it comparable to what's used in Swift? How is it compared to the methods typically used in V8 and Spider Monkey?

Re: QuickJS JavaScript Engine

#17

Post by mstade » Thu, Jul 11, 2019, 5:10 PM UTC

heapjs wrote: post #15

Would it be possible to compile a nodejs app to a binary with this? If so, would performance be any better?

I think you'd need to translate node specific APIs in order to make this work, e.g. i/o features and require function. It is probably more work than just rewriting the app to use QuickJS APIs instead, but I don't think it's impossible to make some sort of compatibility or translation layer. Couldn't say if it'd be more performant, but it'd have a killer feature over node: compilation to single binary without dependencies.

Re: QuickJS JavaScript Engine

#18

Post by xvilka » Thu, Jul 11, 2019, 5:15 PM UTC

kybernetikos wrote: post #7

stcredzero wrote: post #6

Earlier quoted context omitted.

This is fast enough, it could be used to write command line utilities in Javascript! What about a Javascript OS in the style of the Lisp machines or early Smalltalks?

Record-query [1] embeds v8 for its query language, which seems to add a significant amount of heft. I know that couchdb uses js for querying as well. It seems like this could be another option for something like that. [1] https://github.com/dflemstr/rq

Convert the QuickJS code into Rust using c2rust[1], then reuse in rq.

[1] https://github.com/immunant/c2rust

Re: QuickJS JavaScript Engine

#19

Post by lhorie » Thu, Jul 11, 2019, 5:18 PM UTC

heapjs wrote: post #15

Would it be possible to compile a nodejs app to a binary with this? If so, would performance be any better?

Doesn't look like. It uses the `os` module name for its own thing, so you'd need at a minimum to patch that (in addition to actually having to implement all of Node's APIs on top of the `std` primitives or as C modules)

Re: QuickJS JavaScript Engine

#20

Post by mstade » Thu, Jul 11, 2019, 5:19 PM UTC

I just tried building this on my Mac and it looked initially like it all was building fine, but it eventually failed when building qjs32.

Thinking this probably didn't matter much I went ahead and ran `./qjs examples/hello.js` which worked as advertised – cool! Tried `./qjsbn examples/pi.js 5` and it worked as well – very cool! Then I tried `./qjs examples/hello_module.js` and got this:

    SyntaxError: unsupported keyword: import
        at examples/hello_module.js:3

I don't know what I did wrong – anyone else try it yet?