7 ms·

Absolutely. Anyone building on top of performance critical systems should have a healthy bit of gratitude for the engineers who were interested to specialize th

Absolutely. Anyone building on top of performance critical systems should have a healthy bit of gratitude for the engineers who were interested to specialize there. That said, I think it's good to remain as objective as possible about the actual impact of optimizing for performance in different domains. So for instance, the impact of attention paid to performance in the codecs used by a music/video player, or the v8 runtime, or rendering or networking subsystems in e.g. macOS or Chromium is huge. However, should we expect the impact of optimizing to be similar in application-level code for consumer apps? I would argue no (granting that exceptions exist). At this layer the computations are for business and display logic, and calling into highly performant subsystems. Additionally, they are typically 'leaves,' not dependencies of other systems (which would cause their performance choices to ramify). This is not to say consumer apps are able to ignore performance concerns: you can still make garbage that way. But you'd be deep into the region of diminishing returns if you poured as many resources into performance for application-level code on something like Spotify as you did on e.g. codecs it uses or low-level rendering code it depends on. And that's the reason tech like Electron is so often selected by folks whose bottom line is massively affective by their ability to be objective about these issues.

TeMPOraL 5y ago
There's a huge difference in the performance levels you're talking about, which creates a risk of unintentional equivocation. I've written long rants about this in the past, so let me draw a picture instead: codecs, chrome old spotify slack, teams, renderer | current spotify | | | |--v----------v----x----------v--------| FAST | SLOW slow enough to notice during casual use \________/\________/\________/\________/ | | | | overkill | bad UX | | you're just being good UX mean to users (your app should be here)
- westoncb 5y ago
  A couple things here. First is that this is fundamentally a question of tradeoffs, which means a single axis diagram like this is fundamentally misleading. For instance, we have the conclusion about 'being mean to users' toward the slow end of the scale. But if the tradeoff means the app costs more, or has fewer accessibility or language features, or doesn't run on the user's chosen OS—which is more mean? Second, this topic is contentious not because Spotify is slow but because many readers believe that building on Electron implies your app will be slow and is a basically negligent technology decision, a blight on the field of software engineering, and so on and so on... So, while I agree with your placement of Teams (though not Spotify incidentally), saying that because a couple Electron apps are not optimally snappy in this context reinforces the (imo) mistaken attribution of non-snappiness to Electron: afaict, of the major Electron apps out, there are at least as many that are snappy, and of the ones somewhat lacking in this department there are no native apps with feature parity to compare against (i.e. for Slack or Teams; Spotify otoh, maybe it is really bad for some people—not my experience, and the sample of 1 wouldn't prove much). In any case, I like the diagram and largely agree with its assertions in isolation. Edit: I'd be happy to take a look at one of your longer rants if you want to point me to one. I am genuinely interested in better understanding the situation if I've missed something.
  - jcelerier 5y ago
    > and of the ones somewhat lacking in this department there are no native apps with feature parity to compare against (i.e. for Slack https://cancel.fm/ripcord/ https://cancel.fm/ripcord/ literally developed by one person in Qt Widgets, covers both Slack and Discord, the installed size of the AppImage on linux is 30 megabytes $ smem -k | grep ripcord jcelerier ripcord 0 60.2M 63.6M 84.9M with a dozen slack workspaces open and ~20 tabs
    - TeMPOraL 5y ago
      Ripcord is lovely, I'm a paying customer[0] and highly recommend it. I used it for years with Slack, and have only good things to say about the experience. It's also a living proof that all the bloat in Slack and similar apps is absolutely not necessary. That said, the issue with Ripcord and similar is that they're all living on borrowed time - and using them means risking your own account. It's only a matter of time before Slack and Discord start to ban people using alternate clients - and then poof, Ripcord is dead. -- [0] - Fancy way of saying "bought a license when the dev finally enabled throwing some money towards them".

TeMPOraL 5y ago

There's a huge difference in the performance levels you're talking about, which creates a risk of unintentional equivocation. I've written long rants about this in the past, so let me draw a picture instead: codecs, chrome old spotify slack, teams, renderer | current spotify | | | |--v----------v----x----------v--------| FAST | SLOW slow enough to notice during casual use \________/\________/\________/\________/ | | | | overkill | bad UX | | you're just being good UX mean to users (your app should be here)

westoncb 5y ago
A couple things here. First is that this is fundamentally a question of tradeoffs, which means a single axis diagram like this is fundamentally misleading. For instance, we have the conclusion about 'being mean to users' toward the slow end of the scale. But if the tradeoff means the app costs more, or has fewer accessibility or language features, or doesn't run on the user's chosen OS—which is more mean? Second, this topic is contentious not because Spotify is slow but because many readers believe that building on Electron implies your app will be slow and is a basically negligent technology decision, a blight on the field of software engineering, and so on and so on... So, while I agree with your placement of Teams (though not Spotify incidentally), saying that because a couple Electron apps are not optimally snappy in this context reinforces the (imo) mistaken attribution of non-snappiness to Electron: afaict, of the major Electron apps out, there are at least as many that are snappy, and of the ones somewhat lacking in this department there are no native apps with feature parity to compare against (i.e. for Slack or Teams; Spotify otoh, maybe it is really bad for some people—not my experience, and the sample of 1 wouldn't prove much). In any case, I like the diagram and largely agree with its assertions in isolation. Edit: I'd be happy to take a look at one of your longer rants if you want to point me to one. I am genuinely interested in better understanding the situation if I've missed something.
- jcelerier 5y ago
  > and of the ones somewhat lacking in this department there are no native apps with feature parity to compare against (i.e. for Slack https://cancel.fm/ripcord/ https://cancel.fm/ripcord/ literally developed by one person in Qt Widgets, covers both Slack and Discord, the installed size of the AppImage on linux is 30 megabytes $ smem -k | grep ripcord jcelerier ripcord 0 60.2M 63.6M 84.9M with a dozen slack workspaces open and ~20 tabs
  - TeMPOraL 5y ago
    Ripcord is lovely, I'm a paying customer[0] and highly recommend it. I used it for years with Slack, and have only good things to say about the experience. It's also a living proof that all the bloat in Slack and similar apps is absolutely not necessary. That said, the issue with Ripcord and similar is that they're all living on borrowed time - and using them means risking your own account. It's only a matter of time before Slack and Discord start to ban people using alternate clients - and then poof, Ripcord is dead. -- [0] - Fancy way of saying "bought a license when the dev finally enabled throwing some money towards them".