Get the top HN stories in your inbox every day.
mythz
ClawsOnPaws
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.
csmpltn
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.
mythz
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.
dailyanchovy
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).
eloisius
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.
jpochyla
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
miki123211
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.
OOPMan
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...
blowski
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.
bovermyer
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.
dalmo3
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.
jatone
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.
mwcampbell
> 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.
blowski
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.
ap-andersson
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...
vsnf
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.
scns
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.
toxik
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.
brianzelip
> 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.
inter_netuser
Money tends to change people.
mythz
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.
fps_doug
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...
jayjader
> 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.
MasterYoda
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.
zanderz
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.
judge2020
The problem (or rather value proposition) is that the only thing that matters is the end-user's perceived value, and that's almost always in the form of features and stability. Most people don't care that it takes an extra 10-100 milliseconds for the UI to react compared to a native app, especially given they just want to listen to music, which the app does just fine. If people specifically don't like the social features, they'll be mad at the decision to implement those social features instead of 'what they used for the tech stack' since ultimately Spotify could have developed the same features in a native app with just a few extra weeks of sprint, if that.
westoncb
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.
blub
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.
runawaybottle
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.
snek_case
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.
ouchjars
> 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)".
Shacklz
> 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.
open-source-ux
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...
blub
Generic statements such as "most people don't care [...] extra 10-100ms for the UI" need to be supported by evidence, especially since those 100ms are added to existing latency and 100ms is considered the threshold where operations feel instantaneous [1].
Still, for certain things 100ms is too much. Android famously had a round-trip audio latency of a bit above 100ms which made it a poor choice for music apps - in contrast to iOS. They now require 20ms in the Android Compatibility Definition Document and admit that musicians require 10ms [2].
In addition to that, hitting the 100ms threshold doesn't mean that lag is not noticeable or not annoying. There was an article about keyboard lag posted on HN a while ago, and the top comment was likewise interesting: https://news.ycombinator.com/item?id=15486494.
[1]: https://www.nngroup.com/articles/response-times-3-important-...
[2]: https://developer.android.com/ndk/guides/audio/audio-latency
TeMPOraL
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.
jack_pp
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.
vxNsr
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.
gmassman
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.
bradstewart
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.
ryosuke
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.
rightbyte
> 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.
jamil7
The iOS client isn’t much better, it seems as if they’ve given up on decent offline support all together.
systemvoltage
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.
imachine1980_
trashcan, butterfly keyboard, bending displays, less intuitive user interface in post of similar style whit ios?
ipv6ipv4
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.
inter_netuser
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.
laurent92
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.
tjbiddle
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.
miki123211
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.
amerine
Rdio's app was stunning compared to Spotify imo.
montag
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.
djhworld
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.
tim--
One thing that has devastated me about recent Spotify updates is that now, when viewing an Artist, you do not get to see all of the albums (or at least the first 10 newest albums) for that artist straight away with all of the tracks listed. It's now much harder to find a song that you don't know the title of, but you know an artist has sung.
It's also small changes that are extremely annoying. Pressing "New Playlist" used to come up with a dialog box asking what the playlist should be named. Now it just gets called "New Playlist". Clicking the playlist name to rename it does not automatically select the textbox to give it a name, meaning that to create a new named playlist - an action that used to take one click, is at least three clicks and two keyboard presses... I mean, come on Spotify!
The search bar used to always be visible. Now I need to click search first, then click the search bar.
To me, Spotify was the epitome of software completion five years ago. The client worked. It was perfect. It seems like every single update since they released the "Daily Mixes" has both downgraded the performance of the app, and made discoverability harder. I want Spotify how it was 18 months ago.
Spotify on my machine sometimes chews up 2GB of RAM. Reached out to support, and the best that they can give is "try restarting the app". That helps, until 12 hours later you need to do it again. A music player should not have 10% CPU usage on a modern MacBook.
Finding Psst has been a life changer.
chx
Discoverability...
I'd pay handsomely for an app that did discovery on tracks and not artists. Last.fm kind of but not really does it. It took me many years to get from Sirenia: Seven Sirens And A Silver Tear to the Midnight Sonata (I can't remember alas who did it -- was it reddit or a forum on a now defunct tracker? all the great trackers are dead) and from there I was able to branch out. But this shouldn't be so hard..? We already have several music matching apps, surely closeness is a solvable problem.
operatorius
> a forum on a now defunct tracker
Years have passed. I still havent filled the gap left by whatcd...
chx
Nothing can, it seems. What wanton destruction. Oink's Pink Palace first, then what.cd
blehn
Try YouTube Music. There's a tab in the player that shows related tracks for each song you're listening to.
chx
Based on https://www.reddit.com/r/YoutubeMusic/search?q=related&restr... I will pass.
brianmcc
They really do make things worse and worse and worse. Related to your playlist example - saving an actual album I liked as a new playlist would give it a default title, "artist - album title" or something like that. Fine, 2 clicks: create the playlist, and accept the title.
Now? A blank text box. "Let's ignore the artist and album this user's basing a playlist on and make them type the whole thing from memory". I just don't bother any more, which seems petty but it's just so cumbersome, from mobile especially.
Teknoman117
Oh wow. I thought that was only a mobile thing, going to have to check the "desktop" app now...
milofeynman
I have also noticed this. There isn't even a way to see songs, you always have to go to each album. I don't remember the album! Or the name of the song!
norov
Under the artist's page, select their Discography. Songs not released under albums should show up under 'Singles'
tim--
Again with the multiple clicks though. You need to select 'Singles & EPs' after clicking the drop down with the label 'Albums'. To see all the tracks, you first need to change the view from grid view to list.
gxqoz
I wonder if some of these decisions are driven by their business model. My understanding is Spotify's agreement with record labels means they have very low margin on a typical song stream. I've heard that some of their playlists are very valuable for artists and that there's some payola going on there. It could make sense that they're nudging people in those directions.
They also see much more upside in podcasts and thus are pushing people there.
kuu
I'm on the same boat: finding a song now requires too many clicks. Albums make sense in a physical world, but not in the virtual one.
JasonFruit
An album is (ideally) carefully crafted to work as a coherent musical statement. Tracks in isolation don't have the same effect. It's even more so in classical music, where a work usually encompasses multiple tracks. One of my frustrations with Spotify is that it doesn't understand multi-movement works, so you get an single movement — sometimes even one that is connected to the preceding or following one — in isolation, and it's often really unsatisfying.
tl;dr I think albums have more significance than you do.
kuu
Let the user be the one choosing how to use the music.
I think Spotify (at least for me and I think for many others) is great because of lists: I'm the one choosing what and when to listen the songs, and I'm able to group them. I have lists made out of albums where I respect the order that you mention, with the same implications. But some other lists I have hours of songs that don't fit under the concept of album.
I agree and understand your point, but I think in the past Spotify's UI had both options: the songs were sorted by album, but also allowed me to access all of them and cherry-pick the ones I wanted easily from that same view.
antifa
But none of that matters because most artists only upload a small number of songs from each album anyways.
avh02
dunno how long it will last for, but you can add `ui.experience_override="classic"` to your prefs file to hold out a little longer.
tim--
Sadly, this does not work on the newest version of their client.
DynamicStatic
True but you can use a old version and set the update folder to read only.
avh02
oh? I'm on stable version from snap and it's still alive - time to find a way to keep an old version around just in case (apparently snaps don't make this easy.)
lucsky
> The search bar used to always be visible. Now I need to click search first, then click the search bar.
This is a lie. When you click "Search" in the side bar the search field gets focused automatically. It is still just one click.
tim--
I just checked Spotify, and it seems like yes, it does now get focused automatically, not sure if it was always that way, or I just feel that I need to click the textbox after choosing the menu item on the left hand side.
That being said, it was still much friendlier to have a search box that you could click on straight away. From a UX perspective, you need to move your focus away from where you have clicked, because the textbox is in a different area of view.
Clicking back on the search menu clears the search that you were doing. It's fine, you can click the back button, but the old Spotify client (iirc!) would keep your previous search in the search box.
amethyst
At this point, I'd be willing to pay for a Spotify client that works exactly the same, but just ignores the existence of podcasts entirely. I use a dedicated podcast client when I want to listen to podcasts, and they keep shoving them in my face and taking up precious UI real estate everywhere.
But any client without support for Spotify Connect might as well be dead to me. Controlling my wifi speakers from my phone, or playing music on my desktop Mac from my laptop or gaming PC is critical functionality at this point.
gizdan
Check out spicetify cli[0]! It patches the Spotify (desktop) client and makes it better. It also adds support for extensions, one of which[1] disables the podcast features. I haven't used the extension so I'm not sure how well it works.
Heads up though, the original developer is MIA at the moment and the latest few versions of the client are incompatible. There's an effort by someone to fix the issues and there are other maintainers who mostly just seem to address PRs. Personally I just downgraded the client and it works perfectly.
[0] https://github.com/khanhas/spicetify-cli
[1] https://github.com/3raxton/spicetify-custom-apps-and-extensi...
jfrunyon
I'd be willing to pay for a Spotify client that allows you to select your audio output device. And yet here we are, 10 years later...
Spotify is a marketing platform first and an audio player second.
lwansbrough
If you’re on Windows, you can define audio input and output devices on a per app basis through Windows’ settings. Handy for any app that doesn’t support such configuration (though Spotify obviously should.)
stjohnswarts
It works similar on Linux with pipewire/alsa/pulse, there are several guis for such.
jfrunyon
TIL, thanks!
konart
I'd rather use https://staticz.com/soundcontrol/ (which I do use actually) than rely on an app like Spotify to be honest.
vladvasiliu
This. I absolutely hate it when apps try to be smart and use their own audio routing.
I'm a Linux user and have multiple audio outputs. I've configured Spotify to always go to my amp / speakers. And it works great.
But then there's Teams, which is absolute sh*tshow. It always says "custom configuration" but you never know where it goes, and partially ignores the configuration in PulseAudio / PipeWire.
I understand why they do this, random users may find it more useful to have this choice directly in front of them, and I would agree... if it worked well! Zoom at least has the good taste to have an entry for "use system settings", which seems to mostly work.
I think that aside from "specialty" applications (like DAWs, etc) regular apps have no business messing around with the system audio settings.
jazzyjackson
What platform do you mean? The iOS app lets me select output device. It’s a little icon next to play/pause, kind of half computer screen half bookshelf speaker (monitor/monitor :)
I think I remember seeing this on desktop too but at that point why not use the OS sound mixer?
jfrunyon
No, the app lets you select what system you're going to listen to Spotify on, not what audio device to use on your system.
Sometimes I just want music through my speakers while I have something else piping into my headset. ¯\_(ツ)_/¯
sbuttgereit
Android works pretty much the same way. I'm usually listening on my PC, but I don't try to control other devices from there so I can't remember if it's possible there.
cik
Can't you just do that outside of Spotify? It would be nicer if you could in app, but with pavucontrol I have Spotify send music where it belongs.
throwaway1777
They make it easy to play to any Bluetooth device or headphones. Covers my use case, but I can see it being annoying if it doesn’t support your setup.
savolai
On iphone I can’t seem to actually choose the bluetooth device to play to from the app itself. iOS limitation?
rubiquity
Came here to say this. It was hard enough losing Rdio and now Spotify has been on a rapid decline for the last 1-2 years. It used to be a place to listen to music you already knew and maybe find something new and now they do nothing but shove podcasts down your throat. Who that works there is looking at the current UI as an improvement?
bullfightonmars
I loved Rdio for the Ui. I subscribed for years. That said Spotify has introduced me to so much music that I missed growing up.
The Spotify UI has been pretty painful lately but I have a hard time living because the suggested music selection has been so good.
swiley
I love my 3.5mm cables for this reason. No negotiating with vendors (except Apple but it's well known that they really suck) just plug and play.
asdff
I can't wait to sit my grandchildren on my knee and tell them stories of the magic headphones that you never needed to charge and just worked instantly with practically any audio device ever made by mankind right up until the iPhone 7 was unleashed unto the world.
SilverRed
They would probably see it like we computers that had memory which did not wipe when powered down. The inconvenience is minor and the benefits large. They will never deal with huge hell balls of cables/headphones. The charging is pretty painless and the airpods pretty much do just work instantly with any Apple device (they can detect which one you are using at the time).
swiley
Between their screw ups and Pine64's successes that hopefully won't happen.
eurasiantiger
Remember to throw in stories about impedance matching and the differences of A/B and T/D class amplifiers, as well as soundstage, acoustic compression and active correction.
matthewfcarlson
I'm with you 100%. If they had a decent podcast experience, I'd be happy to switch but it's terrible. Why can't I mark something as already played?
josephg
Yep; I'm a paying customer of spotify and I like some of the podcasts they have. But they don't have the gap removal + speed controls of Overcast (my fav podcast program on my phone). So I'm in this weird situation of never wanting to listen to any podcasts through the spotify app, which I'm paying for. And then when I want to listen to music (eg while coding) I have to wade through podcasts which are intentionally designed to blend in with music recommendations in spotify's apps.
I hate it. If any spotify PMs are listening:
- If spotify wants me to listen to podcasts, let me do it from my existing podcast app. I'm sure the developer of Overcast (and other apps) would happily add a spotify login button for a song if you ask nicely and offered to pay.
- Let users disable podcasts entirely in the spotify app.
- In the spotify app, give podcasts a consistent visual differentiator so I can easily visually separate them from music. Nobody wants to be tricked into listening to a podcast instead of music. Maybe make the "album cover" for podcasts a rectangle instead of a square. Or change the background color for all podcast related content to blue so I can find podcasts visually (or filter them out visually) while scrolling.
gonehome
I don’t think Spotify wants you to be able to use your favorite app.
Their strategy is to take the open protocol of podcasts and pay the hosts to turn that into centralized tracks on Spotify to force you as the user to use Spotify to listen to it.
It’s about control intentionally - that’s the strategy.
vxNsr
Spotify has spent over half a billion dollars on acquisitions and investments into its podcasts division, there is zero chance they ever intentionally implement anything that might impede the returns on that spending.
pornel
If you care about Podcasts, don't listen to them on Spotify, ever. Spotify's plan is to build a walled garden around them.
Spotify promotes podcasts and buys exclusives so desperately, because their plan is to grow their audience to a too-big-to-fail size, so they start dictating their own terms. Every remaining use of RSS is a business opportunity.
yupper32
You can. There's a "Mark as played" button in at least the Android Spotify app that I'm looking at right now.
Can't comment on anything else, though.
tyre
It’s insane that Spotify on Mac doesn’t support airplay.
When my girlfriend and I moved in together, we got rid of her Alexa devices because privacy and use HomePods. But Spotify doesn’t work with AirPlay for reasons I cannot fathom, so I set her up with a program that will AirPlay specific applications on her Mac.
That said, there are open source libraries and clients for AirPlay so it shouldn’t be too difficult to get them supported. I have a Raspberry Pi for streaming to “dumb” speakers.
bleachedsleet
Airfoil [1] is worth every penny. The same could be said for pretty much everything Rogue Amoeba makes.
It’s also worth noting that Spotify can act as a remote for its own service across devices. So you can start a song playing on your phone and direct the output over AirPlay and then just interface with that session using the desktop client.
geraneum
If I understood your problem correctly, you need to listen to Spotify through your HomePod which is on the same local network as your Mac.
This is what I do on macOS. I press on the little megaphone icon (enable it in OS sound preferences) in menu bar and then I can choose my HomePod from the list, without any third party software. I am running Big Sur but in two previous versions I also did the same. Maybe I’m missing something here but I think it should work seamlessly.
nonninz
That routes all the audio from the mac though, not only Spotify. And with a noticeable delay.
This makes watching a "GIF" with audio (say browsing Reddit), opening a video, answering a slack call, etc. a very bad experience.
Spotify by itself supports its own protocol, whatever that may be, and chromecast. The iOS app should also support Airplay through the OS.
Personally I have a Spotify enabled receiver plugged to my audio system, it works really well.
jazzyjackson
I don’t understand, not a user of Airplay - your Mac doesn’t have a way to stream to airplay devices? Why does it come down to the app?
mrweasel
The Mac can use the Airplay device as an output device, but it's not ideal, because that will send ALL sound to the Airplay device.
The correct solution is for the application to support Airplay, so that for instance Spotify can stream music to your Airplay device, while the Mac sounds still goes to the speakers of the laptop/iMac.
gonehome
I gave up on Spotify because of this - and because of their hostile moves to turn podcasts into another centralized service.
Apple Music is still mostly worse without discovery, but at least lossless makes up the quality difference that use to be there.
dangravell
Got me thinking. I wonder how much scope there is to build apps for platforms like Spotify which are built around a given use case.
For example - for people that prefer listening to albums. Or people that only care about political podcasts. Or something. I wonder if the global audience is enough to support indie products like this.
Significant platform risk though.
mackrevinack
i don't like this podcast stuff either. even just the homepage that displays artists (that i will never listen to) is enough to annoy me. i would really love an option to open directly into my playlists or something else. im building up a local music collection at the moment so its not going to be annoying me for too long more
andrewmcwatters
I love seeing software like this, even if it's not legal. Who cares? I remember being a teenager and trying out all sorts of cool underground, fundamentally illegal software, or stuff that worked around Terms of Service.
Where would the world be today without Napster? Maybe the same place, but provocative software is the definition of cool.
jazzyjackson
Nothing illegal about it, Spotify has a well documented API and supports third party clients
laserbeam
Eh. Ish. They only support playback within a browser and have deprecated native playback support years ago. Also their ToS technically doesn't let you do a looot of things you may want. Like caching. Srsly, you're not allowed to cache things. Many 3rd parties stopped supporting spotify because the dev ToS kept getting worse.
Regardless, I'm excited about this little project even if it goes against the ToS.
jazzyjackson
Hmm it was years ago but I remember now my chatbot was controlling the playback session in a browser, you’re right.
sunshineforever
So does this version not have advertisements or something?
laserbeam
You still need to log into spotify to use any 3rd party app and none of the playback apis will work without a premium account. Apps like this one are for people with premium accounts.
BoxOfRain
Things like Napster have a long tradition dating back to the 1960s, in the UK the response to the paternalistic and stuffy state monopoly on music broadcasting was for people to put studios and transmitters on ships parked just outside of British territorial waters. That’s really what fuelled the explosion in British music!
gjs278
people on here care about laws too much. it's a api/webscraping tool redisplayed a gtk window. nobody is going to go to jail. even if they dmca it someone should just host the sources on anything other than github and let it ride. people cheat at videogames all the time, they can cheat on a music client.
toothbrush
Running the risk of being a dirty reposter and.. reposting. My little Spotify client is for macOS only, mostly only built for my own use, and a lot more minimal, visually. It's also native Swift though, so it's got that nice macOS feel. It's also pretty much 100% keyboard-driven (Vim keys, if that's something you like) and supports regex filters. It's just an open-source thing: https://github.com/toothbrush/Spotiqueue
dorian-graph
I like this! Thanks for (re)posting it.
PascLeRasc
I love this! Thanks for making it.
tiew9Vii
This is good to see.
It shows you can write native cross-platform apps that are fast and have low system resource usage instead of the now default, packaging your app in a standalone resource-intensive web browser, aka Electron.
It's a shame we have a handful of people who can do this as a hobby project yet multi billion dollar companies with the money and manpower to do this don't, they chose Electron.
dropofwill
Druid is still not ready for prime time though (https://www.areweguiyet.com/). Played with psst for a bit: no keyboard shortcuts, no screenreader support, scrollbar feels 'off', stuff that just works if you use a native toolkit or a browser.
I get that this is early days for this project, but the issues are general for all of these non-browser, non-native UI toolkits. Hopefully we get there though.
jpochyla
Hi, the author here. Keyboard navigation is definitely something I'd like to focus on soon, the app should be 100% usable without a mouse. And accessibility is definitely on the Druid roadmap! <3
raphlinus
Keyboard shortcuts should be doable, I don't think this is a limitation of the toolkit.
Obviously screen readers are an important step, but we hope to be working with AccessKit.
In any case, though I'm not trying to represent Druid as ready for production use, I love seeing stuff like this. I think it's a good sign of what's possible and where things are headed.
mkj
Trying psst here on Linux I came away with the opposite impression - Druid's further along than I expected, it Just Worked at high DPI on Wayland better than most electron apps. I guess it'd feel worse on MacOS which already has a more consistent system UI.
artursapek
We are (I hope) helping solve this problem at Kraken. We sponsor development of the iced library, which we're using to build https://cryptowat.ch/desktop. It's supported on Windows, Mac, and Linux and has received a ton of positive feedback about how fast and light it is. I have hope for the future, and don't expect Electron to stay dominant forever. Native GUI apps are slowly coming back.
globular-toast
Why do people keep forgetting this? You can use Qt to easily build a "fast" GUI that works on all platforms. And you can do it with Python via PyQt. No complicated C++ or Rust, unless you actually need it (which this almost certainly does not).
Picard is a good example of a PyQt app: https://picard.musicbrainz.org/
I suspect the real reason is that web developers are seen as a dime a dozen and GUI programmers more specialist and hard to find. This was the main reason my team chose to do an Electron app. We were already doing React on the website and nobody had any experience with Qt.
ramesh31
>It's a shame we have a handful of people who can do this as a hobby project yet multi billion dollar companies with the money and manpower to do this don't, they chose Electron
This is a purposeful decision though. How else could they track a thousand different metrics about you without 20mb of Javascript?
brundolf
Why would an Electron frame allow them to track you more easily than a native desktop app that has access to your whole (userspace) system?
pritambaral
Not your parent. Just clarifying.
1. Electron apps also have access to "your whole (userspace) system".
2. Electron has npm, which makes it ridiculously easy to add analytics code to your app. See, for example: https://www.npmjs.com/package/electron-analytics
zingplex
If it's just for tracking, why not ship a JS runtime and run the tracking in a separate thread. No electron needed.
pritambaral
Too much work. With Electron, one can just `npm i electron-analytics` and done. Without Electron, libraries like that will have to be patched (at least) to be usable with the custom runtime.
stjohnswarts
but electron does have a JS runtime included?
tomc1985
Oh, don't forget the legions of cheap javascript newbs fresh out of boot camp that they can hire!
undefined
Vespasian
I'm going to give it less than a year now that it has been featured on HN.
This is too user facing and too easy to modify for DRM circumvention (if it isn't already doing that)
Whether it dies through a DMCA takedown or harder DRM measures remains to be seen.
I'm always sad to see people investing lots of time into creating great software that exists in a legal dark grey zone and will inevitably be nuked.
And yes I'm also not happy with the standard Spotify client
codetrotter
> harder DRM measures
Is that even possible for Spotify at this point?
The OP project is speaking to Spotify servers through the same means that official clients are, but the official clients are not just on iOS, Android, macOS and Windows.
There’s official Spotify clients on almost every platform imaginable. Everything from PS4 to built into TVs. And even a lot of stereo systems have Spotify Connect built into them.
Spotify Connect works by having these other devices streaming and playing the media, and your computer or phone acting as a “remote” for choosing the songs to be played. See https://www.spotify.com/us/connect/
Basically they’d have to break a lot of official clients, many of which probably cannot be updated, if they were to change their DRM scheme. How do you update a receiver for example? Well, you might be able to flash a new firmware with a USB stick. But for regular people, they are not going to do that. And the DRM scheme, at least as of yet, would be defeated by the reverse engineers as DRM always is. And hopefully continues to be.
So at least as of yet I think they would hurt people with official clients more than they would hurt anyone using an unofficial client.
And even people using unofficial clients are probably paying customers.
Besides what’s the point anyways, everyone knows that if you really really want to rip audio you don’t need to circumvent any DRM at all. You can play the song on your computer or your phone and take the analog signal that is going to the speakers and digitize it again and make an imperfect but still good copy of any audio. Admittedly it doesn’t scale anywhere near as good as automatically stripping DRM though.
jeroenhd
Music publishers could demand better DRM in their contracts, though. That would lock out any devices incapable of receiving DRM updates, but it's certainly a possibility. If Spotify would refuse to budge, their platform would lose access to a lot of songs. If they agree, their users would have a terrible experience, only being able to play some songs on some devices.
In order for Spotify to have any decent user experience, they need to nip any DRM bypass as scale in the bud before the publishers find out, through cease and desist or worse. If better DRM becomes the only solution, everyone loses.
The difference between official and unofficial clients is that Spotify can have some (contractual) power over the official clients, like demand that music is cached encrypted, demand a certain limit for cached music, etc. Unofficial clients aren't bound by any contract, so the developers could easily do something they shouldn't be doing according to the terms and conditions Spotify lays out (or the terms and conditions of the copyright holders that Spotify must uphold).
GOATS-
> Is that even possible for Spotify at this point?
Spotify are using Widevine on their web client, which is considerably more annoying to deal with than the encryption method used in the files fetched by Psst.
Nothing is stopping them from only serving files from the endpoint that serves Widevine protected files.
Then again, Widevine L3 has been broken[0], Google just keeps rotating the private keys used in the content decryption module.
BrokenDesktop
Something is stopping them: all the old devices that already know how to speak Spotify.
Spotify is built on bringing your music library with you everywhere. If your car or five year old stereo stops being able to play spotify songs, why would you still pay for a Premium account? 2% loss doesn't sound like much, but at Spotify's scale, that would mean loosing 2 million paying customers. If they pay $5 /month, that's not pocket change.
ramesh31
This is a great point. It's truly no different than a third party manufacturer writing some device firmware to connect with Spotify.
vladvasiliu
But as a sibling has posted, this is a posture / plausible deniability thing.
I've looked it up a few years ago, so this may have changed, but at the time you couldn't just ask Spotify for the SDK / docs to build your own Connect client. I don't remember the details, but you'd have to jump through some hoops, at which point I stopped looking since I wasn't about to build anything industrial. I expect some terms would be that you'd at least try to protect the keys.
bob1029
DRM for audio is so laughable. Any bit of patience allows for even the most rookie of users to rip a track from spotify.
If it weren't for all the legal agreements with copyright holders, I feel like spotify would already have an open playback API.
56h4h4h
The name of the game is risk mitigation. In this case, there are lots of ways to rip a singular track. They are usually slow because you record the audio stream from Spotify.
But if you could get the original file from Spotify's servers and decrypt it yourself, you could automate downloading your entire library, offline forever at source quality DRM free. Unfortunately, that is illegal and Spotify is going to dick them with lawyers. Pretty sure that's what happened to this project: https://news.ycombinator.com/item?id=25017167
History: after the developer decided to pivot from only being a tool to scrape the encryption keys needed to decrypt an individual song, the developer decided it would be a good idea to build in automating the downloading and also decryption of those files, instead of letting people develop that as a separate tool.
Developer and project has disappeared shortly after that decision.
1vuio0pswjnm7
Archive.org still has copies.
fabianhjr
> source quality
Spotify does at most MP3 320kbps, source quality would imply something like lossless FLAC/AAC
dawnerd
Rdio had an api that let you playback songs with a valid user token. It was really sweet.
Qub3d
Anecdotally, the only other Spotify UI I've seen on HN is still going strong after 2 years: https://github.com/Rigellute/spotify-tui
Vespasian
They don't break the DRM and use the official WebAPI.
> This app uses the Web API from Spotify, which doesn't handle streaming itself. So you'll need either an official Spotify client open or a lighter weight alternative such as spotifyd.
Qub3d
This app does, too. It uses aspotify[0], which is just a rust spotify API wrapper.
Brian_K_White
I've been using pianobar and pithos and pandoroid for my paid Pandora account for over 10 years.
thebean11
> This is too user facing and too easy to modify for DRM circumvention (if it isn't already doing that)
How?
Brian_K_White
Google "pianobarfly"
stjohnswarts
You realize there are other unofficial spotify clients and have been for years don't you?
bluepizza
They do not exist in a legal grey zone. Spotify has open APIs. Using them is allowed.
nfd
librespot is a reverse-engineered thin client (using the same api that e.g. your "smart speakers" would). It doesn't use official APIs, arguably violates DMCA, and you pretty much have to use it if you don't want to simultaneously run the full thick official client on the same device at the same time.
numlock86
> Psst: Fast Spotify client with native GUI, without Electron, built in Rust
I wonder what's faster: The new GUI, linked user accounts getting suspended or the project getting legal issues with the result of being taken down.
¯\_(ツ)_/¯
No, seriously. I support projects like this. But they pretty much always end the same. It's always sad to see so much effort go into waste. I get the motivation but I think there are a lot of other things to spend this kind of work on other than somethings that breaks a service's TOS from just reading the title.
ubercow13
This uses the same API as libspotify, a library for accessing Spotify for playback that Spotify released themselves. It’s not been supported for a while so future support for this API is unclear, but it’s not clearly going to be shut down like you suggest.
Apple Music also has an official and maintained API for building third party clients.
bluepizza
Spotify API is open. He is not breaking any ToS.
fleddr
I think the idea of desktop apps being web apps repackaged is now so ingrained that some people have never experienced true desktop app performance.
As in, zero latency, or no observable latency. Instant performance. Honestly, it sickens me how spectacular advances in hardware translate into performance being worse than before.
Even the Office client apps are now web (React). And you can tell. Sluggish and glitchy.
As for the Spotify app, I have little love for it. Overengineered garbage where the simplest actions leave you searching. Internally, they have created this massively complex structure of squads and tribes each taking care of just one tiny part of the experience. This may explain why Spotify is so disconnected and makes no sense.
All of this engineering effort, I imagine there to be at least a few hundred working on it, ultimately add up to an experience less usable than bloody Windows Media Player from the 90s.
shp0ngle
MS Office is React now? Wow. Does not surprise me though.
gruez
That statement's horribly misleading. The desktop versions (eg. windows or mac) aren't, but the web versions are.
fleddr
No, it's not misleading. The Office 365 desktop apps are written in React. As is Teams. As is Visual Studio Code.
Specifically, React Native for Windows. https://github.com/Microsoft/react-native-windows
For things like background services, they still use C/C++.
riskable
Just downloaded this to try it out... This is now my new Spotify client!
It's so damned efficient it barely registers in my CPU monitor. Check out the memory utilization too!
https://i.imgur.com/Fa3Dnnb.png
Now compare it with the semi-official Spotify client:
lostmsu
According to this: https://forums.overclockers.com.au/threads/winamp-memory-usa...
Winamp 2.72 only used about 8 megs of RAM.
dotancohen
Eight Megs And Counting.
Wow, eight megs was once so much memory that we would laugh about applications that even approached it.
TchoBeer
It's really crazy how quickly things have gotten bigger. I remember not too long ago my mid-high power computer had 1Gb of RAM, nowadays that would be laughably small.
jpochyla
Hi, I'm glad you like it! The performance is not _that_ good at the moment, mostly because of superfluous paints, but it's something I'd like to focus on (as it's one of the primary objectives).
rvz
So Electron is the problem. It gets worse if you have lots of tabs open in Chrome + running other electron apps as well. A visible and obvious improvement when compared with a native app.
Also, Electron apps do not scale and it wastes CPU time, eats RAM up and fills up HDD space. On laptops, it drains the battery faster.
A quadruple negative to the user.
userbinator
The second one should be sorted by name to show that there are actually multiple spotify processes. (There's another one near the bottom of the list.)
xyst
I wonder what the footprint will look like once the author writes in all of the missing features
jeroenhd
I've never given Spotify a try because of the crummy web/Electron player I saw everyone using. Wanted to try this out, but it only works with a premium account. That could've been mentioned more clearly, would've saved me the effort of compiling this thing.
I can't judge the main application but just the settings screen makes me feel like the UI library powering this isn't quite ready for prime time yet. I consider shortcuts and basic text handling like ctrl+a to select all text in a textbox to be basic features for any UI toolkit; the lack of such ease of use features really makes the GUI toolkit feel less native than the Electron cruft that's overtaking our desktops.
As for the legality, the DMCA sucks but this client is definitely in violation of it. Breaking the TOS isn't necessarily illegal so the tool is fine to use (at the risk of getting your account banned) but development can be quite risky. Hopefully, Spotify takes an interest and uses (a fork of) this project to write a faster player for their desktop clients instead of cease-and-desisting it to hell.
mimimi31
>it only works with a premium account. That could've been mentioned more clearly
I agree, although it looks like you only have to change a single line of code to make it work without a premium account. Might as well go all the way if you're already breaking the TOS anyway I guess.
fabianhjr
> As for the legality, the DMCA sucks but this client is definitely in violation of it.
How is it definitely in violation of the DMCA? (Not a lawyer and not a USA resident, would appreciate legal clarification)
jeroenhd
Any circumvention of DRM, even simple DRM as long as it's not too trivial, is considered illegal under the DMCA. The decryption routines Spotify uses should definitely be considered non-trivial DRM.
kxrm
Not who you replied to, but if anything decrypts a DRM stream in an unauthorized way, it technically is breaching DMCA. I assume that is what they meant.
cik
I've been running this for the last 5 hours, since I saw the posting. Thankfully, in arch it's just part of the aur.
Frankly, it's awesome. It's literally every single thing I dislike about Spotify fixed. There are no podcasts, I can search, there's no social senselessness anymore.. I'm thrilled.
The only problem I have is that eventually it just gobbles CPU. Having it open and doing nothing seems to take ~4% of my CPU, and while playing a constant 7.2%. Frankly, I assume this is decoding, but I haven't traced yet. Eventually it spun out of control and pegged one CPU at ~90%, which a quick restart fixed. All of this is to say it's an incredible project - I'm not going back to the old client.
Get the top HN stories in your inbox every day.
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.