Hacker News Reader

Comment by kethinov | Hacker News Reader

Building a shared runtime for Electron so that each Electron app no longer needs to bundle Node.js and Chromium. It would significantly improve the performance of a framework now used by countless apps. So far as I can tell, this has been on the back burner of the Electron team for many years. I'm surprised it's not a higher priority.

View on HN

This already exists: the browser is the shared runtime. What needs to happen is everyone shipping Electron should instead ship a local HTTP server and open the user's default browser to run the UI. You can hide the browser chrome and make real top level windows by making your app a PWA. Anything else that needs to happen outside of the browser sandbox can be handled by the local server.

The only disadvantage is you lose control over the browser version that's running, but you also lose that with a shared runtime (unless every app pins their own runtime version which defeats the purpose of sharing). Besides, most Electron apps also have a web version that has to support all browsers anyway. The advantage is you seriously reduce the disk and memory footprint of your app and shed the responsibility of shipping prompt patches for Chromium security issues.

> should instead just ship a local HTTP server

and a Node.JS runtime, and native libraries to support menubars, system trays, dialogs that support folder selections, native drag and drop for all file types, ...

I agree, though: if the electron app doesn't need any of these things, it really shouldn't pull in the entire electron runtime.

Node is a lot smaller than Chromium. Even if the app does want some of the other things you list, it's possible to do all of them from the server, and it'll remain a fraction of the size of Electron.

yeah just use Chromium as the GUI interface and do everything else in node. Come on! Someone goto have alredy done this, no?

With a local server, how do you avoid Windows's scary confusing firewall prompts? I'm sure they cost users, and for a local app they don't make sense. Is there a way to make your server local-only that will prevent them?

You can bind to the loopback interface so the server isn't exposed to the network. I am not sure if Windows will choose to show the scary dialog in this case. To be absolutely sure, according to Stack Overflow you can request admin privileges (standard for Windows installers of course) and add a firewall rule yourself allowing any network communication you want.

We are losing Chrome Apps.

And then you need to have everyone install the runtime. And update it.

And we're back in Java-land, but with HTML instead of Swing :-)

It's nice from a developer point of view but I wonder how many application creators/vendors will actually use it. Most want to control as much of the stack as possible.

The webview project fills some of this need, correct? I didn't start using one yet but there were multiple GUI projects leveraging it to create cross-platform application binaries.

Link - https://github.com/webview/webview

Unless something has changed, using that means no Webassembly support on Windows[0].

[0]https://github.com/webview/webview/issues/76

For now, hopefully: https://github.com/webview/webview/issues/85

Here's the 6-year-old issue about a shared runtime for Electron:

Idea of runtime mode - https://github.com/electron/electron/issues/673

Earlier discussion on this Topic : https://news.ycombinator.com/item?id=19083169

Couldn't that just be made with a browser that would allow to be run in a runtime mode with limited features?

What electron apps can’t be done as chrome pages with local file system access?

Reply on news.ycombinator.com