5 ms·

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 s

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

butz 9y ago
Are you planing to add Linux and Windows builds?
- endergen 9y ago
  Definitely makes sense to. Wanted to make more progress and play with APIs before going wider on platform support.
- crieff 9y ago
  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.
hiphipjorge 9y ago
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!
- kitsunesoba 9y ago
  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.
  - endergen 9y ago
    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.
  - lenkite 9y ago
    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/ https://nodekit.io/.
pier25 9y ago
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?
- endergen 9y ago
  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.
mikewhy 9y ago
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
andoon 9y ago
Why is the Mini Paint icon the icon of the minigun from San Andreas?
- endergen 9y ago
  I'm not sure, I just wrapped the project: https://github.com/viliusle/miniPaint https://github.com/viliusle/miniPaint
kodablah 9y 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 9y ago
  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.
- endergen 9y ago
  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.
lenkite 9y ago
Another cross platform alternative: https://nodekit.io/ https://nodekit.io/

butz 9y ago

Are you planing to add Linux and Windows builds?

endergen 9y ago
Definitely makes sense to. Wanted to make more progress and play with APIs before going wider on platform support.
crieff 9y ago
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.

hiphipjorge 9y ago

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!

kitsunesoba 9y ago
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.
- endergen 9y ago
  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.
- lenkite 9y ago
  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/ https://nodekit.io/.

pier25 9y ago

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?

endergen 9y ago
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.

mikewhy 9y ago

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

andoon 9y ago

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

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

kodablah 9y 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 9y ago
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.
endergen 9y ago
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.

lenkite 9y ago

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