3 ms·

Stupid question: instead of embedding an entire browser in each-and-every app and trying to keep that secure, why not package the native desktop framework as a

Stupid question: instead of embedding an entire browser in each-and-every app and trying to keep that secure, why not package the native desktop framework as a shared, versioned component and the app as a tiny thing that depends on it?

bityard 7y ago
Not a stupid question. This is exactly how operating systems and application SDKs were always developed and deployed until fairly recently.
- thrower123 7y ago
  It worked quite well, until software release cycles got stupidly short. It was always a pain in the ass to have to install the Visual C++ runtime, but there were only so many versions of it. These days you have people linking a hundred DLLs that release new versions monthly, sometimes weekly.
bengl 7y ago
Google's Carlo sort of does that. It uses your system's already-installed Chrome instead of packaging another one. https://github.com/GoogleChromeLabs/carlo https://github.com/GoogleChromeLabs/carlo
mrits 7y ago
Single binary is becoming more common even for runtime apps (JVM,.NET). The reason I wouldn't want Electron to be shared across apps is I don't want a system wide install and certainly don't want to deal runtime version type issues. Electron would start having to be backward compatible for years.
api 7y ago
That's sane. Sanity is prohibited in the realm of UI programming. There's apparently a law somewhere that states that all GUI libraries and APIs must be one of: platform-specific, bloated/slow, or incomplete/ugly.
- fiddlerwoaroof 7y ago
  Lazarus and LispWorks CAPI are exceptions to this rule, but they both use languages people don’t want to learn and CAPI is proprietary
simias 7y ago
I'm generally pretty old school when it comes to development practices but I can totally understand how appealing it is to effectively ship your entire environment as part of your application instead of relying on shared dependencies. Dealing with dependency incompatibility is a huge maintenance burden in my experience, and it's super tricky to debug if you don't have access to the problematic environment (which is most of the time if you deal with public projects). That's why I really try to get into docker for instance, sure good old unix sysadmin and configure scripts might arguably be more elegant and efficient but it's a huge pain to maintain and can (and eventually will) break out the blue after a system update because of a regression in some obscure library. Meanwhile docker images should work mostly everywhere without any effort and you only update your dependencies when you want to update them. So now that storage is cheap and RAM is plentiful I think shipping the dependencies as part of the executable is a reasonable approach most of the time. The problem with electron is that the dependencies involve a full web browser and half a trillion libraries. That's the insane part. I have full python virtual envs for non-trivial apps that are a fraction of the footprint of an electron hello world. It's the core technology that's broken, not the packaging.
- derefr 7y ago
  I think the grandparent comment is envisioning something more like Docker than like e.g. the JRE. This is actually already how the Microsoft Visual Studio C Runtime (aka MSVCRT) is distributed: each application embeds or streaming-downloads the exact [ABI] version of the runtime it needs, but only one of each exact [ABI] version of the runtime needs to exist per system, and each of those runtimes can be upgraded by the OS to resolve security problems (while never altering the ABI guarantees that version distribution makes.) As such, a runtime built this way is a lot like a base layer in a Docker image: it’s a static dependency of the app, installed during the app’s installation, and held in a pseudo content-addressable store that deduplicates it from other apps’ demands for the same dependency.
  - NullPrefix 7y ago
    >each application embeds or streaming-downloads the exact [ABI] version of the runtime it needs Except when they don't. Took me way too long to accidentally install the right redist to have fn-key OSD (volume up, mute, airplane mode, et cetera) on my ThinkPad. Because why bundle it with the drivers? No error messages either. Just mash the buttons and have no visual feedback.
efdee 7y ago
The appealing thing about Electron was that it shipped a particular version of a particular browser brand, combined with a particular version of a Javascript engine. Knowing exactly what browser version you're developing for gives you a lot of freedom that you'd lack when having to support different ones.

bityard 7y ago

Not a stupid question. This is exactly how operating systems and application SDKs were always developed and deployed until fairly recently.

thrower123 7y ago
It worked quite well, until software release cycles got stupidly short. It was always a pain in the ass to have to install the Visual C++ runtime, but there were only so many versions of it. These days you have people linking a hundred DLLs that release new versions monthly, sometimes weekly.

bengl 7y ago

Google's Carlo sort of does that. It uses your system's already-installed Chrome instead of packaging another one. https://github.com/GoogleChromeLabs/carlo https://github.com/GoogleChromeLabs/carlo

mrits 7y ago

Single binary is becoming more common even for runtime apps (JVM,.NET). The reason I wouldn't want Electron to be shared across apps is I don't want a system wide install and certainly don't want to deal runtime version type issues. Electron would start having to be backward compatible for years.

api 7y ago

That's sane. Sanity is prohibited in the realm of UI programming. There's apparently a law somewhere that states that all GUI libraries and APIs must be one of: platform-specific, bloated/slow, or incomplete/ugly.

fiddlerwoaroof 7y ago
Lazarus and LispWorks CAPI are exceptions to this rule, but they both use languages people don’t want to learn and CAPI is proprietary

simias 7y ago

I'm generally pretty old school when it comes to development practices but I can totally understand how appealing it is to effectively ship your entire environment as part of your application instead of relying on shared dependencies. Dealing with dependency incompatibility is a huge maintenance burden in my experience, and it's super tricky to debug if you don't have access to the problematic environment (which is most of the time if you deal with public projects). That's why I really try to get into docker for instance, sure good old unix sysadmin and configure scripts might arguably be more elegant and efficient but it's a huge pain to maintain and can (and eventually will) break out the blue after a system update because of a regression in some obscure library. Meanwhile docker images should work mostly everywhere without any effort and you only update your dependencies when you want to update them. So now that storage is cheap and RAM is plentiful I think shipping the dependencies as part of the executable is a reasonable approach most of the time. The problem with electron is that the dependencies involve a full web browser and half a trillion libraries. That's the insane part. I have full python virtual envs for non-trivial apps that are a fraction of the footprint of an electron hello world. It's the core technology that's broken, not the packaging.

derefr 7y ago
I think the grandparent comment is envisioning something more like Docker than like e.g. the JRE. This is actually already how the Microsoft Visual Studio C Runtime (aka MSVCRT) is distributed: each application embeds or streaming-downloads the exact [ABI] version of the runtime it needs, but only one of each exact [ABI] version of the runtime needs to exist per system, and each of those runtimes can be upgraded by the OS to resolve security problems (while never altering the ABI guarantees that version distribution makes.) As such, a runtime built this way is a lot like a base layer in a Docker image: it’s a static dependency of the app, installed during the app’s installation, and held in a pseudo content-addressable store that deduplicates it from other apps’ demands for the same dependency.
- NullPrefix 7y ago
  >each application embeds or streaming-downloads the exact [ABI] version of the runtime it needs Except when they don't. Took me way too long to accidentally install the right redist to have fn-key OSD (volume up, mute, airplane mode, et cetera) on my ThinkPad. Because why bundle it with the drivers? No error messages either. Just mash the buttons and have no visual feedback.

efdee 7y ago

The appealing thing about Electron was that it shipped a particular version of a particular browser brand, combined with a particular version of a Javascript engine. Knowing exactly what browser version you're developing for gives you a lot of freedom that you'd lack when having to support different ones.