native-messaging-nodejs VS proposal-common-minimum-api

And/or control node and any other programming language from the browser using Native Messaging native-messaging-nodejs.

We can process asynchronous tasks without blocking reading stdin (e.g., full-duplex).

WHat do you mean by "contribute"? I download only the node executable using download-node-nightly-executable to run native-messaging-nodejs, servers, or whatever else I decide to experiement on - without downloading any packages.

I re-wrote the original code substituting using readSync for process.stdin.on('readable', () => {}) and including process.stdout._handle.setBlocking(true) and readFullSync function contributed by a Deno user https://github.com/guest271314/native-messaging-nodejs/blob/main/nm_nodejs.mjs. I wanted to a) get the input message (up to 1MB at a time) echo'ed back to the client; and b) get away from using process.stdin.on('readable', () => {}), rather use an approach that did not include event listeners; c) get away from using CommonJS and package.json and instead use Ecmascript modules without package.json.

If you want you can use a Node.js Native Messaging host https://github.com/guest271314/native-messaging-nodejs, Deno, QuickJS, txiki.js, Bun, C, C++, Python, WASI/WebAssembly or whatever language is built in, e.g., Bash.

I just fetch the nightly node executable, get rid of everything else in the archive, use .mjs extension for import to work without package.json, then I can connect to the host https://github.com/guest271314/native-messaging-nodejs, and start subprocesses, e.g., raw PCM streams, where stdout is streamed to the client (browser), e.g, https://github.com/guest271314/captureSystemAudio/blob/master/native_messaging/capture_system_audio/capture_system_audio_node.js.

Yes, utilizing Native Messaging https://github.com/guest271314/native-messaging-nodejs.

If you are considering building a modern JavaScript runtime I would suggest reading Minimum Common API.

Deno, CloudFlare Workerd, VM Labs WASM Worker Server, and others use some semblance of the ServiceWorker onfetch pattern as a server implementation. Why? Because onfetch of a ServiceWorker with Response() used to send a response to the client is ergonomic. Web API's being implemented by JavaScript runtimes that do not target the browser. In order to try to normalize implementation of Web API's for compatibility there is https://github.com/wintercg/proposal-common-minimum-api.

I guess you do not support Minimum Common API even though Node.js does?

Common I/O (stdin/stdout/stderr) module specification #47.

My goal for one part of this project was to use the same fetch() code in a Node.js and Deno Native Messaging host, respectively, in the spirit of Minimum Common API

The premise of this question is precisely why I filed Single HTTPS server for QuickJS, Bun, Deno, Node.js - without reliance on either to build #33. Closed as