Hacker News Reader

Comment by ksec | Hacker News Reader

Yes and I thought it make sense. Do people not just use Electron App on Desktop? I mean the App would be packaged as such most consumer wont even notice.

And I thought some of the comments in the Bug Tracker were quite hostile.

View on HN

> Do people not just use Electron App on Desktop

It would be nice to not have 80+ slightly different chrome installs on a desktop for all the apps these days.

Shipping just the app code and using the runtime (edge or chrome i guess, would've been nice to have firefox as a modern xulrunner successor) on the end users machine makes more sense to me.

And it's not just the number of installs but also multitasking of multiple browser engines exhausting RAM on typically 16GB laptops.

For Windows Chredge/Edgium is planned to support that via Microsoft’s something-something API which allows to declare Electronesque-mode for a app and get independent updates to the common Electron layer (and hopefully, reduce memory usage). I don’t recall if such is only available via Windows Store or is only dependent on APPX (which correlates but does not depend on Windows Store - at least not on the server side of it)

Any idea if it will support CORS bypass?

I never heard of an api from microsoft that has an electron layer. I know of webview2 runtime, but that does not work that well in appx/msix packages.

also chakra that could've been close to that is deprecated.

And I can't seem to find it. As soon as I do I'll post here for you to double check, I may have misunderstood.

Hum I may have misunderstood the model. I was thinking of this, but there is no mention of Electron anywhere on the docs. https://www.google.com/amp/s/mspoweruser.com/windows-10-2004...

Ok the Electron part was from HN https://news.ycombinator.com/item?id=22773785

oh wow that was helpful, ok there is a uap10:HostRuntime, unfortunatly the same problem than the webview2 has, you need to package your runtime so that it works with the appx model, which is not always the case and thus you need to create your own "runtime" package if there is no electron runtime package that is inside the windows store.

basically if nobody provides an up to date hostruntime package, it will be the same case as it is now.

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)

> 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.

Electron doesn't run on mobile platforms anyway.

There are Electron like tools for mobile platforms though

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.

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.

Which is kind of strange since the language maintains backward compatibility to version 1.0.

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.

> Chrome already supports it.

Chrome supports it on windows.

I myself have only used it on MacOS, Chrome OS (and Android), so supported in most places?

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).

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.

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).

Linux Mint's take on this in it's next release seems the most appealing to me. It's based on "Peppermint Ice" [1]

"WebApp Manager" uses the Chrome/Chromium/FF installed on your machine and creates a separate browser profile for each "WebApp" you configure and launches the "app" or "site-specific browser" in a new window. Details: [2][3]

Works well for simple sites where you're mostly visiting links in the same site, like Youtube.

[1] https://youtu.be/UCzL8P3WDd4?t=407

[2] https://blog.linuxmint.com/?p=3960

[3] https://github.com/linuxmint/webapp-manager

This looks great! But am I right to assume it makes use of FF's SSB feature – now being removed – and will thus soon stop working?

Not sure. That bug report discussed the --app switch, but I don't see that switch being used by webapp-manager [1] Not sure --class is related.

[1] https://github.com/linuxmint/webapp-manager/blob/4a879d11ef2...

It makes sense as long as forward and backward compatibility are maintained perfectly. If a future version of the runtime breaks something in your application you suddenly lose a lot of the value of this kind of packaging. Ditto if you make an application that uses features only available in the latest runtime.

I imagine you could declare which runtime version is known to work, and then force a compatibility mode with that declaration?

Sure, but ask yourself why that isn't true of every library and runtime that exists today and you'll see how messy reality messes up the theory.

Or just run them in the browser...

I do. But it's often nice to be able to manage them like an app in the operating system. For example being open them with a command (such as spotlight for mac or searching by name in windows). Always having their own icon in the task bar. Even missing all the chrome around the app window is nice since it reduces clutter and eliminates parts you may accidentally click on.

When COVID forced us to work from home, I initially resisted installing Slack on my computer. I don't like Electron, and I'd set up my machine such that installing Electron apps was technically difficult anyway.

IMO, the UX was horrible. I tried to keep Slack as a pinned Firefox tab, but it was far too easy to accidentally move over to a different website, at which point I stopped getting notifications. I also felt like I had to constantly keep my web browser open—I can't say why that's substantially different than having to keep a Slack application open, but for some reason, the separate dock icon helps me to mentally compartmentalize.

When I finally switched to a standalone Slack app, it felt much nicer.

If you would like to try an alternative Slack client which doesn't require Electron, give Ripcord[0] a try. I'm not affiliated in any way, just a happy user. If you really wanted, it's so lightweight that you could use it just to consistently receive notifications that prompt you to check your pinned tab.

[0]: https://cancel.fm/ripcord/

From the website: "Shareware is coming back, baby."

I've been on Linux for a while now and have not come across the word shareware in a long time. Odd the it makes me feel nostalgic and (oddly) hopeful (that is: a business model that doesn't rely on tracking, ads or some nebulous behind the scenes actions to monetize you).

Nice, straightforward, simple business transaction. Software sales (especially shareware) is really tough. Wish the author some success for his efforts.

I can confirm from monitoring the traffic coming out of Ripcord that it doesn't track anything about you at all. It's wonderful.

It'll check for updates on launch, performing a single HTTP request, but if you really like you can disable that with an environment variable on first launch and a configuration option going forward.

We need more software like this, honestly. I hate how we as users have to depend on enormous multinational entities to get back the privacy we once had. I happily paid for my Ripcord license and I'd recommend it to anyone else who cares about the same things I do :)

> It would be nice to not have 80+ slightly different chrome installs on a desktop for all the apps these days.

Especially considering that old versions of Chromium are likely to have more security vulnerabilities.

On the iOS platform, Apple essentially forbids the use of any browser engine other than the WebKit/Nitro engine provided by the OS itself. From the user's point of view this has the advantage of guaranteeing the absence of old and vulnerable browser engines on their system (provided they're up to date with iOS updates, and of course provided Apple hold up their end and maintain their software well).

As AnIdiotOnTheNet points out, this requires app vendors to stay on top of testing their app as the iOS browser engine is updated by Apple.

> It would be nice to not have 80+ slightly different chrome installs on a desktop for all the apps these days.

It's why I liked Microsoft's HTA (HTML Application) approach:

https://docs.microsoft.com/en-us/previous-versions/ms536496(...

https://docs.microsoft.com/en-us/previous-versions/ms536495(...

https://en.wikipedia.org/wiki/HTML_Application

It had lots of potential but never really took off. Looking at Sciter[0] as a lightweight Electron alternative (and a modern HTA replacement).

[0] https://sciter.com/

> Do people not just use Electron App on Desktop?

This is precisely why Firefox should support adding websites as desktop apps.

Electron is Chromium. Anyone who installs Slack as a desktop app is using Chromium. The more people who use Chromium, the less incentive Slack has to make their website compatible with anything which isn't than Chromium, which is presumably why you can't, for instance, make Slack calls in a browser other than Chrome or Edge.

If the purpose of Firefox is to give Mozilla a say in the direction of the web, they should be supporting and encouraging users to install websites as "apps" through Firefox.

There's another angle to this that was discussed on the Risky Business[0] podcast a while back, namely the security angle. As the recent Microsoft Team's vulnerability[1] illustrated, with many Electron apps any XSS vulnerability turns into RCE. Personally I am moving away from Slack, Discord, and other electron apps like them. The browser sandbox ensures that XSS is "only" XSS and doesn't turn into RCE as well.

0: https://www.risky.biz/

1: https://github.com/oskarsve/ms-teams-rce

Electron has a number of problems. First, as already mentioned, any XSS turns into much more serious RCE bug. Second, the bloat. Third, on platforms like MacOS you're encouraged (soon required) to obtain a code signing certificate, which costs money and time and is often unfeasible for someone developing a simple app, compared to web. Finally, another security issue is/was that Electron releases lag behind the official Chrome releases (although nowadays this is much better).

I'd prefer one Firefox tab in a standalone window (for example: Slack) instead of booting an instance of a different browser.

Granted, I could always have that tab in a separate window, but that groups it with other Firefox windows, making it harder to navigate to when compared to PWA.

Reply on news.ycombinator.com