22 ms·

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

by mythz 5y 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.

judge2020 5y ago
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 5y ago
  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.
  - runawaybottle 5y ago
    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.
    - SilverRed 5y ago
      None of the competitors care about making the ui 20ms faster. Apple music just flat out didn't work for me, totally broken for the web version and not even an electron app. Spotify is already better than the alternatives.
    - westoncb 5y ago
      Absolutely. Anyone building on top of performance critical systems should have a healthy bit of gratitude for the engineers who were interested to specialize there. That said, I think it's good to remain as objective as possible about the actual impact of optimizing for performance in different domains. So for instance, the impact of attention paid to performance in the codecs used by a music/video player, or the v8 runtime, or rendering or networking subsystems in e.g. macOS or Chromium is huge. However, should we expect the impact of optimizing to be similar in application-level code for consumer apps? I would argue no (granting that exceptions exist). At this layer the computations are for business and display logic, and calling into highly performant subsystems. Additionally, they are typically 'leaves,' not dependencies of other systems (which would cause their performance choices to ramify). This is not to say consumer apps are able to ignore performance concerns: you can still make garbage that way. But you'd be deep into the region of diminishing returns if you poured as many resources into performance for application-level code on something like Spotify as you did on e.g. codecs it uses or low-level rendering code it depends on. And that's the reason tech like Electron is so often selected by folks whose bottom line is massively affective by their ability to be objective about these issues.
amerine 5y ago
Rdio's app was stunning compared to Spotify imo.
- montag 5y ago
  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.
slumpt_ 5y ago
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?
- cjblomqvist 5y ago
  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)
  - slumpt_ 5y ago
    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.
    - rzzzt 5y ago
      Can it send e-mails?
  - zwaps 5y ago
    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.
    - 5y ago
tjbiddle 5y ago
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.
ap-andersson 5y ago
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 https://pca.st/cbo7khrm Here's also a blog post related to the topic: https://engineering.atspotify.com/2021/08/04/four-lessons-we-learned-from-creating-spotifys-desktop-app/ https://engineering.atspotify.com/2021/08/04/four-lessons-we...
- mythz 5y ago
  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=d8695b5f4e58491c 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.
spullara 5y ago
I really don't know what yall are going on about. I hit play on a song in spotify and it just plays instantly.
ClawsOnPaws 5y ago
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.
- miki123211 5y ago
  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.
- jpochyla 5y ago
  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 https://github.com/hrkfdn/ncspot [2] https://github.com/Rigellute/spotify-tui https://github.com/Rigellute/spotify-tui [3] https://github.com/xou816/spot https://github.com/xou816/spot
jcelerier 5y ago
> Our QT/C++ client had decent performance but was noticeably heavier than Spotify's. Wasn't Spotify's client Qt too ?
- deleted 5y ago
  [deleted]
- mythz 5y ago
  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-built-in 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-lightweight-well-designed-desktop-application-What-is-the-technology-behind-it 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
  - jcelerier 5y ago
    TIL, I only ever used it on Linux and assumed it was the same everywhere
djhworld 5y ago
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.
miki123211 5y ago
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.
MasterYoda 5y ago
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 5y ago
  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.
stayfrosty420 5y ago
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.
twobitshifter 5y ago
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.
matheusmoreira 5y ago
> unauthorized clones Are we really living in a world where we need "authorization" to replace some corporation's software with our own?
huhtenberg 5y ago
> 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 https://en.wikipedia.org/wiki/Ludvig_Strigeus
cronix 5y ago
> 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 https://www.youtube.com/watch?v=MKJjLwMUPJI
ilrwbwrkhv 5y ago
Even on the iPad app they don't follow basic things like swipe left on the edge to go back.

by mythz 5y ago

judge2020 5y ago

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 5y ago
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.
- runawaybottle 5y ago
  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.
  - SilverRed 5y ago
    None of the competitors care about making the ui 20ms faster. Apple music just flat out didn't work for me, totally broken for the web version and not even an electron app. Spotify is already better than the alternatives.
  - westoncb 5y ago
    Absolutely. Anyone building on top of performance critical systems should have a healthy bit of gratitude for the engineers who were interested to specialize there. That said, I think it's good to remain as objective as possible about the actual impact of optimizing for performance in different domains. So for instance, the impact of attention paid to performance in the codecs used by a music/video player, or the v8 runtime, or rendering or networking subsystems in e.g. macOS or Chromium is huge. However, should we expect the impact of optimizing to be similar in application-level code for consumer apps? I would argue no (granting that exceptions exist). At this layer the computations are for business and display logic, and calling into highly performant subsystems. Additionally, they are typically 'leaves,' not dependencies of other systems (which would cause their performance choices to ramify). This is not to say consumer apps are able to ignore performance concerns: you can still make garbage that way. But you'd be deep into the region of diminishing returns if you poured as many resources into performance for application-level code on something like Spotify as you did on e.g. codecs it uses or low-level rendering code it depends on. And that's the reason tech like Electron is so often selected by folks whose bottom line is massively affective by their ability to be objective about these issues.

amerine 5y ago

Rdio's app was stunning compared to Spotify imo.

montag 5y ago
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.

slumpt_ 5y ago

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?

cjblomqvist 5y ago
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)
- slumpt_ 5y ago
  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.
  - rzzzt 5y ago
    Can it send e-mails?
- zwaps 5y ago
  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.
  - 5y ago

tjbiddle 5y ago

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.

ap-andersson 5y ago

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 https://pca.st/cbo7khrm Here's also a blog post related to the topic: https://engineering.atspotify.com/2021/08/04/four-lessons-we-learned-from-creating-spotifys-desktop-app/ https://engineering.atspotify.com/2021/08/04/four-lessons-we...

mythz 5y ago
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=d8695b5f4e58491c 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.

spullara 5y ago

I really don't know what yall are going on about. I hit play on a song in spotify and it just plays instantly.

ClawsOnPaws 5y ago

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.

miki123211 5y ago
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.
jpochyla 5y ago
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 https://github.com/hrkfdn/ncspot [2] https://github.com/Rigellute/spotify-tui https://github.com/Rigellute/spotify-tui [3] https://github.com/xou816/spot https://github.com/xou816/spot

jcelerier 5y ago

> Our QT/C++ client had decent performance but was noticeably heavier than Spotify's. Wasn't Spotify's client Qt too ?

deleted 5y ago
[deleted]
mythz 5y ago
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-built-in 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-lightweight-well-designed-desktop-application-What-is-the-technology-behind-it 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
- jcelerier 5y ago
  TIL, I only ever used it on Linux and assumed it was the same everywhere

djhworld 5y ago

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.

miki123211 5y ago

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.

MasterYoda 5y ago

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 5y ago
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.

stayfrosty420 5y ago

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.

twobitshifter 5y ago

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.

matheusmoreira 5y ago

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

huhtenberg 5y ago

> 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 https://en.wikipedia.org/wiki/Ludvig_Strigeus

cronix 5y ago

> 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 https://www.youtube.com/watch?v=MKJjLwMUPJI

ilrwbwrkhv 5y ago

Even on the iPad app they don't follow basic things like swipe left on the edge to go back.