In my experience, purely from a UX perspective (both visuals and responsiveness), a hand-crafted macOS app tends to be moderately better than an Electron app, but an Electron app is usually vastly better than a shoddy or cross-compiled native app.
A well-crafted, organic, gluten-free macOS app is generally the best UI and UX experience on any platform, by a mile. Apps that come to mind are Things by Cultured Code and (the as of yet unreleased to the public) Nova editor by Panic.
No Electron app has ever even come close for me, certainly not VSCode that everyone seems to love so much.
But I would say the Slack UX, from a visual and performance perspective (not necessarily intuitiveness), is as good as nearly any native Mac app I've ever used. VSCode, from a visual and performance perspective, is better than any native Windows app I've ever used, and also as good as many native Mac apps.
I know people like to gripe about the memory usage and disk space usage of Electron apps, which, fine. But it's a fairly academic complaint. Those things don't honestly affect my experience as a user. The only time an Electron app has ever felt sluggish to me was Atom, fully loaded with plugins (~3 years ago), and I honestly suspect that had more to do with its naive and non-cooperative plugin architecture than with Electron itself.
> I know people like to gripe about the memory usage and disk space usage of Electron apps, which, fine. But it's a fairly academic complaint.
Whether it's academic depends entirely on how much memory you have, and what else is using that memory. As with most resource-intensive software, you can brute force it with raw specs, but you're left with less computing power than you paid for.
I was watching The Verge's review of the new Macbook Air last night, and they were talking about battery life. I'm paraphrasing, but they said something like: "Apple claims 13 hours of battery life, and you can get that if you live in Safari and other Apple apps. But I'm living my life in Chrome and Slack, and with those apps open I get closer to five hours."
Chrome and Slack are, of course, the same thing.
As strongly as I dislike locked down platforms, situations like this do make me somewhat understand why Apple doesn't allow web rendering engines other than Safari on iOS.
The weight of Chrome as a browser and the more general concept of using the web as a desktop app platform are two different things. I think that when most people complain about "electron apps", what they're complaining about is the latter. If you're complaining about the former, I think that's more fair. Although, I do question whether a third-party browser even has access to the APIs that make Safari's efficiency what it is.
What I'd like to see, personally, is for the three major desktop OSes to agree on a "desktop WebView" standard. Then they can use whatever browser internals they want when it comes to launching those web apps. They could even let you pick your own, the same way you can pick your default browser now. This would not only allow people to use desktop safari for their "electron apps" if they want to, it would avoid one of today's major problems which is shipping a whole copy of the browser with each app. Web-based desktop apps would be no larger than native ones, and depending on how the OS handles them they could be roughly as performant.
> The weight of Chrome as a browser and the more general concept of using the web as a desktop app platform are two different things.
I understand where you're coming from, but when someone says says "Electron apps are slow resource hogs", they're fundamentally referring to the underlying engine that makes those apps slow. If that engine was fast and light on resources, the complaint wouldn't exist.
Apple _does_ allow developers to use Safari Webviews within desktop apps, but by using Chromium everywhere, developers don't have to deal with cross-browser issues. Case in point: Slack video calls don't work in any web browser other than Chromium, because they don't implement WebRTC properly.
> they're fundamentally referring to the underlying engine that makes those apps slow. If that engine was fast and light on resources, the complaint wouldn't exist.
Firstly: in that case you'd have to compare it to the weight of the entire desktop environment. I would bet money that Gnome + your GTK app is not meaningfully lighter-weight than Chrome + an Electron app. It's just that the former has a privileged place in the OS, and is a dynamically-linked dependency instead of a statically-linked one (using those terms loosely).
Secondly: The web itself is not fundamentally slow. People who aren't web developers love to repeat this mantra, but it's simply not true. That's what I'm trying to get to the heart of here:
1) JavaScript is slower than C++, but it's very rare that enough actual work is being done in JavaScript for it to become a bottleneck (on the UI side), even in complex web-apps. Most of the grunt-work, including recalculating layout, is implemented in C++ as part of the browser.
2) Layout calculation can be slow-ish in extreme cases, but that's a direct tradeoff for the benefit of using the world's most advanced UI layout system, which provides real value.
3) Under normal circumstances an entire web page runs in a single thread, which can be a problem when the occasional expensive operation blocks other ones, but Electron gives you several options for moving expensive operations to separate threads. By default the web view runs in a separate thread from the "main" process, and you can spin up workers or even split your UI into separate web views so each panel gets its own thread.
I think the origins of this myth are:
1) Websites have become much slower than they need to be with the increase in JavaScript dependencies. 90% of this is due to ads and analytics, which couldn't care less about their impact on page performance. The rest has mostly to do with the initial load-time of that 1-2MB script, rather than the runtime of the actual JS code.
2) As with any technology that lowers the barriers to making things, there's been a dilution of less-skilled developers putting things out into the world, decreasing the overall perceived quality of the space. But this isn't an indictment of the technology; if anything, it's a complement. It has to be distinguished from the actual merits of the tech.
> but by using Chromium everywhere, developers don't have to deal with cross-browser issues
I think it has more to do with being able to build and ship copies for all systems through a single channel. Building a "first-class" Mac app (a dock icon, hooks into system APIs, etc.) that uses Safari's web view right now would probably mean opening XCode and writing quite a bit of actual Swift as a wrapper around the web UI. People don't want to do that; it defeats a lot of the purpose. My proposal in my last comment would solve this problem.
I don't think that the web is fundamentally slow! I do think Chromium in particular has become a major resource hog. Firefox, which doesn't have Safari's platform advantage, opens more quickly and takes up much less memory than Chrome (even as it still uses up battery quickly). Gnome Web, a Linux webkit-based browser for Linux, also performs quite admirably, so I'm not convinced Safari's success is simply due to its macOS integration.
There've been a couple attempts to build electron-like frameworks that use the OS's native webview, but they don't seem to have gained that much traction. Deskgap is probably the most mature of them, relatively speaking.
Every GTK app I've ever used that didn't come with the OS (granted, I've never actually paid for one) is, compared to most electron apps, a) ugly/buggy, and b) feature-anemic, because it's so much less easy to add features to it. And as a user, I've never noticed a performance difference. I know Electron uses more memory and such, but it just doesn't impact actual usage in my experience. Whereas things not getting implemented because of developer friction absolutely does.
