4 ms·

Each runtime can be a different electron version and have different combination of npm packages. It's the Wild West, without a standard library and tons of opt

Each runtime can be a different electron version and have different combination of npm packages. It's the Wild West, without a standard library and tons of options for the same problems.

dspillett 9y ago
But if they could at least share the Chrome and Node bulk? They'd still have to have their own copy in their address-space so you'll not save RAM but you might save a chunk of disk space (handy when working on a tablet or small laptop with a small eMMC drive) and download time. Of course versioning will be an issue so you might still need multiple versions for compatibility reasons. You might need a copy of 1.6.16, 1.6.17, 1.8.0, 1.8.2, and 2.0.0 to server your collection of apps. How to solve that problem would require some thought. When a user starts an app, if the version it is built against (or one it is otherwise marked as compatible with) isn't present do you warn the user and refuse to run, warn the user but run with the next best thing as it might just work, or automatically kick off a download? For systems where people are used to having a package manager this can be relatively transparent (apt install myElectronApp, pulls a versioned electron package if needed at the same time) but less so on Windows. Perhaps it would be to complex (so potentially bug ridden) for the savings involved. Filesystem block-level deduplication might help the space issue, though not the download issue.