Comment by mythz
5 years ago
What's funny about having to rely on unauthorized clones to provide a fast native UX was that Spotify's original client back in 2008 started out as beautifully light, custom rendered native client.
Few Apps ever had that wow factor the first time I used it, it was so much lighter and more responsive than anything else of the day. I remember being perplexed at how I could search and skip to any part of a song quicker than iTunes could looking at a local library. Everything was latency-free and instantaneous.
We were building a Music Startup at the time, so we investigated how it worked. We we’re very surprised we couldn’t find any evidence of an established UI toolkit. It looked as though they had built their own custom UI renderer and optimized TCP protocol which sent back its metadata in XML. Their traffic looked like it was initially seeded from their own (or CDN) servers (for best latency) and then overtime we would see some P2P traffic on the wire.
Our QT/C++ client had decent performance but was noticeably heavier than Spotify's. I was disappointed to see their native client eventually be abandoned and succumb to become yet another Chromium wrapper. I expect it fell to the pressures of a growing startup adding 100s of developers (without the skill of their original CTO/devs) where a native UI couldn't be updated and re-iterated as fast as a Web App. I wish they maintained 2 desktop clients, and left their native client alone to just be an audio player and push all their new social features to their new flagship CEF app.
It's unfortunate the skill and desire of building fast native UIs are being lost to Electron and CEF wrappers. Seems the larger the organization the more likely they are to build new Web rendered Desktop Apps and we have to rely on unauthorized Indie efforts like this for fast, responsive native UIs.
Something that Chromium apps do give you however, for free for the most part, is accessibility. I just tried the GUI version of this client and was not surprised to find out that I could not use it. The new Spotify UI released a few months ago is the most accessible Spotify has ever been. Landmarks, clear labels, headings, and even aria-trickery to automatically announce things using my screen reader. I remember being very frustrated with the old UI's to the point where I chose another service just because it was more accessible, even if it didn't have a desktop app. YouTube Music and Deezer had much better UI's from the get go. At this point, I'm almost happy to see an Electron app. It doesn't guarantee accessibility, but the likelyhood is so, so, so much higher than any modern cross-platform UI framework. I'd almost go as far as to not call these UI's native. Because if they were, if they used native controls, the accessibility would be there. The OS vendors spend a lot of time to make them usable and consistent. Sadly, these UI frameworks don't, or can't. Sure, psst has a CLI, but I only get panics. I can't do -h to find out what I can do with it, I can only call it with a spotify URL and get it to play and exit once it's done. It feels like the cli was included as a sort of testing tool to check the underlying libs and code, and not as a usable version of the app itself - but it's still very early in development so the GUI might be the same. I can't tell.
Here's how these things usually go: first, you start small. You build something you can show other people. You try to generate some traction and build interest around your idea, validating it at a very small scale (friends, family, "Show HN", etc). You gradually expand that cycle of people. You get into a routine of iterating on improvements, adding new features, and gradually scaling things up. You probably get a couple of people to join you on that journey, because the more popular your product becomes - the more asks you'll be getting, and the more work it takes to scale it out. Rinse and repeat.
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.
I upvoted you to combat your downvote because your initial paragraphs was a very reasonable description of the journey of a lot of hobby projects and its unreasonable to expect alpha apps (built using a GUI FX in active development) racing to get out an MVP is going to have accessibility nailed out of the gate.
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.
2 replies →
I read your comment and agree. Without thinking it through, it seems that if every program provided a full CLI and a sitemap like file, then a screenreader should be able to integrate with said program.
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).
1 reply →
This is an interesting idea for app-interoperability in general. It brings to mind Apple Automator, which I have no idea how works, but can sometimes be used to make Apps interoperate. It'd be pretty cool if every app did have a sitemap-like API spec that that mapped out the core of the app, and the UI sat on top of that.
6 replies →
Hi, the author here. Psst is definitely in alpha, and the CLI is indeed just an example (it's what I was using to test the core mechanisms). I'm sorry the accessibility is so bad now, but Druid, the GUI library, takes it very seriously -- which is not very common in custom GUI frameworks. So, fingers crossed, it should get better soon.
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
This is, unfortunately, a very common occurrence when GUI frameworks are concerned. For some reason, framework authors like to mislead and say that their framework is native, when it looks native but actually isn't. WX and SWT are the two notable exceptions here, they do indeed use native OS controls.
If you want to use a native GUI framework because of accessibility, check if it's as native as it claims.
You're comparing a person's side project to years of work on this in Chromium.
Seems rather like comparing someone's homemade bottle rocket to a Saturn V...
Your analogy doesn't make sense since I'm paying the same amount either way - so of course I'll choose the 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.
To be fair, accessibility is not listed on psst's roadmap at all yet.
I'm intrigued by this client, but I'll wait for a beta before trying it out.
Fun fact about Spotify web's accessibility: Alt+left/right are used to both navigate pages AND go back/skip a song. It is truly an abomination.
I honestly think we need to rethink accessibility from the ground up. modern advances in OCR and machine learning should allow us to do accessibility entirely from the GPU output.
it'd take awhile to perfect but i think it'd ease the burden tremendously for software developers and those who need accessibility.
> it'd take awhile to perfect
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
You're onto something here. As long as accessibility is the job of the developer, software accessibility will reamin "on the roadmap" for many projects. There's simply too much to learn, too many battles to fight, and accessibility tends to offer to little obvious and immediate value compared to other priorities.
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.
If you are interested in their story how the original client and architecture came to be and then how it changed to what it is today they have a podcast you can listen to: "Spotify: A Product Story" - https://pca.st/cbo7khrm
Here's also a blog post related to the topic: https://engineering.atspotify.com/2021/08/04/four-lessons-we...
Just finished listening to this, thanks for the recommendation.
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.
I watched a documentary they made about themselves... Only went there because two band colleagues ask me if i wanna come. In one scene he stands in front of a 4mx4m painting he is going to auction off. Some colors smeared over black foundation, ugly as hell if you'd ask for my irrelevant opinion. Sipping a drink he says: "Sometimes i stand here and ask myself: 'What did the artist think when he made 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.
Ulrich took it personally, thinking it was somebody stealing from him. I'm convinced Metallica would have faded to irrelevance far earlier if people hadn't downloaded their music.
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.
3 replies →
> 20 years on they still don't get it
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.
Money tends to change people.
3 replies →
Thanks! It's great to read the backstory of how the original Spotify client came to be:
> "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.
Yes, I miss this so much, I actually stopped using Spotify about 6 years ago. This might be nerdy, but the feeling of instant playback was just great.
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...
2 replies →
> 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 …
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.
I guess much that did the first client light weight was because it was developed by Ludvig Strigeus. He devloped the very light and popular uTorrent client. Very early for Spotify they bought uTorrent AB, not for the uTorrent client, but because they wanted his skills and he was the person that developed the first Spotify client. A few month later Spotify sold the uTorrent client to Torrent Inc.
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.
The early versions of uTorrent were on the order of 80KB in size, it really was amazing. BitTorrent the company re-skinned it as BitTorrent the software and offered both versions for a few years, differing only by icons and colors, but fans held to strong opinions about which was technically better. It is true that the code was hard to maintain and extend though.
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.
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.
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.
4 replies →
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.
20 replies →
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)".
1 reply →
> 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://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.
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.
1 reply →
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.
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.
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 iOS client isn’t much better, it seems as if they’ve given up on decent offline support all together.
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?
3 replies →
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.
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.
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.
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".
3 replies →
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)
2 replies →
They do care if they have a comparison.
Spotify has certainly degraded over time. My latest frustration: Controlling external devices via my computer or phone.
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.
One of the big (for me) issues with the old, native client was accessibility, or the complete lack of it.
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.
Rdio's app was stunning compared to Spotify imo.
Rdio was great, but it could not compete with Spotify’s performance. The funny thing is, those performance advantages (p2p streaming and a native C++ desktop client) are now ancient history. Rdio was ahead of its time.
Additionally Spotify's original app came out at the time iTunes was (is?) a big bloated mess, especially on Windows.
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.
> unauthorized clones
Are we really living in a world where we need "authorization" to replace some corporation's software with our own?
> Spotify's original client back in 2008 started out as beautifully light, custom rendered native client.
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
Spotify removed a lot of their great social features from that time, as well as Spotify apps. Almost everything about Spotify has gotten much worse except the reccomendation algorithm.
You can build snappy UIs with Electron. It’s easy to conflate organizational bloat’s consequences with something intrinsic to Electron.
Edit:
Upset downvoters care to elaborate? Or just huffing into the void?
Didn't downvote, but can you name a couple of Electron apps that are sna...,hell,.. not sluggish?
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?
I built an Electron app Video Hub App and it's fast:
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
In my experience, my VSCode setup responds just as fast as my fully extended VIM does.
3 replies →
Aside from the initial load that all Electron apps suffer from, Insomnia feels pretty snappy to me. Granted, I only have a few dozens of API that load 20KB of JSON max.
https://insomnia.rest/
1 reply →
Maybe try elaborating yourself? The constant criticism of Electron Apps is that they're bloated and slow, you're claiming otherwise but missed the part providing any presumption of evidence to the contrary.
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.
Electron adds no more overhead than Chrome does. Any snappy web app can be packaged as an Electron app and be equally snappy. So if there are no snappy Electron apps it's because of the web, not Electron.
1 reply →
The web is filled with bloated and slow web applications. This is nothing new. Electron is taking the fall for existing on a popular platform that lots of fast moving companies are using and unfortunately gumming up with feature creep and poor architectural design.
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.
20 replies →
Up-voted for the same reason as the edit - I'd love to hear some fact based arguments why this comment should be down voted (why it's not possible to build performant applications with Electron)
Op did not provide a single example of an Electron app that competes with native performance. When pushed, they became indignant and said that they have personally worked on several snappy Electron apps, which, however are secret. Also, there are apparently no other examples of Electron apps readily at hand.
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.
1 reply →
It’s certainly an easy fall-person for their performance issues, but it seems just as reasonable to blame an ever-expanding feature set, including advertisements and all of the analytics to go with, along with a great deal of just… age? Spotify isn’t a young company anymore, and they’ve been maintaining their shop for long enough that the kitchen sink is undoubtedly strapped to their app by now.
1 reply →
> Our QT/C++ client had decent performance but was noticeably heavier than Spotify's.
Wasn't Spotify's client Qt too ?
The original Windows and Mac clients didn't use Qt, it appears the Linux version released after did. Here's what I found scouting quora:
> 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
TIL, I only ever used it on Linux and assumed it was the same everywhere
> started out as beautifully light, custom rendered native client
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
Loading and rendering HTML can be extremely fast. The slowness we see with apps is a result of bloat, and it’s happened to our native apps too.
I really don't know what yall are going on about. I hit play on a song in spotify and it just plays instantly.
Even on the iPad app they don't follow basic things like swipe left on the edge to go back.