3 ms·
I really liked the concept for this[0] project last year. I now do a similar thing and all of my need-browser-abilities-on-the-desktop projects just require you
by kodablah 10y ago
I really liked the concept for this[0] project last year. I now do a similar thing and all of my need-browser-abilities-on-the-desktop projects just require you also have Chrome installed and I just use "chrome --app". I also get security updates for free! I think it's much more reasonable to run a localhost-only web server and use a browser on the desktop than requiring the browser embed native capabilities directly from JS source (and if you really needed that, you could build some fast IPC). You just need to make sure you sign/auth all of your localhost calls w/ a rotating key to (admittedly only somewhat) prevent other process accessing your webserver. Or someone could just make a chrome plugin that does direct IPC to your backend and no web server needed.
I think the problem is everyone is trying to match the Electron API and the multi-process/IPC hoops. If they would just build it like a localhost-only webapp, they'd get so many benefits including the small app size.
0 - https://github.com/utamaro/neje-ui https://github.com/utamaro/neje-ui
- endergen 10y agoShrinkwrap is basically a local server that hosts a folder of static html/css/js content that is served through an app that is just a full window WebView element. You could use a similar trick of wrapping go code, but instead of assuming Chrome is installed, just host your front end using the native webview. Requires no other installation than your app that way.
- endergen 10y agoOh and regarding your signing requests to ensure other processes can't peak at the server content. I haven't gotten to this, was definitely on the plate, more proving out the approach still. Wrapping various apps and thinking through the issues.