Hacker News Reader

Comment by endergen | Hacker News Reader

I'v been experimenting with trying to make a smaller Electron like Javascript application wrapper. It's called Shrinkray, and only adds 60K of overhead to the size of the app. See: https://github.com/francoislaberge/shrinkray

It is macOS only (for now). I haven't measured if it is more performant when in the background, but I will. It'seems certainly way smaller in disk size, but comes with tradeoffs in API/functionality.

View on HN

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

Shrinkwrap 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.

Oh 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.

Another cross platform alternative: https://nodekit.io/

Great idea. Are you using WebKit's WebView?

I'm guessing no Node or any other API to interact with the OS (file system, etc), right?

This is exactly it. This is the trade off for smaller size. You could do this approach with node.js as the backend.

There are no APIs like file APIs, those would be the first APIs to add for sure.

I've wanted to play around with something like a golang "main" process and using the systems built-in web view. The final app would be much smaller in size and probably better on the end user's hardware.

But, like you said, it comes with its own set of downsides

Is there any difference in memory/battery footprint? I imagine that "problem" would still exists, because it's using Chrome underneath. Decreasing build sizes is a great improvement though!

Seeing that it's macOS only for now, it's probably using WKWebView underneath (same as Safari) which is considerably easier on resources than Chromium is.

A web wrapper that uses the system's resident web renderer would be a wonderful alternative to electron. A Linux build could also use WebKit, and perhaps the Windows version could be based on Edge.

This is exactly what it does, wraps WebView. I don't do much Windows desktop programming these days, never have for Linux. I assume there are similar built in webviews that can be used for them too.

There is already an OSS project that attempts to do this - a wrapper around the system native browser for all platforms. See https://nodekit.io/.

Are you planing to add Linux and Windows builds?

Definitely makes sense to. Wanted to make more progress and play with APIs before going wider on platform support.

WRT to windows 8 and 10 (that is no windows 7 or earlier) this is essentially a windows store app when written using html, css, js instead of c#. It does have a more limited api than a conventional desktop app since it is sandboxed, but using portable class libraries and the provided api you can get file access and even sqlite with a bit of wrangling.

Why is the Mini Paint icon the icon of the minigun from San Andreas?

I'm not sure, I just wrapped the project: https://github.com/viliusle/miniPaint

Reply on news.ycombinator.com