Pretty sure we crossed the Rubicon in the other direction, as it was basically the popularity of Electron apps that forced Microsoft to abandon their own browser rendering engine in favor of Chromium.
If you had come to me 10 years ago and said "Microsoft will drop their browser and use Google's code," I absolutely would not have believed you.
What I've noticed is that much of the distaste with Electron apps has more to do with the idea of waste than with the actual practical implications. Programmers like things to be efficient and optimized. Electron sacrifices those traits in a couple of ways, in favor of actual productivity.
So "the downsides of Electron outweigh the downsides of native apps" when you're someone who patrols the task manager looking for things to be upset about. Your chat client - one of half a dozen applications you realistically have open - using 400MB of RAM on your 32GB workstation does not have a meaningful impact on your workflow. It's just offensive.
I think it definitely depends on your use-case. Like you wrote, if everything else you have open also churns through battery life, it's unlikely having Slack open will make a difference.
However, if your other applications are a terminal, other efficient text editor (e.g. Sublime), and other generally respectful apps, I've found having Slack open is the difference between having enough battery life to work all day, and not.
But that is just one one electron app. Imagine that every desktop app you use is written in electron. I am pretty sure that even 32GB workstation would be stretched to the limits.
32GB workstations are the exception, not the norm. I'd wager most people are using Slack from computers with 8GB RAM (e.g. every 13 inch Macbook Pro that isn't built to order) and at least one browser open at all times.
(I'm not against web APIs as a platform for desktop apps, but I'm happier using Webkit wrappers and I think this would be improved, cross-platform, if Chrome could effectively host the apps that currently ship with their own instance of Electron or CEF)
That's nice for them, but no matter what OS you're on the desktop client is probably crappier than loading up the webpage, with the one upside of giving you a separate icon in the dock and app switcher.
Even with the performance improved, the "stuff the whole app in one web view" implementation is still showing. Clearly this isn't an Electron limitation; VS Code handles multiple windows just as well as any other text editor.
Slack's desktop client is basically "It's a web browser except worse and with the URL bar hidden." Since chat requires an internet connection and it's not like Slack's desktop version launches particularly fast, I'm not sure that it does anything better than using a browser.
We'll see if they support multiple instances on iOS 13. If they do, maybe we can get a Mac version based on that for something closer to native desktop behavior.
> no matter what OS you're on the desktop client is probably crappier than loading up the webpage
I don't see how it could ever be worse than the webpage. And it gives you nice perks like notification badge integration, which for me personally is essential.
My web browser has windows and tabs and lets me open Slack in multiple places if I want to see more than one view of Slack at the same time.
I usually don't need to do that, but when I do it's annoying that the desktop client prevents it.
It's fine that my phone doesn't let me open two text conversations at once since that's all the space it has, but on a computer with a 24+ inch screen and multiple virtual desktop spaces with different sets of tasks, it's a pointless limitation.
You're right, I, a user, don't perceive any of the upsides.
The upside that keeps getting paraded around is that it's a huge boon for product velocity. But that's just objectively false because Slack-the-product hasn't meaningfully changed in years.
If you had come to me 10 years ago and said "Microsoft will drop their browser and use Google's code," I absolutely would not have believed you.