Comment by westoncb
5 years ago
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.
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:
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.
> 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/
literally developed by one person in Qt Widgets, covers both Slack and Discord, the installed size of the AppImage on linux is 30 megabytes
with a dozen slack workspaces open and ~20 tabs
9 replies →
> First is that this is fundamentally a question of tradeoffs, which means a single axis diagram like this is fundamentally misleading.
Agreed on the tradeoffs, and the diagram is a projection of complex parameter space onto a single axis.
> 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?
That's a very tricky question, because relationship between performance and those other factors is not straightforward. For example, the cost of making an app in a typical startup has zero relation to what the users pay - development is funded from investor money, and user-facing price is set by whatever shenanigans the business is doing at the moment - e.g. $0 to corner the market or maximize growth, or $10 as a calculated point that maximizes money extraction from a growing user base, etc.
(One would think there's no free lunch, and eventually the price has to come close to costs - but that's not how startups economy works. If you get to the point of having to turn actual profit, you've already missed your exit.)
Related to this is a second point: in a winner-takes-all market, the most successful app will suck the oxygen out of the room, preventing others from doing better work. Success typically isn't determined by the app itself - the app is usually backed by a service, which makes it not commodizable. If you need Teams because of network effects, you won't switch to Slack even though the app is better. You won't dump Spotify for a competitor that doesn't have an equivalent musical catalog. Etc.
The point I'm trying to make is: the trade-offs are often arbitrary choices. Would it be possible for an app to successfully compete with Spotify while having fast, native clients for every platform and full accessibility? Definitely. But it's not happening because it's not possible for that app to break into that market in the first place. Our would-be app can't compete on being a better music streaming player - it has to first reproduce the entire value-offering, including the streaming service, the library, and countless of deals negotiated with labels and musicians. This isn't happening, and so Spotify isn't getting any feedback from the market about their godawful garbage apps.
> 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...
I'm partial to this view. The way I see it, picking Electron by default lands you smack in the middle of what I labeled as "bad UX" zone. It takes hard work - the kind of work you've described as trading against accessibility or existence - to move it into the "good UX" zone. That work isn't usually done - you don't pick Electron if you want to make a snappy app, you pick it because you care about velocity, cornering your little part of the market. So Electron apps tend to move towards the "now you're being mean" zone - which is where this common view of "Electron = bloat" comes from.
5 replies →