Hacker News Reader

Comment by kethinov | Hacker News Reader

Does anyone know if the idea of creating a runtime mode for Electron is on the roadmap? (A runtime mode would be allowing multiple apps to share one installed Electron dependency rather than bundling Electron with every Electron app.)

View on HN

Then you get into the issue of keeping apps and runtime in sync so you don't get issues with older apps not working well with a new version of the runtime required by newer apps...

You end-up having to keep multiple runtimes and hoping they don't step on each-other's toes...

After a while you're still downloading 200+MB runtimes to run your particular app that still requires Runtime 5.05 and hasn't been updated to work with Runtime 6.12 that is required for newer updates of an app that used to work with Runtime 5.84...

Maybe a better idea would be to make Electron's install specific to each app and only include the bits you actually need so it's a 30MB bundle instead?

Just wondering if calling for a runtime isn't going to make things worse in the long run. It 's already often a pain to install an app that target any framework version in particular that may not be installed or may conflict on some user's target machines. Sometimes it's unavoidable, but I'm wondering if this is really the case here.

Fully agree. I've thought about that and the only solution I came up was to only update all your electrons apps at the same time and they would share the minimal electron runtime's version possible. Would also require electron-apps developers to provide all versions of their app (with the runtime version information)

Agree. I think the solution is to make the runtime a lot smaller to the point where download each time becomes a non-issues.

Which isn't really PWA because Electron do offer slightly more capabilities.

What ends up happening is that without a shared runtime, now each user is responsible for ensuring he has the latest security fixes in every single of his apps' bundled runtimes, which is much harder to ensure than with a shared runtime.

The users have to track the releases of electron themselves and keep on top of security bugs.

While it may be easier for devs to bundle, it's a major loss and a huge risk to users. Probably much more with non-major apps, where the developer may not care all that much to update bundled runtimes, when he's not adding features to the app itself.

Did you check none of the apps you use are vulnerable to this?[1] Now until every single developer and every single electron app in existence updates their runtimes, they'll be potentially vulnerable to this major privilege escalation bug.

[1] https://electronjs.org/blog/window-open-fix

easy. you just add sth like elsched.exe that keeps checking for updates in the runtime, then opens a popup saying "Electron Update Available".

Then the Electron Runtime is updated but breaking the particular App that was relying on a feature that has changed since its publication. The problem is not updating the Runtime, it's ensuring that the apps relying on the runtime still work properly after feature updates in the runtime.

Yes, that would be very useful to have. Some runtime, or some central application, so that the user just has to download some HTML, CSS and Javascript -- not a complete copy of Electron each time. And if this application could be used to browse the internet when the user enters a URL, that would be useful too! Game changer!

Yes great idea! The different applications (or URLs) could be opened simultaneously and displayed as ‘tabs’ for the user to manage in the central application.

That would also allow to call one application from another, just assigning some reserved namespace or domain and appending the feature at the end, kind of a path. Exciting times!

How would one remember a collection of these namespaces or the current place within one location? Analogous to physical paper, could we repurpose the concept of a "bookmark"?

To avoid having to update these files on your pc, these could be served by a "server" on the internet. We would have to run cables around the earth so everyone can benefit.

First thing we'd have to serve then is some place where stuff like that can be discussed though, maybe some sort of "forum" with "comments" and stuff?

Unfortunately, that would also introduce latency. Plus, I'd like to be able to access these files when I'm not connected to one of these "servers".

You probably don't need electron to do that, it could be done by any end user. Wondering why it isn't being done!

I get the joke, but an Electron "player" daemon seems like a decent idea. It could manage getting the right runtime versions, installing apps, deduping assets and granting permissions.

It'd be a sort of cross-platform Google Play Services.

Oh, you're too brutal to the webdev community. Don't do that. :D

Everyone likes this idea until the HTML, CSS, and JS are given the ability to change application menus and access the file system. Then oh no, we can't have that.

Surely you can fix that without having physically separate copies of the underlying chromium engine?

edit: I realize now this is a joke thread... whoosh.

It's funny because it's not entirely a joke.

Instead we are encouraging users to download arbitrary binaries bundled with a browser that can be controlled and updated remotely. It’s not clear to me this is any safer.

Java-based GUI applications have been moving from the system's JVM to bundling one due to longstanding and seemingly unfixable reliability and ease of use problems. Why will Electron be different?

Java applications can compile to native code and remove needless bloat via linking.

So when is Electron going to support the same features?

I have not once seen a Java application that shipped as a native binary. Sure, it can be done, but this is a very rare experience practice.

I have seen plenty on the enterprise, done by companies that actually pay for their tools, or do deployments into embedded targets.

Also Android J++ does AOT compilation, as sidenote.

Now that OpenJDK is starting to offer AOT compilation for free, maybe there will be more adoption among FOSS crowd.

The right way to design it would be to allow apps to declare an allowed range of Electron dependency in package.json.

For instance, if my app depends on Electron 5.x, then it will only run if 5.x is installed. If other apps require 4.x, then a system needs to be in place to allow both 4.x and 5.x to be installed on the system simultaneously.

This way if—say—you have five Electron apps running on your system, three of them require Electron 5.x, and two of them require Electron 4.x, then you only need two versions of Electron installed to your system instead of today's approach of bundling one with each app.

Honestly not sure why Java doesn't work this way too. I think .NET does, doesn't it?

Post: Tries very hard to avoid any use of the word roadmap

First comment: Hey is X on the roadmap?

You can use Chrome + NodeJS as the shared runtime instead of Electron, using an approach such as this: https://github.com/GoogleChromeLabs/carlo

You still need to bundle a copy of NodeJS with your app if you're not targeting developers, but that's much smaller.

Of course, this still has many of the issues that a shared copy of Electron will have - you need to make sure that your app stays compatible as Chrome is updated. The HTML/JS side is typically not an issue, but the devtools protocol that you need for this does get breaking changes now and then.

I think MS fully intends to have something like Electron available for apps to use as a target on Windows. They are desperate to make things easy as possible so devs of consumer apps don't abandon the platform or just make general performance worse by targeting standalone Electron.

macOS is experimenting with UIKit, so we'll see how that plays out. But I wouldn't be completely surprised a few years from now if they announced a Safari-based competitor to Electron that has obvious benefits, like battery life and GPU acceleration everywhere.

I think it would be nice to see this happen, it could be what Adobe's Air platform was supposed to be... I would think that MS could do it relatively easily.

The biggest risk, however are those modules that are compiled to the platform and node version in question. There are now some abstractions that make this easier, but it's still far from perfect. And depending on the application there are more or fewer risks of this being a problem.

As it stands SQLite is specifically one of the most used compiled modules alone and is used in many projects.

Currently not on the roadmap – for what it's worth, the majority of apps perform their Electron updates at different times, so you'd still have the same number of binaries and files as you do today.

There's always Carlo[1] as an alternative.

https://github.com/GoogleChromeLabs/carlo

We once had such a thing. It was called Java. But it's a thing of the past.

I'm unsure if chromium is designed in a way to allow for this safely.

Or just build local permissions into web browsers and download 200KB of HTML and JavaScript instead of 200MB for an electronic install.

Cough, PWA.

https://docs.microsoft.com/de-de/microsoft-edge/progressive-...

Probably OK for some uses, like when you publish as a web app anyway, but for others it burdens you with keeping up with the aggressive release cycle of browsers.

Luckily web browsers take care to "never break the web" and remain backwards-compatible, so that should not be that much work.

I love your sarcastic response.

Favorite recent example, Chrome's audio blocking solution pretty much broke every HTML5 game in existence. 1000s of sites are still broken. To just name some easy categories, every Pico-8 game exported to HTML5, Every Unity and Unreal game exported to HTML5. Even 100s of Google's own Doodles, examples, promotions, etc ... until they pre-whitelisted every domain they own.

The worst is Apple. Trying to do anything game related in a webpage on iOS Safari is a nightmare and is pretty much guaranteed to break with each new iOS release. "minimal-ui" (nope, took that way), "user-scalable" (worked but they keep changing the conditions so old games break and have to reverse engineer under what conditions it's respected). I recently noticed one of my sites broke for audio. No errors, no mention of what changed that I can fine, worked 6 months ago, stopped working, Safari only. Note it's a site about audio and it doesn't start that audio until the user clicks the "Play" button. It's using the "resume" api but no sound comes out. Still works in Firefox and Chrome (after having to update it last year for Chrome's breaking change)

You're right that there's some risk - especially using API's that can also be abused. However, percentage-wise, the vast majority of works targeting browsers continue to work unmodified (at least in terms of interacting with the browser), making it a very stable platform and definitely not breaking as often and as likely as implied by the words "aggressive release cycle".

That said, it's definitely not yet feature-rich enough to fully displace Electron.

Other than VSCode I don't have any other Electron based on my computers, hardly anything to displace.

Give it a couple of years and Electron would be as common as MSHTML, HTA, XUL apps.

I didn't see any sarcasm tags on your comment, so I'll take it at face value and disagree. Two quick examples:

Google Chrome went from proposing a new WebAudio method called "start" to deprecating and removing the "noteGrainOn" method it renamed in the span of 12 months. Any sites using the original spec stopped working, some within a year of being released with the latest and greatest spec, one of which was Google's "WebAudio Playground" demonstration site. (There's a fun bug on file where that team had the browser team push back the method deprecation by a release so that they could fix that one website).

Google released Polymer in 2015 or so. Apps written using the latest version of that in late 2015 stopped working at some point in 2017 on Google Chrome.

Web browsers stopped being even a little bit backwards compatible around 10 years ago.

Gah, Polymer. Glad to hear I'm not the only one bitten by that...

(Did a single site with it, worked for a year and then for 6 months only in Safari/Firefox, and then we ported it to sit atop another Google project... ¯\_(ツ)_/¯ )

That's because it was not sarcastic.

You are right, of course: if you use new proposals that have not yet been standardised, you are at risk of them breaking in the future. (I've been bitten by this at a previous employer that insisted on using Polymer as well. Don't get me started on that.)

When you stick to standardised features with multiple implementations, though, I think in the vast majority of cases you would've been fine. (This is also one reason why I was against using Polymer.)

(Obviously this does not cover all Electron features, which is why I don't consider browsers to be a replacement for Electron, at this point. I'm merely stating that it's very much possible to target browsers without having to concern yourself much with their rapid pace of development.)

Agree, but it isn't like OSes also don't change their API space or behaviors.

Unless one only cares about fossilized UNIX and Win32.

> Agree, but it isn't like OSes also don't change their API space or behaviors.

They change, but more slowly with better backward compatibility, but more important is when they change. In a corporate environment they might update the OS once a decade and on a schedule you control which is much more manageable than relying on a layer that updates itself every 6 weeks.

> Unless one only cares about fossilized UNIX and Win32.

You say that like stability is a bad thing.

Stability is good, but not when it becomes an obstacle for advancing the state of art in OS development, as many cling to the ways of yore and we get CLI apps with coloured terminals as improvement or WinForms database frontends in bigger screens.

Do PWAs allow you to do things like modify application menus, access the file system etc?

If you bothered to read the link I posted, you would see that PWAs are native apps in UWP with full access to the same APIs as .NET and C++ have, if distributed via the store.

Same applies to PWAs on ChromeOS (naturally given its nature), and Google is ramping up the same capabilities on Android with their initial release of TWA.

Yep, there are a few OSes currently left out, it is up to their masters to follow Microsoft and Google's footsteps.

So you're proposing a solution which works on only Windows and ChromeOS (considering desktop OS only), and has to be distributed via a proprietary store (which in all likelihood might take a cut of my revenues), as a replacement for something that works on Win, Linux, and MacOS, and does not require that I lock myself into an unfavorable distribution method?

I am, because I already have a browser, don't need an additional 300 MB copy per app.

It is only a matter of time until all desktop and mobile OSes that matter fully support it.

Also there is Qt, wxWidgets, JavaFX, ....

AFAIK there's no such lock-in in PWAs, even if the app stores are probably going to be the most important venues for their distribution. PWA is a web app that gets more 'app-like' progressively when you need it to. You can use it like any other web application in your browser, but if it's okay to you, it can store data (and cache it's own assets) to your machine, start in it's own window from a launcher, use the filesystem and so on. Many web apps already have this sort of behaviors when you create a home screen launcher for them from your browser.

Per the parent comment I was responding to, PWAs will only have full access to native APIs if they are distributed via the store. And without access to native APIs things like window management, menus etc. become impossible to customize.

This won't meet requirements either. Desktop apps require full system access. Either they get that, or it's another API that'll be deprecated sooner than later.

Reply on news.ycombinator.com