7 ms·

Will this make slack work fast? That piece of crap even cannot resize efficiently on a Mac m3 pro.

by ilrwbwrkhv 2y ago

onedognight 2y ago
Slack is just a website you can open in a tab/window. You don’t need to add Electron your browser diet to use it.
- samtheprogram 2y ago
  It’s desktop app that’s built on Electron. Although, yes, when I’m on resourced constrained machines, I open it in a Firefox tab.
  - magicalhippo 2y ago
    I run Slack in a Firefox window, and I had to add an extension to reload the page every 15 minutes due to live leaks. Would cause FF to eat tens of GB, making FF sluggish until it crashed...
hsbauauvhabzb 2y ago
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?
- eric-hu 2y ago
  After using VS Code for a while coming from vim, I’m inclined to say it’s bad application programming.
  - v3ss0n 2y ago
    There are many places VIM/Neovim are a lot slower / less responsive than VSCode. - Syntax Colorization of large source files. - Auto-Completion Performance - Rendering on Navigation when line lengths are very long. Only thing Vim/NVim faster is Start-Up speed. If someone care about speed actually, try Kate and Zed
    - hsbauauvhabzb 2y ago
      I think the parent was calling vscode good from a performance perspective.
      - eric-hu 2y ago
        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.
- tomphoolery 2y ago
  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 2y ago
    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 2y ago
    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 2y ago
      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.
      - jen20 2y ago
        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.
- jiehong 2y ago
  Maybe it's just not a 'pit of performance'. 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).
- lxgr 2y ago
  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.
guappa 2y ago
I use localslackirc at work, so I don't get overwhelmed. But it's certainly not for everyone. I'm the only one in my company who uses it (AFAIK).

Will this make slack work fast? That piece of crap even cannot resize efficiently on a Mac m3 pro.

onedognight 2y ago

Slack is just a website you can open in a tab/window. You don’t need to add Electron your browser diet to use it.

samtheprogram 2y ago
It’s desktop app that’s built on Electron. Although, yes, when I’m on resourced constrained machines, I open it in a Firefox tab.
- magicalhippo 2y ago
  I run Slack in a Firefox window, and I had to add an extension to reload the page every 15 minutes due to live leaks. Would cause FF to eat tens of GB, making FF sluggish until it crashed...

hsbauauvhabzb 2y ago

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?

eric-hu 2y ago
After using VS Code for a while coming from vim, I’m inclined to say it’s bad application programming.
- v3ss0n 2y ago
  There are many places VIM/Neovim are a lot slower / less responsive than VSCode. - Syntax Colorization of large source files. - Auto-Completion Performance - Rendering on Navigation when line lengths are very long. Only thing Vim/NVim faster is Start-Up speed. If someone care about speed actually, try Kate and Zed
  - hsbauauvhabzb 2y ago
    I think the parent was calling vscode good from a performance perspective.
    - eric-hu 2y ago
      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.
tomphoolery 2y ago
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 2y ago
  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 2y ago
  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 2y ago
    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.
    - jen20 2y ago
      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.
jiehong 2y ago
Maybe it's just not a 'pit of performance'. 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).
lxgr 2y ago
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.

guappa 2y ago

I use localslackirc at work, so I don't get overwhelmed. But it's certainly not for everyone. I'm the only one in my company who uses it (AFAIK).