Oh nice to see this here! I’m the author of this little amalgamation, happy to answer any questions :-)

I just love small (for certain definitions of small) C libraries and got hooked to QuickJS the moment I tried it. After a few weekends of tinkering I had “quv” which was just QuickJS running on the libuv event loop. Later on I integrated curl and implemented xmlhttprequest on top of it. The last large change I made was to embed wasm3 as the WASM / WASI runtime.

I haven’t had the time to continue working on it for a while, seeing this here might be the encouragement I needed! :-)

What kind of applications Txiki is a good fit?

Would be nice to get some debugging capabilities. Perhaps implementing the devtools protocol

Oh, goody. Last time I tried QuickJS it didn't have support for asynchronous generators and proxies.

Thank you, Mr. Bellard and whoever is working on this runtime. Your work is appreciated

Since it's presented as a "tiny" runtime, I'd like a size comparaison between this and Node in the readme. Same thing with the use cases (learning projects or "just for fun" are very valid use cases!).

Replying to myself, on Pop!_OS I get a final tjs build of 1.8 Mo. My Node weighs 71 M for comparaison.

In fact 1.8 Mb is quite a lot for QuickJS.

My Sciter engine that includes as QuickJS as HTML/CSS engines is about 6 Mb.

My port of QuickJS [1] that also includes persistent storage (think of MongoDB built into JS) is 736 Kb on Windows.

[1] https://github.com/c-smile/quickjspp

The project also includes wasm3 for WASM, curl and libuv. That's probably what's taking space.

Why is node so large?

V8 alone is around 40/50 Mb.

And used to be under 10 MB.

https://groups.google.com/g/v8-users/c/OaC4TQQjxFg

Probably because Node (and V8) don't try to optimize for size but for speed of execution.

QuickJS [0] quotes a 210KiB binary.

[0] https://bellard.org/quickjs/

Fabrice Bellard is a legend.

For other small JS engines similar to QuickJS see Hermes: https://github.com/facebook/hermes

Hermes is far from a small JS engine (and is not really similar to QuickJS at all).

Duktape, Espruino and JerryScript are way closer examples (both in size and spirit).

Fitbit uses Jerryscript in some of their watch OSes. Well, at least they were last time I was tinkering with making my own watch face

https://jerryscript.net/

Related :- https://github.com/just-js/just

Is this intended to be used with the C header as an embedded lib + runtime to add JS scripting support to applications?

For the moment the intended use case is experimentation, by using the tjs binary as the runtime.

Embedding is something I’d like to get to, eventually.

Good stuff, I'm interested, what's the use case here? And what trade offs compared to nodejs are we making?

No defined use case really, tinkering :-)

Initially I just wanted to try out some other ways to build a JS runtime, now that the web is much more advanced than it was when Node was created.

Shortly after I realized my goals aligned very well with those of Deno: provide web APIs where possible on a CLI / server runtime. Granted Deno is a much bigger beast.

Can we compile this to WASM and compile JavaScript to a binary format that includes the runtime?

I wonder if multi-threaded JS will ever be a thing, despite the event-loop nature of the language

It's something I'd like to see. I have wondered if quickjs might serve as an experimental base to try and implement such a beast. The main issue is having a thread aware object lifetime mechanism. I think quickjs is a reference counting GC. It might be possible to wedge something in there.

the language isn't inherently event-looped. even in the browser you can use workers.