I see electron get a lot of hate, and don’t get me wrong, I empathise with your issue, but has anyone ever documented an analysis on whether these sorts of things are caused by electron itself, or just bad application logic which just happens to be running under electron?
As someone who's made a few Electron apps in the past, I can say that it has a lot more to do with what you're putting into the app itself than the runtime shell you're working with. It's not impossible to make an Electron app that's very efficient, to the point where people probably wouldn't realize it uses Electron unless they opened the app itself and poked through the source code. That said, due to Electron being a layer above the actual application stuff that's doing the "real" work, it's a lot harder to sniff out performance problems and especially to reproduce them on all platforms. So I wouldn't call this "bad application logic", I would say that it probably has more to do with using older (and deprecated) APIs to handle certain things like resizing the window, which could be replaced with better ones if the devs at Slack were able to easily see that this was causing problems for people. Unfortunately, Electron does make that a bit harder to do.
Basically...I'd say this has more to do with the fact that Slack's development team doesn't get enough control over their applications in order to make things like this happen faster.
Yeah - people use Electron because web-style UI toolkits are what they know and work cross platform, but those toolkits make it easy to write very un-performant applications that do block/repaint/block/repaint cycles which feel awful.
Everyone knows the electron apps even if they perform well - they’re the ones that don’t integrate properly with basic system services and don’t use native controls.
Ah yeah, common examples include Premiere Pro, Blender, Photoshop, Fusion 360 and a host of other Electron applications because there is no integration + they don't use native controls.
The Adobe apps integrate fine (on macOS at least). I don't know about any of the others, but would assume that a cross-platform UI solution leads to a bad experience.
Are the Adobe applications using the native toolkits on macOS? Because on Windows they certainly not, and I'm having a hard time imaging macOS has completely different UIs than the Windows versions.
What I mean is: perhaps the path of least resistance (and thus the cheaper way) does not lead to good performance by default.
If only platforms and frameworks would make the fast way easy, and the slow way hard, it would be simpler to have faster software (not that it's easy to do).
Now, if only all programs had performance tests on all commits (like browsers use speedometer 3, and track the trend over time, because they know it matters to users).
Indeed I was. I mentioned vim because I’m used to that level of performance and VS Code is on par. I have experienced sluggishness with Slack, so I meant Slack likely has performance issues due its application code rather than its Electron dependency.
I'd say that it's a great synergy of wasted time, money, and energy:
A bloaty runtime (primarily because it's not shared across processes, as every app brings its own private copy of Electron) enables running the horrors of modern web development, i.e. pulling in thousands of libraries, sometimes each in several versions.
