Imagine the frustration of someone who, for example, did work on sound insulation for cooling systems: they sit out on a patio for dinner with friends and the sound of an inexpertly designed air conditioner appears to them as intolerably intrusive; meanwhile, no one else at the meal notices until it's pointed out.
On the contrary, I have the impression that people snubbing performance while claiming that user satisfaction or business goals are the only things that matter do not care about performance or dare I say technical brilliance at all.
This thread is about how Spotify seemed like magic in the early days. The original iPhone seemed like magic. Netflix seems like magic in how fast it can stream. Similarly, early google and amazon were always fast.
I believe our subconscious values speed as an indication of quality far more than our product owners know how to measure for.
Songs would play immediately. It was faster than iTunes. I believe Spotify is still faster than Apple Music.
This was at a time when I had no expectation that my smartphone's internet was fast enough to do much of anything. It was so impressive, that I became a paying customer and have been a paying Spotify customer for 10 years.
And Spotify pulls a lot of annoying bullshit. They have a habit of treating their users like shit in various ways - you pay and don't get ads in between songs, but they still spam pop ups and try to direct your behavior in various ways. It feels like their attitude towards you as a user is very much influenced by the "free tier" even if you're a paying customer.
Their various app UIs have suffered greatly over the years (current incarnation is mostly tolerable)
But the base thing they do - play music faster than any other service is what has kept me. I also don't think it is ethical that Apple can offer a competing service, while forcing Spotify to give up a significant cut of its revenue. I think it should be illegal, so I likely would never pay for Apple Music because of that.
This is a very confusing comment to me since "cares a lot about performance" is probably one of the most consistent attributes of the HN readership—or they are at least a highly vocal subset of the community.
Personally, I respect technical brilliance, but believe it comes in many varieties, of which performance tuning is just one and not on any kind of higher plane.
I’d let the guy that tinkers on performance keep tinkering.
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.
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)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.
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
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".
Pretty sure in the case of Slack that their business customers will have words when a bunch of their developers can't suddently communicate with the business...
(FWIW, I judged the risk was wort the effort in my case, and was a happy Ripcord user for the years I had to use Slack.)
That said, I think it's important to consider how much development time is spent on iterating as a new product's design is figured out. The company developing Slack has probably done the net work of building it 20 times over as its feature set developed and morphed over the years—and I'm sure Slack's actual complete feature set eclipses Ripcords (most of the difference coming in via features not essential to most individual users, but key to the business).
The workspace and tab counts are also hard to read much meaning from since most of the memory usage is dependent on the media that's been loaded into the app. How many web page previews, videos, images, etc. are in those tabs?
In any case, at the end of the day our sample sizes here are just too small to draw the conclusions people on here so often do about Electron. We know you can move fast with it (development speed), and that apps built with it can be fast (e.g. VSCode, Github desktop client, Discord)—but people can also build slow apps with it (no surprise), and there is a somewhat large constant factor for install size (~50mb base).
In my mind that does not stack up to merit the kind of complaints about Electron that can be found here every day.
I can't speak to the other two, but there is no way I would describe Discord's client as "fast". Starting the application takes 8-10 seconds during which it pops up several different windows on top. Switching between channels has a delay of about 1 second or so. If that channel isn't in cache, then it adds another 3-6 seconds of delay.
Switching between views isn't a new task, and isn't an infrequent one. If I think back to pidgin 20 years ago, the startup time was much faster, and switching between tabs had no perceptible delay. Discord has the advantage of 6 years of Dennard scaling followed by another 14 years of Moore's Law, so it has zero excuse for not being able to perform those same tasks to the same standard.
> The company developing Slack has probably done the net work of building it 20 times over as its feature set developed and morphed over the years
That's definitely true, especially in areas where they were innovating (or at least experimenting with features that were not common in the space). There's a cost to R&D, and I'll agree that preferring velocity is important to minimize that cost, which justifies the use of "nice for devs, bad for UX" tools[0].
> I'm sure Slack's actual complete feature set eclipses Ripcords
That's true. Ripcord doesn't replicate Slack 1:1, there were few "sparkly" that were cut (at least when I used it ~2 years ago), and of course a lot of the chrome that got removed could be considered features by some. But at least by metric of productivity, Ripcord's UX eclipses that of Slack.
> (most of the difference coming in via features not essential to most individual users, but key to the business)
In this particular case, I'd say it was 90% just removal of resource-intensive bloat. But that's a good observation in general: one of the reasons some users are dissatisfied with official apps is because of what they[2] deem as user-hostile features, existing to exploit the user instead of aiding them. Obviously, they're put there because they're the key to the business. Plenty of obviously bad UX can be easily explained when one looks at how the vendor actually makes money.
> How many web page previews, videos, images, etc. are in those tabs?
Ripcord either doesn't load those or is lazy about it. But when it does, you at least get the full picture, instead of having to click through some gallery-like popup interface :).
> apps built with [Electron] can be fast (e.g. VSCode, Github desktop client, Discord)
People will contest with you here because they're using a different reference point for "fast". VSCode is impressively fast... for an Electron app. Not so much in comparison to desktop-native apps implementing equivalent features. And that's the one well-known exception, a typical Electron application is noticeably slower and more resource-intensive than an equivalent desktop app.
> large constant factor for install size (~50mb base)
This is not something that people care about unless you're doing something silly, like an Electron TODO app that weighs 50MB and uses many times more of RAM, where the reference comparison is against a WinAPI app that would weigh 50 kilobytes and use not much more of memory.
This is also why people don't generally complain about VS Code being Electron - it actually makes good use of all the features its platform offers. But most Electron apps? Picking Electron saves developers a little bit of time, at the cost of heavy resource tax for all users. That's annoying. Especially if you have experience with native software that gives you reference points to compare.
--
[0] - I'm definitely guilty of this myself. At my previous job, I developed a prototype for 2.0 version of the company's flagship product in two weeks, in... ObservableHQ[1]. The actual work to reimplement those features in our product took almost a year. I did joke we should probably ship the prototype in the meantime (especially given that our main competitor was an Excel plugin), but we never seriously considered that.
[1] - https://observablehq.com/
[2] - And when I say "they", I also mean myself in most such discussions.
They got my €18 immediately after I managed to change font sizes and typefaces to the ones I like.
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.
These aspects of where the money comes from are orthogonal to the tradeoffs problem though: at the end of the day you have some quantity of money and spending it on A means you don't spend it on B. If performance was sacrificed, you can't look at that in isolation: whether it was a good decision or not depends on what it was traded for.
> But it's not happening because it's not possible for that app to break into that market in the first place.
That whole situation is unfortunate, but tech like Electron that allows companies to take advantage of it also enables independent developers to build things they wouldn't otherwise have time for. It's purely an increase in power and individuals can use it for good or evil.
> It takes hard work - ... - to move it into the "good UX" zone.
This isn't true. If you are to the point of having noticeable performance problems using the DOM/Chromium to render the kind of desktop application UI you might build with QT—you have seriously fucked up (imo). Out of the box this should be blazingly fast; there is nothing extra you need to do to make it fast. Just like don't run expensive computations on the render thread and don't be sloppy lol.
Where the situation complicates is once 'web development culture' is brought into the picture—and I think that's an interesting topic in itself—but it's separate from attributes inherent in Electron.
Fair enough. Myself, I mentally conflate the two - and I suppose so are most of the people criticizing Electron. This position is not without its merit, though: one of the main selling points of Electron is that you can leverage all the libraries developed for the Web.
It's the same thing as with regular web apps - modern browsers are amazingly fast, and you can create snappy experiences with vanilla JS and enough elbow grease. But people naturally reach for modern frameworks - and that very decision is what usually kills snappiness at the spot.
I think there is still a misconception here though: A) no elbow grease is required, and B) just using a popular framework (React, Vue) is not going to slow things down.
RE A, I would recommend just giving this a shot if you haven't: try building a desktop application-like UI with html/css/js executed by Chromium. My expectation of what you would find: it is snappy by default, and it's not even clear how you would write UI code bad enough to create a sluggish experience like e.g. Teams. IMO the explanation probably lies within some organizational structure at Microsoft, not the tech they're building on. (One exception to the rule of things being fast by default: with animations it's fairly easy to shoot yourself in the foot, but it doesn't typically take more effort for performant animations, just basic knowledge of what is quick and what is resource intensive.)
RE B, similar situation here: I think if you try building something with React/Vue you will see that they are also fast by default, and that no extra work is required to make them fast. That said, they (have the potential to) do a lot under the hood, so the potential for triggering something that would cause slowness is higher than without.
After writing this it seems like our disagreement may come down to this: my point is that the tech isn't inherently slow and that a disciplined/experienced programmer can use them to rapidly build high quality software; but maybe from your perspective the more significant thing is that in practice many developers using the technology do end up making sluggish/bloated software, so: that the tech allows people to make slow things fairly easily is more important than its equal potential to make fast things. I.e. the problem is that there are no guardrails + it is the tech of choice of a huge community of developers, many of whom would benefit by the guardrails? (I don't main to blame devs here so much, it's probably more that fault of businesses' priorities than anything)
Spotify is already better than the alternatives.
IMO, Spotify is neglecting its core features, and that will ultimately hurt the platform. However, there is such a thing as network effect, and they may have the broadest selection of music. That will keep the platform growing, up to a point. Eventually, the growth numbers may peak and slow down. It's just that there's a lot of inertia right now, and the growth is still going upwards, but eventually, gravity might catch up.
It seems to me that this happens on a per-user basis as recommendations are overfitted to the recommendations they've already listened to. They overfit so much that if you put a playlist of 1000 tracks you like on shuffle, it will only play the hundred or so tracks the algorithm has decided you "really like", and it will play almost the same selection if you put it on shuffle the next day.
YouTube music (music on YouTube, not YouTube Music) works the same way but less subtly. I had a great few months discovering music through their recommendations, until literally every song I listened to would be followed on autoplay by "Sergio Mendes feat. Black Eyed Peas - Mas Que Nada" or "Funky Destination - The Inside Man (Soopasoul remix)".
It became a bit of an in-joke with us but yeah the youtube recommendation algorithm is dreadful.
I probably wouldn't care about it too much if they didn't mess up the rest of their apps into the dogturd that they currently are. Doing bad UX is one thing, making UX consistently worse with pretty much every update another. And that's what Spotify has been doing for years now - if I could go back to a client-version from a few years ago, I would, immediately, without thinking twice.
The fun part? My company jumped on the SAFe-train a while ago, and Spotify was heralded as the "prime example" of where agile and all that works out really well.
I have no idea what they are doing, but whatever it is - if they continue like this, I'll go back to pirating music, because they're getting really close to having just-as-bad of an experience as that. And I really don't mind paying 20 bucks for my family account; experience is all I care about.
The NNGroup has done studies with users to gather reactions to slow websites in 1997 and 2010. They remain relevant in 2021 to both apps and websites: "Users really care about speed in interaction design" [1]
A few weeks ago someone on HN shared the reflections of the developer of SumatraPDF - a native Windows PDF reader that is small, lightweight and performant (all the things that Adobe Acrobat Reader is not).
From the developer Krzysztof Kowalczyk: "I believe being small and seemingly fast was a big reason for adoption...there will never be a time when users want bloated and slow apps, so being small and fast is a permanent advantage." [2]
[1] Website Response Times (2010): https://www.nngroup.com/articles/website-response-times/
[2] Lessons learned from 15 years of SumatraPDF : https://blog.kowalczyk.info/article/2f72237a4230410a888acbfc...
Still, for certain things 100ms is too much. Android famously had a round-trip audio latency of a bit above 100ms which made it a poor choice for music apps - in contrast to iOS. They now require 20ms in the Android Compatibility Definition Document and admit that musicians require 10ms [2].
In addition to that, hitting the 100ms threshold doesn't mean that lag is not noticeable or not annoying. There was an article about keyboard lag posted on HN a while ago, and the top comment was likewise interesting: https://news.ycombinator.com/item?id=15486494.
[1]: https://www.nngroup.com/articles/response-times-3-important-...
[2]: https://developer.android.com/ndk/guides/audio/audio-latency
Once per 100ms means 10 times per second. A game running at 10FPS would be considered unplayable, not just because of choppy rendering, but also because of input lag.
Search is just so basic, you can not have any typos whatsoever.
There is no proper history function. Say you start a radio, it only remembers that you started a radio but if you come back to it you probably will not have the same songs.
Connectivity is piss poor. If you lost connection you will have to restart the app otherwise you won't be able to use search.
While this is about the native desktop client, I assume it has similar problems so the argument that it is only a couple milliseconds of latency doesn't hold up. Their UX is the worst I've ever had to deal with in a music app.
I’m guessing someone in Spotify’s marketing dept or user retention came up with an algo that determined the features/bugs that would make the service just bad enough that it’s still usable (and thus worth paying for) but too annoying to use too often.
I'd rather have queries for exactly what I type then Google's irrelevant "never gonna let you down" answers.
You might be guessing from intuition that 10-100ms latency doesn't matter, but I suspect that it does. You can feel the philsophy of the company when you use their products and they feel wonderful. It's a culmination of attention to detail in every aspect of development. I love Sublime Text precisely because of how fast it is.
And they would expect you to have an assistant to work the software for you. ;P
A lot more “luxury” apps compared to android, and priced accordingly.
e.g. $50 for a todo list app, etc.
How pleasant an app is to use does affect a user’s perception of an app and product even if they can’t articulate it. Fit, finish and polish do matter.
Yes, rusty creaking lambos are the best. The rustier and creakier the better.
On my first iPad, gestures seemed to actually move the screen like paper. Now you perform the gesture and the screen does it’s animation. It doesn’t feel alive. And the animation gets in the way, because you need to wait for it.
If you neglect your core features in exchange for pointless trinkets you're setting yourself up for failure.
The first alternative to show up with an equally vast catalog, but a light and fast interface is going to win a lot of customers in no time.
Remember this is streaming: there is no friction for me to switch. I export/import my playlists and it's done.
This is exactly why Spotify can decay so badly and still succeed. This is why most widely-used apps are so bloated and offer such ridiculously bad UX. It's because the whole point of the business behind them is to ensure there will be no alternative.
Slack, Teams, Discord, et al. live off network effects. You'll go where the community is. At work, you'll use what your employer picks for you, and your employer has a huge list of concerns[0] that are more important to them than user experience. Spotify survives because of the catalog - making a streaming app is relatively trivial; reproducing all the deals with labels and individual artists is an insurmountable barrier. Netflix was untouchable up until their distribution deals expired, at which point the owners of the content all spun up their own streaming services - but a random entrepreneur can't possibly break into that market.
--
[0] - Ranging from "does it tick the right cybersecurity questionnaire checkboxes", through "does it integrate with our SSO", "does it work with our SharePoint", to "was the golfing with the salesperson fun".
They have an insurmountable barrier to entry built out of their deals with labels and artists. They just don't care - caring cost money that could be used elsewhere in the business.
The thing is, that for many people Spotify wasn't competing with other platforms. Spotify was more convenient than downloading music. And at some point of decay, it no longer is.
I have one of the fastest laptops (Apple M1 MacBook Pro) and now I opened Spotify and it was just a black screen for about 1 minute before it showed anything. Then it started.
It is usable. But not good.
You can tell this is true because people keep complaining about it, and developers keep reminding us that we don't actually care about how slow apps are.
For speed good enough is just very far away from good (factor 10-1000)
The thing that keeps me on Spotify is that I’ve invested a lot (but not insane) time in curating my playlists. If I was guaranteed a high quality experience with a competitor I would make the switch but I’m not going to make the switch just to find out that the competitor also sucks.
I think here it's more accurate to say, "the business' impression of the end-user's perceived value".
Because a snappy user experience DOES have real value; in web we are very conscious that milliseconds cost viewers in load and response times. It's well documented that brand positivity is connected to load and response times.
But users don't know to tell you that until the performance gets REALLY bad. Consequently it's hard to get this value from a user survey, and hard to communicate internally as a value prop. Capabilities are much more business process friendly.
TLDR: up to 100ms latency is fine, but alongside higher RAM usage, and when applied to all programs across your machine (not just a single app), hell breaks loose.
I entirely agree with this statement. However, most people don't have a high-end machine like the developers test on, and actual difference in latency between an electron app and a web app may be over an order of magnitude larger.
The problem is in many parts of the world (including in poorer communities of the global north) people rely on second-hand hardware which even in 2021 typically has 1-4GB of RAM, so a single application taking hundreds of megabytes when not over a gigabyte of RAM will quickly lead to you swap hell and render your entire machine slower.
Despite being an ardent GNU/Linux user, I believe the linux kernel OOM is close to the worst that can be done in this matter (although there are certain progresses with eg. earlyoom), but MacOS and Windows are certainly not immune from it. You'd be surprised just how much people avoid using their computer altogether when they don't absolutely need it, just because it's slow as hell, just because developers in their ~ivory towers~ offices didn't do testing on reasonable second-hand hardware.
Many modern JS/Electron apps are in fact network bound for UI updates which is the worst possible thing you can do... just try to use element.io in a Tor Browser on a normal xDSL connection and you'll see what i mean (unless it's improved recently). So on this scale of the absurdity of modern software engineering, 100ms latency for user interaction is not all that bad... although my GUI/CLI tools in the 90s were much snappier than that and we have in fact greatly regressed as a field.
made my blood boil every time I had to use them. Even the poster child for a good Electron app, VS code, while packed with cool features, feels so sluggish next to Qt Creator that it distracts me from my work constantly when I use it.
Thankfully, on my Linux desktop, the actual number of such apps I actually need is precisely zero, everything has at least one (much snappier) Qt or GTK alternative.
> just try to use element.io in a Tor Browser on a normal xDSL connection and you'll see what i mean (unless it's improved recently).
I just tried without Tor and counted 5-6 seconds between the time where I clicked on "Open in your browser" and the page actually showing up here: https://element.io/get-started, so I'll happily pass