Closed guest271314 closed 1 year ago
relying on either what?
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
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
andnpm
.
is not true and correct; false advertising https://github.com/guest271314/banned/issues/7.
Why
I test your gear.
E.g., https://gist.github.com/guest271314/93587ee12d61154fb26954e17f87e160.
https://github.com/wintercg/proposal-common-minimum-api/issues/35#issuecomment-1376661447:
@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 fordeno
- 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
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 https://github.com/stackblitz/webcontainer-core/issues/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.
This is not in scope for wintercg.
Single HTTPS server for QuickJS, Bun, Deno, Node.js - without reliance on either to build.
No such animal exists right now.