4 ms·

There's a lot of buzz lately about flash player being retired. Why couldn't Electron copy its approach? Install a single runtime and run all your apps on it (li

There's a lot of buzz lately about flash player being retired. Why couldn't Electron copy its approach? Install a single runtime and run all your apps on it (like Archlinux already does, btw); problem solved. It's pretty much how the JVM or .NET have worked for decades. I understand people don't care about supporting multiple version of the runtime, but there should be a way to reduce the cruft of multiple bundled Chromiums on systems that might have storage constraints (thanks Apple and soldered SSDs)

masklinn 6y ago
> There's a lot of buzz lately about flash player being retired. Why couldn't Electron copy its approach? Certainly can't work on mobile platforms where everything is sandboxed.
- nicoburns 6y ago
  Electron doesn't run on mobile platforms anyway.
  - VoxPelli 6y ago
    There are Electron like tools for mobile platforms though
    - nicoburns 6y ago
      True, but most of them already share the runtime, partly because iOS doesn't let you do it any other way if you want JITed JavaScript.
alexhutcheson 6y ago
The JVM world is moving away from that approach. The current recommendation is to use jlink[1] to build a custom runtime image, which doesn’t depend on a JRE being present on the system.
- paulryanrogers 6y ago
  Which is kind of strange since the language maintains backward compatibility to version 1.0.
VoxPelli 6y ago
You are describing desktop PWA:s here, the “runtime” is the browser :) Chrome already supports it. You can install eg Twitter or GitHub Codespaces locally and they will appear as apps on your desktop system.
- sonotmyname 6y ago
  > Chrome already supports it. Chrome supports it on windows.
  - VoxPelli 6y ago
    I myself have only used it on MacOS, Chrome OS (and Android), so supported in most places?
mceachen 6y ago
Unfortunately, node modules with native components must be compiled to a specific version of Electron. This non-portability throws a monkey wrench into any "single runtime" approach (you'd need an electron runtime installed for every unique nAPI version).
- qalmakka 6y ago
  How convenient nowadays every JS environment supports a platform-independent way to run native code (WASM). I think it could solve the issue nicely, if anyone tried to put in the effort to adapt Electron and tooling around it.
  - mceachen 6y ago
    FWIW I've found WASM to be 2-4x slower than native-compiled binaries (especially with large memory copy ops, like with image codecs). (don't get me wrong: this is a wonderful technical feat, but it still is a substantial tradeoff from a native binary).

masklinn 6y ago

> There's a lot of buzz lately about flash player being retired. Why couldn't Electron copy its approach? Certainly can't work on mobile platforms where everything is sandboxed.

nicoburns 6y ago
Electron doesn't run on mobile platforms anyway.
- VoxPelli 6y ago
  There are Electron like tools for mobile platforms though
  - nicoburns 6y ago
    True, but most of them already share the runtime, partly because iOS doesn't let you do it any other way if you want JITed JavaScript.

alexhutcheson 6y ago

The JVM world is moving away from that approach. The current recommendation is to use jlink[1] to build a custom runtime image, which doesn’t depend on a JRE being present on the system.

paulryanrogers 6y ago
Which is kind of strange since the language maintains backward compatibility to version 1.0.

VoxPelli 6y ago

You are describing desktop PWA:s here, the “runtime” is the browser :) Chrome already supports it. You can install eg Twitter or GitHub Codespaces locally and they will appear as apps on your desktop system.

sonotmyname 6y ago
> Chrome already supports it. Chrome supports it on windows.
- VoxPelli 6y ago
  I myself have only used it on MacOS, Chrome OS (and Android), so supported in most places?

mceachen 6y ago

Unfortunately, node modules with native components must be compiled to a specific version of Electron. This non-portability throws a monkey wrench into any "single runtime" approach (you'd need an electron runtime installed for every unique nAPI version).

qalmakka 6y ago
How convenient nowadays every JS environment supports a platform-independent way to run native code (WASM). I think it could solve the issue nicely, if anyone tried to put in the effort to adapt Electron and tooling around it.
- mceachen 6y ago
  FWIW I've found WASM to be 2-4x slower than native-compiled binaries (especially with large memory copy ops, like with image codecs). (don't get me wrong: this is a wonderful technical feat, but it still is a substantial tradeoff from a native binary).