The plan is to implement Node-compatible modules directly in Electrino.
I made stubs for "path", "url", "process" so that the Electron Hello World can be loaded. Doing "fs" next seems like a good idea, but I'd like to have a real-world app to test it against to see which APIs actually get hit (rather than just reimplementing all of "fs").
It seems like the trouble with this approach is that you have to not only build up adequate Electron compatibility but you also need to build up Node compatibility, which seems to me to be a bigger deal. One of the huge benefits to Electron is the ability to use any of the modules from npm.
I can see how the architecture is greatly simplified, and I can still imagine using something like this... but giving up npm is a lot.
Yes, the backend provided by Node needs to be reimplemented using the native JS bridge APIs. Whether this is realistic or not will depend on how much the typical Electron app actually makes use of Node -- I just don't know, honestly. If it's mostly "fs" and a bunch of the other OS-wrapper APIs, it's not insurmountable.
Re: npm, you can of course still use an npm-based workflow for the browser-side part of the app (Webpack, whatever). It's just the Node-side services that are missing.
Ideally developers would have a spectrum of choice: all native libraries (Electrino), native browser + Node (your suggestion), Chromium + Node (Electron). They could then pick what works best for the scale of the project.
I made stubs for "path", "url", "process" so that the Electron Hello World can be loaded. Doing "fs" next seems like a good idea, but I'd like to have a real-world app to test it against to see which APIs actually get hit (rather than just reimplementing all of "fs").