>Why deceptively package the javascript as an app when you can just put it on a website?
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, runs 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 the Javascript inside of 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 trying to manage feature parity in separate code bases.
That's great, but I don't know any Electron app that needs file system or task bar access. Notifications are a solved problem already and installing web apps from the browser is just a click away in all browsers (except Firefox), after which they run completely offline.
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.
>That's great, but I don't know any Electron app that needs file system or task bar access.
I first ran Zulip chat client in a Chrome web browser tab. But I often missed replying to new messages because I always forgot to manually 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.
Does Zulip not add these red dots to the favicon? Because every chat application I've used does. I've got a bunch of them pinned exactly for this purpose.
> 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 the Javascript inside of foobarapp.html iterate all files of the local file system.
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).
Electron has always had capabilities that websites don't have. VS Code, e.g., has shell integration, uses file watchers, lets you connect to remote servers or your container runtime, interacts with other installed programs, etc. I don't want to miss these features, which is why I don't want to use the web version.
I would explain it in a way that electron has API and access to stuff that a browser should not/does not/never will have.
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.
There're few benefits that comes with packaging it into an electron wrapper, including:
- 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)
Just took a look, because 400MB seems low for Slack. It is in fact almost 1GB of memory across six processes, while providing a terrible and non native UI.
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.
the website mechanism has so many flaws, an abitrary code size restriction for once, constant access to the internet for another. And you can't really tell if the code you run today is the same as that yesterday.
They do, because the browser will arbitrarily unload your webapp for no reason whatsoever, so you'd better have the Internet available any time you want to switch back to the app...
You seen a 100MB web apps? That's pretty common in mobile apps. A practical restriction rather than a principle one. A web app can be as large as it wants, it will just take forever to load or some obscene over-engineering to stream the modules.
> Why deceptively package the javascript as an app when you can just put it on a website?
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
And what's that about notes taking 120 Mb, when Electron apps start at 3-400 Mb? Deceptively split into <App Name> and <App Name Helper (Renderer).
Not to mention when you leave a chat app like Discord or Slack running and they keep instatiating those meme gifs forever, until you run out of ram.