The reality is that we can't expect every single hobby project to support every single use-case from day one. Painfully for all - the current state of things in this space is such that building accessibility into your product is not trivial and hence it gets postponed "for later".

Now, on to a completely honest question: why don't we have screen readers that can consistently translate the "visual" version to a version people with visibility impairments can understand in a more generic manner, without requiring every single piece of software to adjust itself to every single flavor of a screen reader? I'm honestly asking why can't we solve the whole problem by offloading it to the screen reader itself. Can we solve this by simply offering a text-only command-line like version of every product? (ie. as opposed to building "beautiful"/"designed" experiences that get downsampled by the screen-reader anyways)? Sort of like building a sitemap.xml file that lets the user with a screen reader do everything a user with the full-blown GUI can. Sounds like an opportunity to create a cross-industry standard?

Edit: getting downvoted for comments like this is why I'm honestly considering just closing my account and not participating in any more such conversations going forward.

Your last paragraph for a magic screen reader is that it simply doesn't exist, so in its absence you need to use a GUI FX that supports accessibility for it to be accessible. If all the screen reader can see is a rendered bitmap they're not going to be able to identify what's a UI control or how to interact with it, which group of pixels is decorative and which is functional or how it will be able to determine the difference between a real App and a screenshot of it? With the recent real-time AI powering "copy text from image" maybe a generic reader is going to be more advanced than what's historically been possible.

But I don't really know how screen readers work, I'm assuming they need to work in tandem with GUI FX's which is able to describe the purpose and roles of its different UI elements, so if you use native OS controls it's going to be able to know how to inspect different controls of running Apps and how to send events to them.

This has been the status quo for decades of computing, but it seems quaint in this age of instant ML-driven image recognition. Anybody doing anything in the accessibility space with ML?

I don't know much about the accessibility business, but my impression is that the screenreaders are all very expensive. Maybe providing a universal interface as described would level the playing field, maybe that's not desired (by the big brands).

False. I have a print-related disability and I rely on screenreaders.

I use Orca on Ubuntu. However, the default voices for Orca are deplorable (by default eSpeak text to speech engine).

Most people do not know this, but https://oralux.org sells machine learning high quality voices (NeoSpeech engine) for $35 per voice at most which work directly with Orca. Here are the English text to speech voices: https://www.oralux.org/voice.php#english_american_english

You can also accomplish UI scripting via C/ObjC/Swift using the Application Services framework [1].

[0] https://developer.apple.com/library/archive/documentation/Ac... [1] https://developer.apple.com/documentation/applicationservice...

We should decouple the core of the application from the UI. Have a standardized interface which exposes all available functionality to the screen reader and allows it to talk to the core directly, bypassing the UI.

Stop doing what everybody does today: stop having screen reader depend on the UI (ie. aria-labels, etc). This problem can't be solved by adding "decorations" to existing UI components. It's best solved by exposing an entirely separate interface which lets screen readers (and other hardware) interact with the core of the application directly.

This sounds like a spec, a set of language frameworks and a design pattern waiting to be written.

Re. command-line Spotify clients, there is ncspot[1] and spotify-tui[2], and if you use Linux, Spot[3] looks like a nice GTK experience.

[1] https://github.com/hrkfdn/ncspot

[2] https://github.com/Rigellute/spotify-tui

[3] https://github.com/xou816/spot

If you want to use a native GUI framework because of accessibility, check if it's as native as it claims.

Seems rather like comparing someone's homemade bottle rocket to a Saturn V...

Perhaps a better analogy would be whether you want a fast but fragile kit car missing some features, or a well-built but slower caravan.

I'm intrigued by this client, but I'll wait for a beta before trying it out.

it'd take awhile to perfect but i think it'd ease the burden tremendously for software developers and those who need accessibility.

Some of us can't wait. That's why I, for one, continue to advocate for developers to make their applications accessible with the currently available tools. It's also why I'm trying, with my AccessKit [1] project (which admittedly is taking time to get off the ground), to make it easier for GUI toolkits to implement the current baroque platform accessibility APIs.

I'm also reluctant to concede that we're doomed to reconstruct UI content and semantics probabilistically from pixels, when that information is already there somewhere in the app. But it may be the best long-term solution to the social problem of trying to get everyone to implement accessibility.

[1]: https://github.com/AccessKit/accesskit

Legislation is not really the answer, or we'd already have great accessibility.

In other areas, we've automated and outsourced it - CI/CD, security, infrastructure. Think how hard it was to manage an RDBMS cluster or version control repository 20 years ago, and now even a junior developer is able to have both within minutes. We have frameworks like React.

In that time, accessibility has actually got harder, because of more devices, technologies, network connections, and more people with a wider range of accessibility needs.

I'm not sure what it would look like. Maybe a new way of rendering content, maybe a new framework that puts accessibility as a first-class concept.

Here's also a blog post related to the topic: https://engineering.atspotify.com/2021/08/04/four-lessons-we...

They spend some time interviewing Lars Ulrich of Metallica in the context of of the Napster lawsuit. He comes across in this interview as still upset at Napster for what they did, and he is at turns indignant and also emotionally wounded at the fact that they are perceived as the villains in the story. In particular he cannot seem to reconcile his belief that they, and I quote "are the most fan friendly band on this planet" with suing Napster for $100k per download in damages, a ludicrous and arrogant sum. I am not a Metallica fan and do not listen to their music (out of disinterest, not antifandom. Metal isn't my genre), but it is striking to me to see how 20 years on they still don't get it.

Slayers' drummer Dave Lombardo said about his colleague Kerry King: "He is the dumbest person i know."

You don't have to be smart, your ego problems figured out or a likeable personality to make great music.

Narcissim plays its part too. I think actually is okay to want to be admired by others by accomplishing great things. I think it is a biological urge to attract a mate. Doseage makes the poison though.

A lot of musicians still think this way, "I should be able to make a living from my craft and thus piracy is theft." But that's a misunderstanding, I believe -- people would still pay money for music, just like they pay money to creators on YouTube and the likes even if most of the content is freely available.

No offense but this is wishful thinking, they're one of the best selling bands of all time.

Here's a great clip (from the amazingly deep diving podcast What Had Happened Was) with El-P from Run the Jewels, et al, about why RTJ gives away their albums, https://www.youtube.com/watch?v=TdtLTw7Xsj8.

A close friend gave me insight on why success changes people, after I hit a milestone that mattered to me. He told me, "You are still going to have problems, they are just going to be different problems."

Each of our moral outlooks, stability, suitability for state of life, relatability, etc., is heavily dependent on our relationship with our survival environment. And success radically changes that relationship qualitatively, when it changes it much quantitatively.

Did you read about the "what survival means to us" somewhere, or was that just convos with friends?

> "Not to go into too much detail here, but at the time, most of the internet was made up of “thin clients,” like web pages or Flash-based clients that ran in-browser, and used more traditional, standardized protocols like HTTPS. Seeing the limitations of that, Ludde and a team of engineers ran in the exact opposite direction, creating a stand-alone “fat client,” building entirely new protocols and hybridizing client-server and P2P technology to suit their own ends. (Check out Episode 01, “How do you steal from a pirate?”, to hear more of that nitty-gritty stuff about persistent TCP connections and how our P2P implementation saved us bandwidth cost.) It was only by rethinking every layer of our infrastructure that we were able to pull Spotify off, to create that magic moment of double-clicking on a new song and having it instantly play. And speaking of magic …"

Having been an early user of the beta I presumed it had to be driven by people with this mindset from rethinking everything from bottom up to provide the best UX possible, would really love to read more about the technology used in the original Desktop client?

EDIT: Currently listening to “How do you steal from a pirate?” which is providing a more detailed backstory on the origins of Spotify:

https://open.spotify.com/episode/1jHRUXkeiUh44CK4KZQb0h?si=d...

Sounds like Ludde Strigeus, the creator of µTorrent was the key hire to make the original Desktop Client UX possible whose Desktop & P2P expertise was able to convince the rest of dev team to go down the path they did. Some interesting insights, they used Ogg Vorbis instead of mp3 using a custom designed TCP protocol because they were better able to strip packet bits down to transport just the audio bits required for playback.

> Michelle: The thing that happened that was kind of pure magic in that meeting was that [Daniel] did a comparison. He started playing a song on the software, and the song played so quick, so instant … I mean, I don’t know if people remember, but playback was slow back then. Even if you had an MP3 on your computer, and you played it via, you know, Winamp, iTunes, this was faster. And we were like, “You have the files on your computer, right?” And he was like, “No, it’s in the cloud.”

I had the same initial experience where I was blown away at how instant and responsive it was, at first I didn't believe it and thought it was doing some sort of pre-caching magic where it'd start downloading before selecting each song. So ran lots of tests where I did first time searches and immediately scroll to songs down the list of search results (to bypass any caches) and could see that it was indeed pulling traffic in real-time, the time from click/scrubbing to audio playing was just unbelievably fast.

This Electron crap is really a race to the bottom, so you can hire the cheapest college drop-outs to cobble together some JavaScript to add feature number 1001.

On another note, this ludde guy is one of the few rock stars in IT to me. Had a lot of fun on ScummVM, played OpenTTD to death, used µTorrent in College, you name it...

I definitely miss native apps, but I understand why they're less common now.

This reminds me of a conference that John Carmack gave (in 2019?) where he goes over how [the occulus team] got input latency down to a manageable amount on modern hardware.

It's an interesting data point that both these efforts to produce "magic" required an in-depth "rethinking" of many of the underlying stack layers.

Ludvig Strigeus is a skilled developer and have got many awards, like the Polhem Prize which is a Swedish award for a high-level technological innovation or an ingenious solution to a technical problem. If I recall correctly, he is very good at writing very small and optimized c++ programs, but the code is very hard for others to understand and maintain. So I guess when Spotify become bigger and more developer needed to work with the code they needed a more "main stream" solution and had to abandon the first client.

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.

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

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

I'll often play from my phone and connect it to my Echo speaker group. This used to work so seamlessly - it was beautiful.

But now - it takes 10 seconds for the initial connect. If I hit play/pause there's a 5-second delay to the point where I'll tap it twice, which is also delayed, and then it'll stutter and jump around. And worst of all: I'll hit pause, come back to it in a few minutes, and it's completely disconnected.

As a screen reader user, I couldn't use Spotify at all before the Chromium client was released, first in beta and then in stable.

Spotify's desktop accessibility was... passable, but far from great. It improved massively with the most recent UI redesign, which is almost universally hated by sighted folks.

This is a pattern I see pretty often, Reddit is another great example. Old Reddit is almost unusable to me, the new one is a massive improvement.

When Spotify came along it felt like a breath of fresh air, light, nimble, instant playback. Obviously the streaming approach was a departure from the older way, but it just felt so much better to use.

Such a shame they seem to have lost their way with the browser based thing.

Are we really living in a world where we need "authorization" to replace some corporation's software with our own?

I think time is a large contributing factor. A lot of things start off simple and elegant. Then you have to come up with new features year after year after year (how old is the product?) in order to not appear stagnant and keep customers happy. "Oh, this other app got x feature, I want this in the app I use too!!!"

Here's kind of a video to illustrate the point, where Rick talks about iTunes. How it used to be, and how it evolved and is now. iTunes once ruled the world. It was simple, and elegant.

https://www.youtube.com/watch?v=MKJjLwMUPJI

Edit:

Upset downvoters care to elaborate? Or just huffing into the void?

People usually point to VSCode...If that is the epitome of a responsive, lag-free software then I claim Electron defenders haven't seen snappy application.

Do people even remember Winamp?

https://github.com/whyboris/Video-Hub-App

Electron is overkill for a todo app that you want users to open/close many times per day. But if it's an app that's used for 90% while it's open and is used a few times per week, who cares if it takes 2 seconds to start?

I don't understand what everyone is moaning about with Electron. My app uses 130mb of RAM -- is that too much to ask for, for a dedicated video browser?

ps - here's also a file renamer I built with Electron: https://github.com/whyboris/Simplest-File-Renamer

I see no other rational explanation here

https://insomnia.rest/

But I remember a few months ago I was developing a basic API and testing it through Insomnia. At first, I almost had a heart attack seeing the time it took to answer, between clicking "send" and getting a response back. All this running on localhost, on an old but fairly powerful box (i7-3930k, 64 GB ram). My first reaction was I must have had some sleep() lying around.

Then I looked at the details, and the actual time taken handling the call, etc, as reported by Insomnia was a few ms, all the rest was... I don't know what.

But I do agree than other than that, when interacting with the app itself (switch requests, type, etc) it feels snappy enough. I usually use it alongside IntelliJ, which while fairly fast, isn't terminal-level instantaneous.

I've yet to experience any Electron App that's close to the snappiness and UX of the original native Spotify client, I'd like to hear about good examples of Electron Apps comparable to it.

That is, indeed, the argument, except without the "if" part.

I don’t care to share details of my past employers but I have absolutely worked on web apps that ran 60 Hz on mobile and looked beautiful to boot.

It was a team of senior devs though, and it was a small shop. We didn’t suffer from the same organizational issues at the time but as we grew, sure enough - the web application slowed as the need to move quickly and cut corners arose.

The point is that the web offers you a vast array of performance footguns that anyone on a tight schedule is going to wind up firing off at one time or another. Electron isn’t to blame. It’s architecture and code practices.

But the web is easy to hate, and by association Electron is going to take a ton of flack.

Having experienced the original Spotify App myself and having used many Electron Apps daily for years I'd posit that it's naive to claim the responsiveness and snappiness of the original Spotify App could ever be reimplemented in Electron. You're claiming it is, so lets hear about some examples we can actually use?

I’ve worked in the industry for something on the order of like 15 years and have worked on extremely snappy web apps that I don’t personally care to name given my association with them.

I’m sorry you are disappointed by the web. I actually find VSCode to be an impressive achievement with Electron, though, fwiw - which is probably not much given your obvious predisposition.

VS Code is a good general multi-purpose text editor that I use daily, but it's nowhere near the responsiveness and performance of a native editors like Sublime Text.

Opening a 1MB text file with no other VS Code windows open takes up 350MB, Sublime is 48MB. If I want to view a file quickly I'll use a native text editor. But please keep baselessly spouting how Electron produces the snappiest apps and how it's everyone elses fault for assuming just because every Electron App they've ever used is slow, it's not Electron's fault - which apparently when used in stealth internally produces just as fast and snappy UX's as native Apps.

I did not say Electron intrinsically produces snappy apps. I said that one CAN produce snappy Electron apps.

Which is indeed true, but as highlighted elsewhere by more reasonable individuals - the baseline for the web is slow. It requires expertise to do right, and in ways other platforms might not demand.

The benefit? Run it everywhere. The downside? $$$ and time. That’s why most just take their “run everywhere” benefit and accept the fact their app is going to be slow and/or a hog.

We’re discussing the platform’s potential, not the common case result of the platform’s broad userbase.

You're still asserting they CAN without being able to cite any that does. You've only highlighted everyone's favorite VS Code example whose performance and resource usage is definitely not comparable to native text editors.

Everyone already knows the obvious benefits of Electron and why it's popular, that's irrelevant to your baseless snappiness claims on a thread about the impressive UX and responsiveness of Spotify's original Desktop App which even they themselves was not able to recreate when they moved to their new Desktop's CEF/Web UI architecture.

Which explains everything.

When I open a software, I did so for a purpose, and I expect to actually do the thing as fast as possible and be done with UI...that's the reason why TUI apps are popular with power-users

I will say though that I’ve yet to work anywhere else that held themselves to a comparable performance standard.

I have yet to use a fast electron app that didn’t hog ram.

To the extent you understand the tech, though, you understand the problem was never the platform but really the hands it resides in. Nobody thinks its worth the extra work required to heavily optimize a web application.

One needn’t exist for me to be right, as unsatisfying as that may be to a group of folks unfamiliar with frontend perf on the web platform.

You’re being pedantic and are upset that you’re being called out.

The problem is not Electron. It’s far bigger than Electron. I realize this is a take that requires knowledge of the web platform and industry, however, and as such may simply be lost on folks without that context.

You’re being hard headed and am upset I don’t agree with you. Hope that helps

Atom is the Electron-based editor from GitHub. It's way slower than the others.

I can't think of any Electron apps that have low response latency. VScode's is noticeably much higher than, say, Emacs.

Slowness is the natural state of web applications and creating a fast web application is much more difficult and requires a senior team with knowledge about browser implementation in order to avoid or work around the performance pitfalls.

I also have the feeling that such performance comparisons are done with the assumption that the apps under test are almost the only thing running on the machine. If every applications were to start 10 processes taking 1 GB of RAM things would get uncomfortably slow.

Is anything fast on Android? I have a 2017 Samsung and it's always been slow.

I don't upgrade often for financial and environmental reasons but we're not at the stage yet where smartphones are a commodity and performance is stable over the years. There's still performance gains every year and they add up.

So we end up where we were, with VsCode as singular example, and in turn, with the distinctive suspicion that the inability of anyone to point to even one decently performing Electron app may just simply be because Electron is not very good.

The downvotes then probably arise from the fact that this argument has been replayed on HN hundreds of times.

Wasn't Spotify's client Qt too ?

> Qt is only used on Linux. The native parts is built with our own custom toolkit on top of a canvas- and window-abstraction layer. The canvas/window stuff is implemented with Qt on Linux, but with native stuff on win/mac. Then we have the HTML5 views, which use Chromium Embedded Framework.

https://www.quora.com/What-is-spotify-Windows-Mac-GUI-app-bu...

> Proprietary technology written in C++, C and a tad of assembler. A list of third party technology used can be read by going to Help → Show Licenses in Spotify, or by opening file://localhost/Applications/Spotify.app/Contents/Resources/licenses.xhtml (if you're on Mac OS).

https://www.quora.com/How-did-Spotify-make-a-multiplatform-l...

The list of deps is insightful looks like they used WTL for their Windows UI, no idea how they made it work on Mac as well:

Boost, Expat, FastDelegate, giflib, libjpeg, libogg, libvorbis, Mersenne Twister, zlib, NSIS (Windows only), Windows Template Library (Windows only), Growl (Max OS X only), Lua

Very much expected - back then the main Spotify developer was Ludde, an author of another little marvel - uTorrent.

[1] https://en.wikipedia.org/wiki/Ludvig_Strigeus