Hacker News Reader

Comment by judge2020 | Hacker News Reader

judge2020

The problem (or rather value proposition) is that the only thing that matters is the end-user's perceived value, and that's almost always in the form of features and stability. Most people don't care that it takes an extra 10-100 milliseconds for the UI to react compared to a native app, especially given they just want to listen to music, which the app does just fine. If people specifically don't like the social features, they'll be mad at the decision to implement those social features instead of 'what they used for the tech stack' since ultimately Spotify could have developed the same features in a native app with just a few extra weeks of sprint, if that.

View on HN

The outrage around these supposedly egregious performance issues is more understandable when you consider that developers who spend a lot of time tuning performance in their work would naturally develop a 'selective attention bias,' magnifying the significance of what to others are negligible if not imperceptible differences.

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.

The imperceptible becomes perceptible when you make it noticeably more perceptible. A better point would be to not even show the user what they are missing out on, because then that will be the standard. The danger of the latter is it is very likely your competitor(s) will show it to users anyway.

I’d let the guy that tinkers on performance keep tinkering.

None of the competitors care about making the ui 20ms faster. Apple music just flat out didn't work for me, totally broken for the web version and not even an electron app.

Spotify is already better than the alternatives.

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:

   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)

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

    $ smem -k | grep ripcord 
    jcelerier ripcord                            0    60.2M    63.6M    84.9M

with a dozen slack workspaces open and ~20 tabs

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".

> It's only a matter of time before Slack and Discord start to ban people using alternate clients

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...

I'd wager those devs will be told to use the official Slack client.

So there’s no loss to using ripcord in the mean time.

There isn't, as long as you're willing to tolerate the risk of getting your account banned for blatant ToS violation. Companies like Slack tend to ban first, ask question never, and good luck reaching customer support if you aren't a paying business customer.

(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's pretty awesome, hadn't heard of it before.

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.

You raise very good points, that together make the picture even more complex :).

> 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.

> apps built with it can be fast (e.g. VSCode, Github desktop client, Discord)

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.

Thanks so much for that link!

They got my €18 immediately after I managed to change font sizes and typefaces to the ones I like.

> 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.

> ... the cost of making an app in a typical startup has zero relation to what the users pay ...

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.

> 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.

You can pick a modern framework that cares about performance, eg Svelte or Solid.

Great thread and discussion. IMO, there's some overhead to using a framework but it's marginal compared to the data model/flow/architecture you've chosen to implement. I don't think reaching for a framework kills snappiness nearly as quickly as reaching for a convenient but inefficient data model.

> 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)

Judging by the dismissals of performance concerns seen in typical online discussion threads, I'm not sure that developers working on performance tuning in any meaningful way still post online.

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.

> I'm not sure that developers working on performance tuning in any meaningful way still post online

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.

In terms of running a business, surely user satisfaction and business goals are much more directly relevant than performance in and of itself, except insofar it contributes to the former? So it's not surprising to me that you'd see a lot of that sentiment on a forum hosted by a startup accelerator, nor that it's what for-profit organizations optimize for. That doesn't mean that people can't also have an appreciation for well-performing or technically brilliant code.

I'm starting to come to the conclusion that performance is much more important than we realise.

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.

I can only share my experience. I used Spotify for the first time in 2011. It completely defied what I thought was possible with music streaming.

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.

The Spotify website and phone apps don't just have performance issues, they have awful bugs that have been left unfixed for months/years. When streaming to a Chromecast, the UI quickly gets out of sync, randomly disconnects, etc. I'm resorting to using a bluetooth receiver connected to my amplifier because that works better. The recommendations are also getting worse IMO, though that's more subjective, hard to quantify, but the amount of time I spend using Spotify has gone down a lot, just because I'm not discovering enough interesting tracks anymore.

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.

> The recommendations are also getting worse IMO

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)".

During the first lockdown my girlfriend and I would put music videos on youtube on a Friday night. No matter where we started we'd end up funnelled to 'Len - Steal my Sunshine' and then a predictable list of likable but before long thoroughly overplayed songs.

It became a bit of an in-joke with us but yeah the youtube recommendation algorithm is dreadful.

> Most people don't care that it takes an extra 10-100 milliseconds

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.

Users do notice speed issues in apps and websites.

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...

Generic statements such as "most people don't care [...] extra 10-100ms for the UI" need to be supported by evidence, especially since those 100ms are added to existing latency and 100ms is considered the threshold where operations feel instantaneous [1].

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

Yup. 100ms may be working as "instantaneous" in isolation. If you start chaining interactions, it absolutely isn't.

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.

Spotify's Android app is of very poor quality.

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.

It's true. I'm sad to see how far downhill Spotify's UX has slid on all fronts, but especially native. They are also suffering significantly on the customer service end. I asked for a data dump months ago and haven't gotten anything more than an automated "we're working on it" in May.

You know what’s fascinating, I find these same things so annoying and also use it less because of that… but crucially I still pay for it. So in essence I’m their best customer. I pay and I don’t use it. All streaming platforms operate like gyms, they want the most paying customers who forget they even pay for the service and don’t really use it.

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.

Yeah i still pay for it too even though I mostly use youtube music now which is much better in my opinion. I'll go ahead and cancel it because of this thread.

The iOS client isn’t much better, it seems as if they’ve given up on decent offline support all together.

I've had the same exact experience. You lose connection once and there's no way to get back to your music without restarting the app. The iOS version is better but still not amazing.

> Search is just so basic, you can not have any typos whatsoever.

I'd rather have queries for exactly what I type then Google's irrelevant "never gonna let you down" answers.

The most irritating thing to me is the constant shuffling of the menu. I'm sure they're running some sort of A/B test, but every update seems to randomly moving the menus around for no apparent reason.

If we followed similar arguments about hardware, we wouldn't have Apple today. The entire premise of Apple's hardware is that it is beautiful, well designed, with attention to details even in places where the user would never interact (motherboard layout and finish).

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.

trashcan, butterfly keyboard, bending displays, less intuitive user interface in post of similar style whit ios?

Touche, we need some finest software equivalent of Rolls Royces. Luxury software industry doesn't exist, I wish it did. I'd gladly pay 2x for a piece of software that is well crafted.

Rolls Royces equivalent software would cost at least 10x if the cost ratio is analogous to the vehicle prices.

And they would expect you to have an assistant to work the software for you. ;P

Crudely put, luxury market is iOS.

A lot more “luxury” apps compared to android, and priced accordingly.

e.g. $50 for a todo list app, etc.

I disagree with the assessment that an extra 10-100ms doesn’t matter.

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.

This. 10ms matters.

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.

Arguing app performance doesn’t matter sounds like extra polish and better fitting parts without gaps or creaks on luxury cars just do not matter.

Yes, rusty creaking lambos are the best. The rustier and creakier the better.

Myself and every (non-technical) user of Spotify I know complains about the horrible mobile and desktop apps. The android one is an absolute dog, even on mid to high end smartphones.

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.

> The first alternative to show up with an equally vast catalog (...)

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".

How many devs do they employ? How big is their cashflow? And still they fail to develop a glorified winamp that's not an exercise in frustration to use? The thing is bloated, slow and riddled with bugs that go years unfixed. Why take the risk of offering such a crap experience, just because you can afford it? Hubris? Incompetence? Both?

> Why take the risk of offering such a crap experience, just because you can afford it? Hubris? Incompetence? Both?

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.

>This is exactly why Spotify can decay so badly and still succeed.

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 mean

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.

> Most people don't care that it takes an extra 10-100 milliseconds for the UI to react compared to a native app

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.

The problem is that the people with decision power over software are usually not the ones who actually use it and latency issues are more of a subconscious thing. Slow programs just feel less good to use until they reach a pretty high threshold where it feels unbearable.

For speed good enough is just very far away from good (factor 10-1000)

The stability of Spotify is awful, I use Spotify to entertain my kids in the daytime and put them to bed at night so I’m a heavy user. Connecting to external speakers through Connect is very unstable.

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.

Transferring playlists is pretty easy. There’s a web app that connnects to most services and moves tracks between them

The problem is it's only 10-100 milliseconds when my computer is otherwise unloaded. When my machine is under high load that turns into several seconds.

My wife doesn't know WTF Electron is, but definitely notices when a pile of Electron "apps" are slowing her computer to a crawl.

> the only thing that matters is the end-user's perceived value, and that's almost always in the form of features and stability.

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.

Probably. But I'd like to think fit & finish makes an app more sticky.

> Most people don't care that it takes an extra 10-100 milliseconds for the UI

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.

I don't understand in which universe 100ms latency is fine. It's an insane amount of time. Hell, when you're used to 140+hz refresh rate, apps that have hardcoded a 60fps GUI refresh loop, so 16ms between two frames, are terribly obvious (and really feel like a pain to use)

It's not good, but it's not the worst. Of course i prefer applications which feel instantaneous, but these are hard to come by nowadays. I don't have strong opinions for 140Hz refresh rate, because i don't think i ever had monitors with more than 60Hz.

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.

> Many modern JS/Electron apps

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

They do care if they have a comparison.

Reply on news.ycombinator.com