holepunchto / pear

combined Peer-to-Peer (P2P) Runtime, Development & Deployment tool
https://docs.pears.com/
Apache License 2.0
99 stars 9 forks source link

Deno as platform (alternative to BARE) #320

Closed mindplay-dk closed 2 days ago

mindplay-dk commented 3 days ago

Okay, I know this is a somewhat "wild" suggestion, but just hear me out. 😅

Deno 2 was announced and is basically a self-contained JS/TS developer toolchain.

Deno is able to produce stand-alone executables.

Deno has a cross-platform window manager.

Deno has SDL 2 support, including WebGPU and Skia and more.

It does of course have all of the standard stuff like console, buffers, file system, etc. - as well as now also "full" support for Node.js extensions, although I'm sure this still comes with caveats.

It does have Tokio instead of LibUV so it's not a shoe-in, but I have to wonder... wouldn't it be better to build on an existing runtime, rather than purpose-building a dedicated run-time just for PEAR?

Like, that must be a lot of work? 😅

Of course, there are things that PEAR has out of the box that Deno doesn't, like the whole browser based UI. But there are modules like WebUI which enables you to create self-contained apps that launch your system browser to run the UI. As well as bindings for webview, which sounds similar to what you have, with native Linux/Mac/Windows support, etc.

I know, a drastic change like this would also be a lot of work, but it does get you out of maintaining an entire platform for something (P2P networking) that actually has very little to do with all the work you're putting into the desktop application framework.

I'm sure you have your reasons for building an entirely new platform, but I wonder if the key features of PEAR wouldn't do a whole lot better if they were made available to an existing ecosystem, rather than requiring an entirely different, dedicated platform for the UI part. Deno is based on web standards, so these are well known to most of the developer world, without having to learn yet another thing.

And there is access to Node modules, which is the main reason I've been pondering this subject and decided to open this discussion... I actually had an interesting project in mind for trying out PEAR - but I needed a Node package for things like loading/saving and processing images. It can't really be done in the browser UI - I need Sharp for which I already know/have compatible code/extensions. Image processing isn't a feature that BARE has, so the idea dies there.

Of course, this is just one guy with one random idea. 😅

But the point is, when you build on an existing platform, you get access to a wealth of features and knowledge - whereas building on a feature-specific platform like BARE tends to shut you off from both.

It's just a thought, so feel free to ignore me. 😅

I could just see PEAR itself being a whole lot more useful and accessible in a well known context, and I don't imagine that building and maintaining an entire platform is very central to building P2P applications? I could be wrong! 😅

Cheers guys

mafintosh commented 2 days ago

We have 2 guys maintaining Bare. They just finished userland modules 95% of node compat (the parts we care about), made it run on v8, quickjs, javascriptcore, implemented node_api, made it run on desktop/ios/android, and solved esm/cjs compat.

I think we're good. Sometimes the best solution require the least amount of work.