Single HTTPS server for QuickJS, Bun, Deno, Node.js - without reliance on either to build

[guest271314]

Single HTTPS server for QuickJS, Bun, Deno, Node.js - without reliance on either to build.

No such animal exists right now.

[ljharb]

relying on either what?

[guest271314]

Without relying on Node.js to build a server that can be imported into QuickJS. I don't actually ever install Node.js, Deno, Bun, or QuickJS. I fetch the executables and test the gear, mainly as Native Messaging hosts. SOmebody referred me to unjs/nitro here https://www.reddit.com/r/javascript/comments/106m5i6/comment/j3isli5/?utm_source=share&utm_medium=web2x&context=3 which turns out relies on Node.js to build.

So I fetch the Node.js nightly download, yet instead of what I normally do, get rid of everything except the node executable https://github.com/guest271314/download-node-nightly-executable I kept the whole download. But Node.js expects you to install Node.js, so then comes the task on manually changing paths re npx, etc. I've done that before here https://github.com/guest271314/jsdom-extension for

• Incorporating JSDOM into V3 Chrome Extension Service Worker jsdom/jsdom#3315
• The MV3 migration guide recommends jsdom, but it cannot be used in browsers out of the box GoogleChrome/developer.chrome.com#2290
• JSDOM Support in the Browser? jsdom/jsdom#245 (comment)

yet it is extremely tedious - just to build a server using Node.js that I intend to primary use in QuickJS - because node consumes too much resources to justify using.

In that same reddit question somebody referred me here https://www.reddit.com/r/javascript/comments/106m5i6/comment/j3lp4yu/?utm_source=share&utm_medium=web2x&context=3.

I know the StackBlitz claim about Node.js in WebAssembly is suspicious because I had already asked them, and they claimed the code was essential closed-source.

I don't deal with false, untrue, spurious claims - not well at least. I'm calling folks on their false claims, especially in documentation, no matter who they think they are. The result is me usually getting banned. I'm fine with that. I vet all claims, without exception; e.g.,

Node requires node_modules and npm.

is not true and correct; false advertising guest271314/banned#7.

[guest271314]

Why

I test your gear.

E.g., https://gist.github.com/guest271314/93587ee12d61154fb26954e17f87e160.

#35 (comment):

@ljharb Look, somebody referred me to this repository on reddit, responding to my question for a single server that can be imported into QuickJS, Bun, Deno, and Node.js. For various reasons:

• Both Node.js and Deno are dependent on V8, which consume unnecessary resources just to get a JavaScript runtime: 80-100MB executables; 250MB memory allocation for node; 5.6GB memory allocation for deno - with no explanation why nor any clearly specified V* flags to stop that insane behaviour;
• Bun executable bun consumes ~37MB for a runtime; 100MB memory allocation;
• QuickJS only allocates 4.7MB, and runtime uses ~3MB, is not shipped with a built-in server.

So my idea was to import Deno's HTTPS server into QuickJS. Then, hell, why not create a server that can be imported into all JavaScript runtimes? Seems like right up the alley of this body.

I used Deno's server because the sematics resembled ServiceWorker API onfetch handler.

Then I observed deno executable alone was allocating 5.7GB of resources.

QuickJS is compiled to WASM by several applications

• https://github.com/second-state/wasmedge-quickjs
• https://github.com/justjake/quickjs-emscripten
• https://bellard.org/jslinux/vm.html?url=alpine-x86.cfg

There is no such animal that I am aware of re FOSS Node.js or Deno in WASM - because of the sheer size of V8 and dependencies - minimum 40MB to run the executable and between 250MB to 5.7GB of memory allocated. The browser tab generally can handle that and will more than likely crash or freeze the entire machine - especially if you are running a live OS on RAM only to begin with.

StackBlitz claims to have compiled Node.js to WASM, yet the code is evidently closed source stackblitz/webcontainer-core#658. Not interoperable at all.

You question Node.js and Deno narrative they ban you. The numbers tell the tale; QuickJS is the fastest Native Messaging host between Node.js, Deno, Bun, and QuickJS https://gist.github.com/guest271314/fb8969a956a873e495b890a42ac0d731.

A few JavaScript engines makes this or that claim; from being the fastest to having this or that module; etc.

I test the executable standalone until the claim breaks, or is verified true and correct.

It makes sense to test the same server on different JavaScript engines.

When there is a deliverable all stakeholers will have learned how to cooperate to achieve the goal, and there will be nowhere to hide behind a narrative when we are all testing the same imported code. That is interoperability.

How

Thus, there should be a server written in C, C++, Rust - even JavaScript that can be imported via import into the arbitrary JavaScript engine that supports Ecmascript/HTML import.

Through the process you will see how divergent the JavaScript engines are, and how they are alike. Improving networking uniformity along the way. That is the goal.

[jasnell]

This is not in scope for wintercg.