Using pear as a distributed backend for a Nodej.s server

[mattdesl]

For a project I'd like to test, I want the visuals to be run in a browser context (for canvas/webgpu support) but not restricted to pear's Electron GUI system. What I'd like to do instead is start a websocket server in the pear terminal app, and communicate through that. So there might be several clients running across different browsers and devices, and pear is just used as a p2p layer in the backend to sync files.

This seems theoretically doable but because pear is using bare I'd have to re-implement everything from the ground up, including things like a HTTP server that supports websockets. Is there any way to specify node as the backend? Or, a way to install express and ws within a pear environment?

[mafintosh]

See https://github.com/holepunchto/bare-node

[mafintosh]

Next version you can do what that repo says with pear init --node

Note, not full stdlib is covered yet but we are adding as we need it

[mattdesl]

But—does http1 even support ws? What are the odds that something as high level as express would work?

It feels like large swaths of node/npm ecosystem are going to be incompatible with pear & bare.

[mafintosh]

Everything we've used so far works. Our http stack is prop the one with least cov as we only use p2p internally, but i'm sure it'll get there.

[mafintosh]

Any thing you find thats incompat, just open an issue on the relevant repo and someone will look at it eventually or at least say thats in the 5% we dont wanna support for reasons.

[mattdesl]

It seems like a huge undertaking to build a new JS runtime from the ground up instead of allowing developers to use one of the existing ones (node, deno, bun).

This doesn't work in pear for example:

import express from "express";

Because process doesn't exist, it has to be imported manually from bare-process or re-mapped in package.json. But even if it's remapped, that doesn't change the import resolution algorithm for all sub-dependencies (like express and its sub-dependencies) as far as I can tell.

[mafintosh]

Yea we are in it for the long haul.

We are making pear to run apps across desktop, mobile, embedded devices and servers, thats why we made a runtime that supports that 1st class.

This launch focuses on p2p apps, but as the ecosystem grows I'm sure the last parts will be filled out, honestly it's the easy part of the whole thing.

[davidmarkclements]

asked and answered, resolved