Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QuickJS JavaScript Engine

bellard.org

Post reply on HN
Print view View original

21–30 of 279 posts

Re: QuickJS JavaScript Engine

#21

Post by dpacmittal »

mstade wrote: post #17
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 dependen…

Couldn't you replace v8 with this and recompile the node binary? If it passes 100% ECMAScript tests, that should mean it's a drop-in replacement for v8. Correct me if I'm wrong.

Re: QuickJS JavaScript Engine

#22

Post by dan-robertson »

bobajeff wrote: post #16

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?

This is a very broad question. Garbage collection is a large topic. The general consensus is that reference counting methods give typically lower throughput than heap scanning methods but (I think) lower total memory usage and more predictable performance.

They do bookkeeping on every free whereas a heap scanning gc will typically do bookkeeping in small incremental bits on alloc and mainly on gc cycle (when space runs low).

Re: QuickJS JavaScript Engine

#23

Post by btmills »

mstade wrote: post #20

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 keywo…

Try adding the `--module` flag [1]. JS now has two different grammars, script and module, and the `import` keyword is only allowed in module code.

[1] https://bellard.org/quickjs/quickjs.html#qjs-interpreter

Re: QuickJS JavaScript Engine

#24

Post by jarav »

mstade wrote: post #20

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 keywo…

Try ./qjs -m examples/hello_module.js

Re: QuickJS JavaScript Engine

#25

Post by tombert »

Is there anything that Fabrice can't do? I mean, FFMpeg is almost a PhD thesis in and of itself, and he still manages to find time to make TinyC, QEMU, and now this. To say I'm jealous of his skills would be an understatement.

Re: QuickJS JavaScript Engine

#26

Post by anderspitman »

This man is a wizard. You can also thank him for ffmpeg and qemu. A company I worked for once tried to hire him as a consultant because he had implemented an LTE BTS in software. Is there anything he hasn't done?

EDIT: tombert beat me to it[0] by a couple minutes.

[0] https://news.ycombinator.com/item?id=20413498

Re: QuickJS JavaScript Engine

#27

Post by saagarjha »

munificent wrote: post #12
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.

From a cursory glance, it doesn't look like it's a bunch of files concatenated together.

Re: QuickJS JavaScript Engine

#28

Post by errantspark »

I can't wait to mess around with this, it look super cool. I love the minimalist approach, if it's truly spec compliant I'll be using this to compile down a bunch of CLI scripts I've written that currently use node.

I tend to stick with the ECMAScript core whenever I can and avoid using packages from NPM, especially ones with binary components. A lot of the time that slows me down a bit because I'm rewriting parts of libraries, but here everything should just work with a little bit of translation for the OS interaction layer which is very exciting.

Re: QuickJS JavaScript Engine

#29

Post by mobilio »

tombert wrote: post #25

Is there anything that Fabrice can't do? I mean, FFMpeg is almost a PhD thesis in and of itself, and he still manages to find time to make TinyC, QEMU, and now this. To say I'm jealous of his skills would be an understatement.

You forgot LZEXE...

Re: QuickJS JavaScript Engine

#30

Post by exebook »

dpacmittal wrote: post #21
mstade wrote: post #17

Earlier quoted context omitted.

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 dependen…

Couldn't you replace v8 with this and recompile the node binary? If it passes 100% ECMAScript tests, that should mean it's a drop-in replacement for v8. Correct me if I'm wrong.

fs/net and some other important pieces of Node.js are written as C++ addons for v8, hooking them would be very difficult I guess. Though Microsoft have been working on this for their ChakraCore engine. There was a conflict if I recall correctly, Microsoft suggested to add another abstraction layer to make hooking other JS engines easier but Node.js team refused it. I might not know that situation very well. But I have downloaded ChakraCore based Node.js once and it ran my project without problems, though the performance was about 5% slower.
Post reply on HN