Native Messaging example

[guest271314]

#1628

[vados-cosmonic]

Hey @guest271314 thanks for submitting this -- do you mind if I reorganize your PR to fit the pattern we have here in the repo?

For example this will likely consist of:

• changing repo structure, adding folders & renaming files
• moving from bun to node (we don't use bun in examples)
• adding a README in a similar form to the other examples

[guest271314]

As long as you test before changing anything, and test after each change - and share those changes - to verify the exact same output happens as does not.

[guest271314]

If you don't use bun, you probably don't use deno, either. I use deno`, in part, to test hosts outside of the browser on the command line for the 1 MiB or less length messages cases https://github.com/guest271314/NativeMessagingHosts/blob/main/nm_standalone_test.js.

[guest271314]

If you get to changing names of files you MUST test to verify.

The code works fine as is. If nothing needs further explanation I don't see why names of iles needs to be changed or folders moved around, or even whey node is the only JavaScript runtimes used in examples. Let me see what your reorganization looks like - and if it works.

[vados-cosmonic]

Hi @guest271314 the largest issue here is that Jco-as-a-host isn't actually used at all in this example -- what am I missing here?. Given the title of #1628 I thought this would mostly be an example of using stdin/stdout manually in a component at the host level. Am I missing something? Where is the code that actually uses Jco?

It seems like there's a script missing that actually uses wasmtime?

When compiled with jco adjust the file name executed by wasmtime in nm_componentize_js.sh to nm_jco.wasm.

This actually makes me think this example isn't a good fit for Jco after all -- I apologize for asking you to contribute it, this kind of thing is probably better as an external repo showcasing the combination of componentize-{js,qjs} and browser functionality, rather than something in-tree in Jco.

With respect to the component examples -- they employ a consistent format and layout to keep things approachable for people who are new and experienced. It's not really the place to advocate for new runtimes unless we have a very specific reason (Jco should stay compatible though). New and experienced JS developers overwhelmingly still use node and not bun/deno -- a conventional package layout is more familiar.

There's a marked difference between the other READMEs and your README -- I think this example's README is really focused towards a crowd that wants to do this and knows all the relevant information already, and just needs an explanation of the "how" -- that's not really the same shape as the other examples. Ideally the example should be instructive enough able to take a user from start to finish with a hope of understanding the use case and steps involved (with as many of them automated as possible). There's just a lot of "draw the rest of the owl" in your

[guest271314]

From the code I read jco depends entirely on componentize-js to create a component. The WASM output by jco is identical to the WASM output by componentize-js - because jco depends on compoentize-js for the component construction, correct?

I used jco to generate the WAT, and I think the WIT, too.

It's 2026, Bun and Deno are a thing. So are JavaScript runtimes other than Node.js - dozens of them https://gist.github.com/guest271314/bd292fc33e1b30dede0643a283fadc6a.

A user can go from start to finish following the instructions I have in the README, now. I've used the same README style for around 30 different Native Messaging hosts - at least 11, including jco - are WASM type hosts.

All bun is used for is install. deno is used for CLI testing. I can probably re-write those parts out to use only node. Not quite how I would do it, because I'm all about JavaScript as a whole - not just node - but it's your repository.

I mean, even your repository says this

JavaScript toolchain for working with WebAssembly Components

It doesn't say Node.js toolchain for working with WebAssembly Components. Maybe it should if that's all you are really concerned with supporting - instead of the whole of the language.

For some perspective I currently have on my machine node, deno, bun, qjs, tjs, llrt, workerd, shermes, V8's d8, SpiderMonkey's js, JavaScriptCore's jsc, LadyBird's js.

Do the re-write if you want. Like I said though, just make sure you test before and after.

[vados-cosmonic]

From the code I read jco depends entirely on componentize-js to create a component. The WASM output by jco is identical to the WASM output by componentize-js - because jco depends on compoentize-js for the component construction, correct?

Yes, this is true -- but normally that's just a piece of the example, i.e. building the component so we can run it with Jco-the-host, and ensuring the example is as self-contained as we can make it.

It's 2026, Bun and Deno are a thing. So are JavaScript runtimes other than Node.js - dozens of them https://gist.github.com/guest271314/bd292fc33e1b30dede0643a283fadc6a.

Certainly agree here -- my point is what is familiar to most that will happen upon this repo. For example, it's a small thing, but I think having a package.json is so ingrained at this point that it's expected in every example repo.

A user can go from start to finish following the instructions I have in the README, now. I've used the same README style for around 30 different Native Messaging hosts - at least 11, including jco - are WASM type hosts.

Your README is certainly easy to follow and you've done the testing, I'm not debating that -- I'm just saying that we try to be what some might call overly explanatory in examples so people can feel like they have a decent grasp of what's going on/goals/what was accomplished, etc.

All bun is used for is install. deno is used for CLI testing. I can probably re-write those parts out to use only node. Not quite how I would do it, because I'm all about JavaScript as a whole - not just node - but it's your repository.

I'm not saying you have to only use node -- but assuming that bun and/or deno are installed, not explaining them (or how to get them) in the Repo as dependencies, etc is not enough compared to the other examples in the repo.

In a package.json, a target like build:bin:bun or build:bin:deno would have been just fine, along with a build:bin that used what was most likely to be present on the user's system, node/npm. As an example, we use pnpm because of it's superior security stance but almost always include at least one example of npm because that's more common.

I mean, even your repository says this

JavaScript toolchain for working with WebAssembly Components

It doesn't say Node.js toolchain for working with WebAssembly Components. Maybe it should if that's all you are really concerned with supporting - instead of the whole of the language.

Agreed, Jco does aim to work on multiple JS platforms, and we test Deno in-tree. Maybe someday we will also test Bun in-tree -- that would be a welcome addition. I do want to point out that for the WASI shims we are currently only targeting NodeJS builtins -- I don't think we can claim to support Deno/Bun strongly just yet, though it is a goal.

What we should support and what is familiar to the average JS developer are still different questions though!

Do the re-write if you want. Like I said though, just make sure you test before and after.

Thanks -- I'll build on the work you've contributed, and you bring up a good point -- we do need tests here (which we often run from CI to avoid regressions). I think in this case we'd need to include puppeteer to make a reasonable test, and that's something I will try to add, along with support for Firefox extensions as well.

[guest271314]

Ironically one reason I first started using deno and the bun is to get away from having a package.json file involved at all.

I went around a year without npm on my machine at all because a Node.js/NPM maintainer said something like NPM is part of JavaScript.

I then just used deno bundle and bun build. Voila, no node_modules folder, no package.json at all for a year - and still bundled packages from NPM.

I don't think the average user is stumbling into WebAssembly Components.

You're dealing with programmers and hackers playing around with this new component thingy. WIT is changing. There's all kinds of proposals and people jump for joy at WASI 3. It's moving very fast. And you think some "new" user is gonna roll up and understand WIT? I don't think so.

It's pretty simple how to get deno and bun. Simpler than just getting the node executable. In fact I use deno to fetch the Node.js nightly archive and extract only node - and leave the rest.

[guest271314]

cd $HOME/bin
wget --show-progress --progress=bar --output-document deno.zip https://dl.deno.land/canary/$(wget -qO- https://dl.deno.land/canary-latest.txt)/deno-x86_64-unknown-linux-gnu.zip && unzip deno.zip && rm deno.zip
wget --show-progress --progress=bar --output-document bun.zip https://github.com/oven-sh/bun/releases/download/canary/bun-linux-x64-baseline.zip && unzip bun.zip && rm bun.zip && mv bun-linux-x64-baseline/bun $PWD && rmdir bun-linux-x64-baseline
# wget --show-progress --progress=bar --output-document quickjs.zip https://bellard.org/quickjs/binary_releases/quickjs-linux-x86_64-2021-03-27.zip && unzip quickjs.zip && rm quickjs.zip
wget --show-progress --progress=bar --output-document llrt.zip https://github.com/awslabs/llrt/releases/download/v0.8.0-beta/llrt-linux-x64.zip && unzip llrt.zip && rm llrt.zip
wget --show-progress --progress=bar --output-document workerd.gz https://github.com/cloudflare/workerd/releases/download/v1.20260602.1/workerd-linux-64.gz && gzip -d workerd.gz

./deno run -A fetch_node.js
# bash ./fetch_node.js
./deno compile -A --unstable-unsafe-proto  npm:esvu
./esvu --engines=v8,spidermonkey
rm -rf node_modules
rm -rf esvu
./deno clean

cd ~/bin
git clone --recursive https://github.com/saghul/txiki.js --shallow-submodules && cd txiki.js
make 
cp "$PWD/build/tjs" ~/bin

cd ~/bin
rm -rf "$HOME/bin/txiki.js"

wget https://github.com/quickjs-ng/quickjs/releases/latest/download/qjs-wasi.wasm

git clone https://github.com/quickjs-ng/quickjs && cd quickjs
make
cp "$PWD/build/qjs" ~/bin
cp "$PWD/build/qjsc" ~/bin
rm -rf "$HOME/bin/quickjs"

fetch_node.js

[vados-cosmonic]

Ironically one reason I first started using deno and the bun is to get away from having a package.json file involved at all.

I went around a year without npm on my machine at all because a Node.js/NPM maintainer said something like NPM is part of JavaScript.

I certainly agree that JS, NodeJS and NPM are distinct and should be. Disagree with the idea that a package.json (or some kind of project configuration file) should be present, though -- there are good reasons almost every language ecosystem has evolved in this way, and having an explicit way to specify dependencies, packaging information, etc was a major driving force of why server-side JS was well adopted, IMO.

I then just used deno bundle and bun build. Voila, no node_modules folder, no package.json at all for a year - and still bundled packages from NPM.

Building native executables is certainly a great step forward that Node, Deno and Bun all support these days. It's fantastic.

I don't think the average user is stumbling into WebAssembly Components.

You're dealing with programmers and hackers playing around with this new component thingy. WIT is changing. There's all kinds of proposals and people jump for joy at WASI 3. It's moving very fast. And you think some "new" user is gonna roll up and understand WIT? I don't think so.

Well it may seem impossible but that's the goal, at least to get them as close as possible to knowing what's happening/what the tools do and why they're there. In general more senior engineers and tinkerers who come will be fine with an overly explanatory README, but the converse is not true -- early engineers may not be able to work through a README that does not explain enough. This is kind of why I think it's reasonable to lean in the direction of helping new users as much as possible.

[guest271314]

You are not gonna be doing something like deno compile -A npm:npm with node's clunky SEA.

You are not gonna be doing something like bun build with node.

You are not gonna be importing C into node like you can with qjs, tjs, and shermes.

OTOH hand you want all of the things - WebAssembly Component Model everywhere - Rust, C#, Go - but you want to use only one, legacy, though known JavaScript runtime - for the whole of JavaScript that exists far beyond just node?

I would think you'd want folks to be exploring your gear outside of the Node.js world?!...

[guest271314]

In some ways WebAssembly is exploratory. I ain't seeing that here. Tethered to StarlingMonkey that includes HTTP stubs that ain't being used - resulting in a 13.4 MiB WASM file that winds up being 170 MiB in WAT - for a single JavaScript input file?

Might wanna rethink some in-house policy objectives. Or not. I just took your gear for a spin. To compare to similar art. We can build with AssemblyScript then "componentize" with wasm-tools "adapter" after the fact for around 13 less MiB... and still be under 1 MiB https://github.com/guest271314/native-messaging-webassembly/blob/main/nm_assemblyscript_component.wasm. That ain't happening with jco nor the work jco is dependent on, componentize-js. We get an entire JavaScript engine compiled to WASM with WASI-SDK with qjs-wasi.wasm. For around 1.4 MiB https://github.com/quickjs-ng/quickjs/blob/master/.github/workflows/release.yml#L121-L146.

But maybe y'all don't really want unbiased, independent JavaScript hacker opinion from the field on the matter?

I really didn't know this project was Node.js-only focused. The descriptions says "JavaScript"...

[vados-cosmonic]

You are not gonna be doing something like deno compile -A npm:npm with node's clunky SEA.

You are not gonna be doing something like bun build with node.

Great point, the convenience of deno compile and bun build are certainly something NodeJS should aspire to, and are great targets to have in a package.json's scripts section so that people who have those tools can use them!

Smoothing over the difficulty for newcomers is something a good example folder/project should do, even if it takes an extra script or two.

You are not gonna be importing C into node like you can with qjs, tjs, and shermes.

OTOH hand you want all of the things - WebAssembly Component Model everywhere - Rust, C#, Go - but you want to use only one, legacy, though known JavaScript runtime - for the whole of JavaScript that exists far beyond just node?

I would think you'd want folks to be exploring your gear outside of the Node.js world?!...

Well, Rome wasn't built in a day! Like I've mentioned previously, we ensure Deno support via testing, and it would be great to have Bun too. It'd be nice to have Deno and Bun examples, but I think people are trained (currently) to do the conversion in one way (take a node project and use bun/deno with it) rather than the other way.

Regardless, examples that are deno/bun focused need to be very much documented as such since they're not the norm (yet, if ever) -- and at present the repo focuses on NodeJS first but does not preclude other JS runtimes.

In some ways WebAssembly is exploratory. I ain't seeing that here. Tethered to StarlingMonkey that includes HTTP stubs that ain't being used - resulting in a 13.4 MiB WASM file that winds up being 170 MiB in WAT - for a single JavaScript input file?

You're certainly right -- StarlingMonkey is a large runtime and it's clear to those who work on it. SpiderMonkey is a complex, robust and performant JS runtime, and it's hard to get such a runtime squeezed into a very small Wasm footprint. I'm sure there are still gains to be had there.

It is also possible to run starling monkey using dynamic linking at the runtime layer and pass around just the scripts that need to be executed but that's a discussion for another time.

Might wanna rethink some in-house policy objectives. Or not. I just took your gear for a spin. To compare to similar art. We can build with AssemblyScript then "componentize" with wasm-tools "adapter" after the fact for around 13 less MiB... and still be under 1 MiB https://github.com/guest271314/native-messaging-webassembly/blob/main/nm_assemblyscript_component.wasm. That ain't happening with jco nor the work jco is dependent on, componentize-js. We get an entire JavaScript engine compiled to WASM with WASI-SDK with qjs-wasi.wasm. For around 1.4 MiB https://github.com/quickjs-ng/quickjs/blob/master/.github/workflows/release.yml#L121-L146.

But maybe y'all don't really want unbiased, independent JavaScript hacker opinion from the field on the matter?

You're always free to share your opinion -- what you're running up against we already know about and have actually already discussed in weekly meetings which are made public every time we have them. Jco will eventually be a multi guest runtime toolkit. Right now we only support componentize-js, but there is no reason we can't build components with componentize-qjs (as you've already seen is possible) and whatever other guest runtimes come along.

There are many ways to build JS guests and there will be even more in the future. It would be silly to not build for that.

Not only will Jco eventually be multi-guest runtime, it will be multi-host runtime with the same mechanisms. Jco does not claim to have the only good CM + WASI implementations, and that's a great thing -- the Component Model and WASI are interoperable standards that should be widely used, with diversity in implementations and tradeoffs. There are already other very impressive host runtimes and eventually Jco will be refactored to make it easier for those to slot in as well, where possible.

One of Jco's primary goals is to be a useful toolkit for developers building WebAssembly components in the JS ecosystem. Jco should eventually be completely unnecessary (with high quality tools available and integrated upstream), but until then, we will persist in trying to make a beginner-friendly toolkit. For periods of time it may not be the absolute minimal runtime one could build, but it will certainly provide an option!

[guest271314]

Not only will Jco eventually be multi-guest runtime, it will be multi-host runtime with the same mechanisms. Jco does not claim to have the only good CM + WASI implementations, and that's a great thing -- the Component Model and WASI are interoperable standards that should be widely used, with diversity in implementations and tradeoffs. There are already other very impressive host runtimes and eventually Jco will be refactored to make it easier for those to slot in as well, where possible.

One of Jco's primary goals is to be a useful toolkit for developers building WebAssembly components in the JS ecosystem. Jco should eventually be completely unnecessary (with high quality tools available and integrated upstream), but until then, we will persist in trying to make a beginner-friendly toolkit. For periods of time it may not be the absolute minimal runtime one could build, but it will certainly provide an option!

Well, if that's true and correct then this PR should be tested and merged. Done.

This is kind of why I think it's reasonable to lean in the direction of helping new users as much as possible.

I don't know who those "new users" are you are talking about? New to programming, period, and here because they heard the term "Components" or "Component Model" in passing somewhere?

I'm estimating only seasoned programmers - in both JavaScript as a whole and WebAssembly - are winding up here tryin to play with the new fangled, and as yet unproven "component model " thing.

So, what's the deal here? You gonna re-write the code to use only jco references? Remove bun install? Rearrange the file structure, rename files, and merge - leaving only the template you have here already and only talking about node? Or, what?

[tschneidereit]

@guest271314 you've made your feelings on WIT, the Component Model, and any number of other things known quite forcefully, and are now starting to get confrontational. I'll ask you to tone things down and accept that in our projects we can do things the way we prefer, regardless of how you feel about them. (We also can do things the way we think is best, regardless of what you think we "MUST" do, fwiw.)

Victor is very graciously putting a lot of effort into this conversation and offering to do a meaningful amount of work here. Please keep that in mind in how you engage.

[guest271314]

@guest271314 you've made your feelings on WIT, the Component Model, and any number of other things known quite forcefully, and are now starting to get confrontational. I'll ask you to tone things down and accept that in our projects we can do things the way we prefer, regardless of how you feel about them. (We also can do things the way we think is best, regardless of what you think we "MUST" do, fwiw.)

Victor is very graciously putting a lot of effort into this conversation and offering to do a meaningful amount of work here. Please keep that in mind in how you engage.

Yeah. You do you.

I'm not the meek and humble type.

If you want only yes men and women who don't vet your claims and gear, that ain't me.

[tschneidereit]

I'm not the meek and humble type.

This is in abundant evidence, yes.

If you want only yes men and women who don't vet your claims and gear, that ain't me.

Not what I asked for, but if that's how you must read it, then it is what it is. In any case, the warning to mind your tone stands.