That said, I think it's important to consider how much development time is spent on iterating as a new product's design is figured out. The company developing Slack has probably done the net work of building it 20 times over as its feature set developed and morphed over the years—and I'm sure Slack's actual complete feature set eclipses Ripcords (most of the difference coming in via features not essential to most individual users, but key to the business).
The workspace and tab counts are also hard to read much meaning from since most of the memory usage is dependent on the media that's been loaded into the app. How many web page previews, videos, images, etc. are in those tabs?
In any case, at the end of the day our sample sizes here are just too small to draw the conclusions people on here so often do about Electron. We know you can move fast with it (development speed), and that apps built with it can be fast (e.g. VSCode, Github desktop client, Discord)—but people can also build slow apps with it (no surprise), and there is a somewhat large constant factor for install size (~50mb base).
In my mind that does not stack up to merit the kind of complaints about Electron that can be found here every day.
> apps built with it can be fast (e.g. VSCode, Github desktop client, Discord)
I can't speak to the other two, but there is no way I would describe Discord's client as "fast". Starting the application takes 8-10 seconds during which it pops up several different windows on top. Switching between channels has a delay of about 1 second or so. If that channel isn't in cache, then it adds another 3-6 seconds of delay.
Switching between views isn't a new task, and isn't an infrequent one. If I think back to pidgin 20 years ago, the startup time was much faster, and switching between tabs had no perceptible delay. Discord has the advantage of 6 years of Dennard scaling followed by another 14 years of Moore's Law, so it has zero excuse for not being able to perform those same tasks to the same standard.
You raise very good points, that together make the picture even more complex :).
> The company developing Slack has probably done the net work of building it 20 times over as its feature set developed and morphed over the years
That's definitely true, especially in areas where they were innovating (or at least experimenting with features that were not common in the space). There's a cost to R&D, and I'll agree that preferring velocity is important to minimize that cost, which justifies the use of "nice for devs, bad for UX" tools[0].
> I'm sure Slack's actual complete feature set eclipses Ripcords
That's true. Ripcord doesn't replicate Slack 1:1, there were few "sparkly" that were cut (at least when I used it ~2 years ago), and of course a lot of the chrome that got removed could be considered features by some. But at least by metric of productivity, Ripcord's UX eclipses that of Slack.
> (most of the difference coming in via features not essential to most individual users, but key to the business)
In this particular case, I'd say it was 90% just removal of resource-intensive bloat. But that's a good observation in general: one of the reasons some users are dissatisfied with official apps is because of what they[2] deem as user-hostile features, existing to exploit the user instead of aiding them. Obviously, they're put there because they're the key to the business. Plenty of obviously bad UX can be easily explained when one looks at how the vendor actually makes money.
> How many web page previews, videos, images, etc. are in those tabs?
Ripcord either doesn't load those or is lazy about it. But when it does, you at least get the full picture, instead of having to click through some gallery-like popup interface :).
> apps built with [Electron] can be fast (e.g. VSCode, Github desktop client, Discord)
People will contest with you here because they're using a different reference point for "fast". VSCode is impressively fast... for an Electron app. Not so much in comparison to desktop-native apps implementing equivalent features. And that's the one well-known exception, a typical Electron application is noticeably slower and more resource-intensive than an equivalent desktop app.
> large constant factor for install size (~50mb base)
This is not something that people care about unless you're doing something silly, like an Electron TODO app that weighs 50MB and uses many times more of RAM, where the reference comparison is against a WinAPI app that would weigh 50 kilobytes and use not much more of memory.
This is also why people don't generally complain about VS Code being Electron - it actually makes good use of all the features its platform offers. But most Electron apps? Picking Electron saves developers a little bit of time, at the cost of heavy resource tax for all users. That's annoying. Especially if you have experience with native software that gives you reference points to compare.
--
[0] - I'm definitely guilty of this myself. At my previous job, I developed a prototype for 2.0 version of the company's flagship product in two weeks, in... ObservableHQ[1]. The actual work to reimplement those features in our product took almost a year. I did joke we should probably ship the prototype in the meantime (especially given that our main competitor was an Excel plugin), but we never seriously considered that.
That said, I think it's important to consider how much development time is spent on iterating as a new product's design is figured out. The company developing Slack has probably done the net work of building it 20 times over as its feature set developed and morphed over the years—and I'm sure Slack's actual complete feature set eclipses Ripcords (most of the difference coming in via features not essential to most individual users, but key to the business).
The workspace and tab counts are also hard to read much meaning from since most of the memory usage is dependent on the media that's been loaded into the app. How many web page previews, videos, images, etc. are in those tabs?
In any case, at the end of the day our sample sizes here are just too small to draw the conclusions people on here so often do about Electron. We know you can move fast with it (development speed), and that apps built with it can be fast (e.g. VSCode, Github desktop client, Discord)—but people can also build slow apps with it (no surprise), and there is a somewhat large constant factor for install size (~50mb base).
In my mind that does not stack up to merit the kind of complaints about Electron that can be found here every day.