A desktop app based on Electron-Chromium runtime has more integration options with the operating system. E.g. file system access, taskbar/Dock icon and notifications, run in the background, etc.

If a developer were to create a 100% pure web url app running locally on https://127.0.0.1/foobarapp.html -- ... they'd quickly run into browser's limitations. For example, the sandboxed security model won't let foobarapp.html iterate all files of the local file system. And Mozilla's new filesystem api isn't really available yet: https://caniuse.com/native-filesystem-api

Not sure if there's any "deception" here. Developers just want to write desktop apps leveraging their existing Javascript knowledge instead of learning C++/C#/Swift for each platform and managing feature parity in separate code bases.

Chrome added a file system API for some reason, but every Electron based application I've used just used the standard <input type=file> prompt and it worked absolutely fine. Even things like live screen recording and P2P VoIP can be done from the browser now.

I'm sure there are plenty of applications that need Electron, but I'm having a hard time coming up with any.

I first ran Zulip chat client in a Chrome web browser tab. But I often missed replying to new messages because I often forgot to cycle over to the Zulip tab to check for them.

After a few days of fighting that limitation, I gave up on Zulip in the web browser tab and installed the desktop version of Zulip (Electron runtime). Now new unread messages trigger a red dot on the taskbar. The desktop version is just easier to use.

If a developer has the app run locally on 127.0.0.1, they already have the capability to enumerate files (without the Web browser's cooperation).

Browser should be much more sand boxed and never have access to the file system with privileges of a user running browser.

Yes, someone can install malicious electron app but that is totally different than randomly stumbling upon malicious website while browsing/clicking around.

- making sure it works on all platforms independently of the browser you use (because it comes packages with chromium)

- having access to more API from the platform. Although the UI is rendered through a WebView, there's still native code running, that you can hook back into your app. That can be useful to either offload some logic to native, or access native API that you pilot from the WebApps

- having a shortcut icon to open you app in the system (although this is getting obsolete now that Chrome and Safari offer "Add to Desktop" functionally)

- I know that I can access it from any device and any OS.

- Better security and privacy unless it grant it permissions.

- I can open multiple tabs and switch between them.

In some cases, so you can load and save data from the user's disk instead of the app's back-end.

Because they appear separately on the user’s task switcher. Honestly there’s not a lot more to it than that. And users do appreciate being able to switch to e.g. Slack specifically rather than switch to their browser then find the Slack tab.

You can do all of this with progressive web apps too these days, but every time they come up in HN people crap on them, so… shrug

Google Chat has a similar issue in that it uses a lot of memory for what it does and has a shitty UI, except it's actually a PWA.

I do get the cross platform benefit, but how many developers do you actually need to build an awesome native application, when much of the interaction is done on the backend anyway? Slack does seem a little complicated, but I have the feeling that you could do Google Chat with perhaps five developers per platform.