Nativefier: Support "shared runtime" mode, bundling apps as pure configuration

Created on 21 Apr 2017  Â·  7Comments  Â·  Source: jiahaog/nativefier

This is a proper issue for https://github.com/jiahaog/nativefier/issues/184#issuecomment-214967131 by @deksden. Re-phrasing them,

A nativefier app is a URL + options (and maybe some --injected resources), all specified to the CLI at
packaging time. So rather than spit the whole electron runtime in each app, we could have only one instance of the shared runtime, and use it to launch the apps, which would become thin launchers calling the shared runtime with their configuration as params.

  • Benefits:

    1. Letting the OS share memory across Electron instances

    2. Reduce disk space usage

  • Drawbacks:

    1. Differs a lot from existing behavior, and goes against the desire for packaging "as statically as possible" that some some users are wishing for, e.g. https://github.com/jiahaog/nativefier/issues/342 .

      → Should be an option.

    2. We'd have nativefier running in two very different modes (the initial "one-folder-per-app" builds, OR the new "1 common-runtime + N thin app-as-settings" mode).

      → Use cases explosion, need for more tests.

    3. Means doing in Nativefier platform-specific work that we're currently avoiding as we're just shipping the bare output of electron-packager.

feature-request

Most helpful comment

All 7 comments

Are there any updates on this issue?

I currently have 6 web applications I use daily, eating up most of my memory available..

This is also the premise behind WebCatalog, would love it if Nativefier had an option to define a shared runtime though, since it's a much more powerful and stable tool

Webcatalog is now deprecated for other OS than OSX..

But you can use electron /path/to/nativefied-app/resources/app to run a nativefied app using a globally installed electron runtime. Only injected css doesn't seem to work, probably because of wrong relative paths (look for INJECT_CSS_PATH if you want to debug this).

I've made a wrapper script to do this: lean-nativefier.sh

Any reason why we couldn't create a fully "clickable" app that would launch/run the electron /path/to/resources command? This feels trivial...

So, with a little experimentation, I created an Automator based (macOS) app that will launch electron with the bundled app/ directory.

Essentially, create your Nativefier app the way you normally would, right click on the resulting .app, go into Contents/Resources/ and copy the app/ directory into the Contents/Resources/ directory in this app.

Assuming you have electron installed in either /usr/bin or /usr/local/bin, it should launch. Leaves me with an app about 4MB in size.

The only two things that don't work are for some reason the app name in the menu bar still says Electron (I poked around a lot, couldn't figure out why it wasn't honoring the Nativefier configuration json files) and the app Icon. It's a step in _a_ direction. Not quite enough for me to switch to it, but the proof of concept is there, and if someone could help me figure out or tell me why electron isn't respecting the config files, we'd basically be there.

Attaching a screenshot of the AppleScript app (and the workflow itself) in case you don't trust some random guy on the internet giving you an unsigned app to run 😂.

image

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jasonivers picture jasonivers  Â·  4Comments

StyxOfDynamite picture StyxOfDynamite  Â·  4Comments

raulcraveiro picture raulcraveiro  Â·  4Comments

ranzou06 picture ranzou06  Â·  3Comments

Waitsnake picture Waitsnake  Â·  5Comments