[tomphoolery]

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.

[pjc50]

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.

[jen20]

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.

[diggan]

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.