For example, Slack-the-Electron-app and Slack-the-web-app are fundamentally identical, aside from likely some platform integration features and so on. That means that, likely, a lot of these Electron apps would already work in, for example, a Safari or Edge webview, since the web version has to anyway. I sincerely doubt that they're taking the time to strip out that compatibility, since the only reason to do so would be efficiency and if you're using Electron that's not a priority.
IOW, for many applications, there's a near-100% chance that everything would function with little to no extra work, and for most of the rest it would likely take very little.
You and I both know that one person can write UI in a vacuum, but there's a litany of other challenges that come up when positioning an application across platforms - sharing code, resources, etc. If all you look at it on is a technical level, you're doing the problem a disservice.
It's not that they cannot afford building 10 native AppleTV apps in parallel and pick the best one.
Call me when Microsoft actually ships WebView2 with the OS.
"This is literally what Slack moved from years ago, because it was very problematic, let me tell you why since I'm the one who did it.
* Adding new APIs was a huge pain in the ass, you had to write all of this ugly bridge code in Objective C, and the APIs ended up being super unnatural on the JS side. As a result, desktop integration wasn't done much since it felt like a "Black Magic" type thing. Writing new APIs in Electron is Just JavaScript, so you can make something much more natural.
* We could literally do fuck-all for people running old versions of macOS - you can't upgrade Safari on old machines, you just Get What You Get. For awhile, every YouTube video on older macOS versions had a pink shade to it. Users write in, "This is clearly wrong!" "Yep, but we can't fix it. Sorry."
* And big spoiler - WKWebView uses _basically_ the same amount of memory give-or-take a few MBs as Chromium. It's the content that sets the memory usage bar, not the host. "
Coincidentally, Slack doesn't fully work in Safari or traditional Edge. Video calls only work in Chromium-based browsers, and in the Electron app which is of course also Chromium.
This is actually the thing that finally got me to switch back to Chromium last week, after using Safari and Firefox for the better part of a decade. The Electron app sucks, I don't like switching between browsers for usability reasons, and I need to make Slack calls for work.
I am not sure what the point is of Electron: a shitty-resource hungry app that literally is a wrapped web-app. Instead of writing platform specific apps that leverage the power and capabilities of those platforms, we get a jack of all trades and master of none. Electron is a business decision, not an enlightened technical one.
What value does electron add to the user? I would argue none. That Slack can’t find the resources to write actual Swift for a Mac App is just amazing to me. Instead we are essentially interacting with a lowest-common-denominator web app. Is a chat app that hard to write natively? We’d get better performance, a smaller footprint, and a more polished, platform-specific product.
You've answered your own question as to why people write then.
> What value does electron add to the user?
It adds a lot of value to Linux and to a lesser extent Mac users: before a electron a lot of apps didn't have a version for these platform at all.
What value does _this_ add over a web app?
I've been an exclusive Linux user since college so I'm aware of the disadvantages of app/service unavailability (I remember the dark days of running Netflix in a windows VM that I barely had enough RAM to run...).
But what's the advantage of using the Slack app over a browser tab? This is a sincere question, since enough people reference the benefit of faux-native wrapped webapps that I assume there's some value.
I seem to be the only one in my company who doesn't use Slack's app, and I'm always shocked when I see a colleague's computer freeze and have them say "ugh it's almost definitely the Slack app". I work in autonomous vehicle engineering, so these are _monster_ machines I'm talking about, capable of running the entire car's stack locally. The only advantage I can think of are desktop notifications, but 1) I'm pretty sure browsers support those and 2) is that really worth using an app that's amateurish enough that it freezes your computer regularly?
I prefer web versions of those apps on Linux than electron. Sorry, I want to run just one browser and it is not Chrome based one.
And for sure Electron apps don't allow that ease of cross platform development as one thinks, I would argue that it is on the same level as a native app with good abstraction library (see Telegram client source on github).
It is more that they don't want to hire desktop developers (or just ones that want to learn something else than JS).
The current state is, you either use something that looks like Windows 95 in all platforms, or web app.
What the web made possible is to anyone to create a decent custom UI with little effort. I still remember how messed up was to create a custom component for Java Swing, which I believe is still one of the easiest to do. How would you do that for QT? GTK? WxWidgets? etc
Actually even WinForms supports them, even though too many are happily doing fixed canvas positioning without using them.
However, I think the Telegram Desktop client is not Electron either, it is just regular C++ compiled on different systems.
So a cross-platform is quite easy, Electron one would need to be tested for different webviews on each system.
Is it crazy bloated and resource hungry for what it does? Undeniably! Does it matter? Not for me.
Electron resource use can be painful for apps that are running constantly, like Discord, VSCode and Slack. For utilities like Etcher, who cares.
https://unix.stackexchange.com/a/189091/220387 https://eklitzke.org/the-cult-of-dd
I do wish they had a command-line version that just ran node without Chromium, but there is a use-case to have a simple foolproof application like this; these days there are a lot of people who need to image drives like this and would be best not to mess with dd on their first time.
And dd doesn't exist for Windows so you've got to use some tool or another like this.
It might be because it is slower and doesn't overheat my usb sticks, I don't know, but if nothing else works you can try etcher.
(Not sure how I found out, can have been something I read or a recommendation by a colleague 3 a 7 years ago or something.)
My 6 year old MacBook runs slack, Xcode, android studio, safari, chrome, messages, vs code, vim, iterm2, preview, battle.net and hearthstone all the time without issue, really.
I think for the average user, they'd rather have more features across platforms more quickly than a smaller resident memory footprint and install size.
The point is that its effectively a web app.
> What value does electron add to the user?
They have a desktop app faster than if it was being built natively.
If you just package an existing website into an Electron app that is a waste of time and user resources. Electron is intended to combine a web-based presentation/UI layer with a Node.js layer that supports access to native resources, unlimited storage, persistence outside the browser, etc. If you are not making meaningful use of these capabilities a PWA would be sufficient.
Overall, I do prefer native apps, although there are examples out there such as VS Code that have achieved UI excellence without it. Although, I really only like that on macOS... on Windows I prefer the older Windows Forms style rather than the new Modern UI, and on Linux there is a bit of style mismash between Qt and GTK apps already.
Exactly, one can look at Telegram app, it is clean, polished and open source client written as a native app that works across many platforms (and one of few that has Linux client).
These two viewpoints cannot be reconciled.
Every month when this Electron discussion comes up there are so many who dismiss the egregious resource usage outright on the basis that it's trivial for modern computers. I'm one of those people who use Thinkpads in 2021 for my personal computing and have no problems with it. I will never buy a Mac, and I don't want to unnecessarily spend hundreds of dollars on a modern system when refurbished ones from a decade ago work so well. I avoid Electron apps on the basis that they flatten my battery quickly. I switched from using vscode to vim on my x200 and my battery life tripled, I'm not even exaggerating here either.
The environmental issue doesn't make sense IMO, but increasing hardware requirements does have real impact on accessibility.
Sure, your ceiling lights use less energy than your fridge. That's not a justification for everyone to completely ignore turning them off when not needed.
Probably true.
> affects the global climate in a negative way
If electricity consumption of all computers in the world doubled because of Electron apps, the total annual electricity consumption would increase by 0.01%. So probably false.
Problem is: how to test that? Even with the most straightforward tests, there are cheaters. Appliances have a special "eco" mode to meet the specs that most people won't use because it barely does the job. And for cars, well, VW have shown us how far companies are ready to go.
On my tablet, a number of current websites don't run even on Chrome, because the tablet isn't particularly new, so it doesn't have current Chrome. It's still great hardware in perfect condition though, everything that does run on it is perfectly smooth and so on, and I still use it. Youtube in particular is fine. Literally the only reason to buy a new one would be to satisfy the software treadmill.
My old phone didn't run Chrome (or Safari). It had Firefox. The only reason I switched to a newer phone, using Android, was because of sites that gradually didn't run well on Firefox any more. That was annoying, having to ditch a perfectly great phone and replace it with something better for the web but worse for other things.
I have a Macbook Pro at home. I'm pretty happy with it, it's still a fine machine, I use it for work every day. It runs the latest Safari that's safe to run on it, but that's not the latest Safari, because it would have problems running the most recent OS.
This brave new world of "I'm sure we'll be fine supporting recentish Chrome and latest Safari" is a world of exclusion. I don't like the memory usage of Electron, but I prefer it to applications that are a bit broken!
Also, to be honest, I've been looking at memory usage. Electron uses much less than any of the three big browsers. You may know that Chrome famously starts a new process for each tab, and Safari does too. Firefox isn't far behind. As a result, the memory saved by running a new page in an already running browser compared with Electron isn't as much as it was long ago, back in the days when tabs shared memory. This is visible with Safari, as the website name shows up in the system utility for viewing process memory.
I know, that feels wrong somehow, but it's true.
Finally, when using a system WebView, will that save memory if it's opening a separate instance of the system's browser? It must be separate in some ways, if opening an application that uses a WebView doesn't open all your saved tabs from last time the browser was open. (And it's a horrible experience if opening an application does open all the other tabs.)
More like: A lot of corporate users mandated a specific version of IE and wouldn't allow anything else to be installed.
I have never bought a prebuilt Windows PC, so this is pure speculation, but I am wildly guessing that the dominance of Chrome is because computers are now coming with Chrome preinstalled and configured as the default, and most people don't care, and just stick with the default.
Now the reason everyone uses it is because it's psychologically the new "default", whether it is on the actual system or not. Everybody knows that's just what you do when you get a new computer: you go install Chrome. And the irony is that even now, with Edge being basically the same thing, most people don't bother to re-evaluate that default assumption that "the windows browser is bad". They just use Chrome.
That's one way to look at it.
Another way is to say that Microsoft has lost customer's trust and now has to work extra hard to earn it back.
IMO they've learned their lesson, at least for now, but it would also be great if others could learn from Microsoft's mistake too.
I'm not aware of any Windows machines shipping with Chrome pre-installed. But as soon as you use any website that's owned by Google you get spammed with install links for Chrome.
https://www.geekwire.com/2021/chromebooks-outsold-macs-world...
So yeah, the situation is without doubt much better now. I think people tend to forget (or aren't aware) that Microsoft actively said "there's no more work to be done here" and stopped all progress for 7 years. There's been some progress on the web since 2014, as a point of comparison.
IEDevToolbar, which Firebug was pretty much a clone of, came out a year before Firebug. And it took Firebug years to catch up in feature parity, as far as I remember.
So, firebug didn't make it the dev tool of choice. We all just hated microsoft. And tabbed browsing was great.
It really looked like a 'DOM tree/tree of Javascript classes' though, not really like the inspector we have today.
I used that IE toolbar setup for years, and it _never_ worked as well as Firebug did.
I have heard that mobile safari can be a bit more unruly than the rest, though it isn't really relevant to the question at hand
At the time, jQuery was a big help in this, especially in hiding the event model mess. Things are a lot better now. Although I do wish we had a strict compatibility-checking layer that'd warn you if you used any feature of the web platform that wasn't supported by everything you wanted to support.
> Webviews are also a moving target so you need a big testing matrix
I say this as a front-end web app dev who would most likely be affected by this kind of shift: it might be slightly less convenient, but I wholeheartedly think it's worth doing, on several levels.
People built web apps 15 years ago in the dumpster-fire that was web standards at the time (and frankly, web tooling too). Browsers, even the good ones, didn't update themselves automatically. Most of the world was still on IE which was actively hostile to web standards for the sake of lock-in (and users weren't even on the same version of IE!). There was nothing like Babel to smooth over the rough edges, there were no polyfills. And even the standards that existed, when you got the opportunity to use them, mostly sucked.
I think, given all that, we can deal with supporting recent-ish Chromium and the latest Safari, if it means bolstering web diversity and saving an order of magnitude in RAM and storage.