I might be misremembering, but I swear when Spotify launched it was a big revelation at the time because the client was super fast and playback was almost instantaneous. This was a big deal as other music players like iTunes were bloated.

Obviously streaming was the big selling point, something that iTunes didn’t offer at the time, but I swear the client was written in some native UI framework, along with the C/C++ library.

Or was the spotify UI always just a browser engine skin and the perception of speed was from the playback engine?

Anyway, cool to see projects like this

Ludvig Strigeus https://en.wikipedia.org/wiki/Ludvig_Strigeus?wprov=sfti1 wrote the original client, and fast, lean, native clients was his modus operandi. OpenTTD and uTorrent were both built the same way. I’ve been wondering on and off over the years why Spotify abandoned it. My guess is that it was hard to scale that approach and that a hybrid browser client was easier to scale when there are many different engineering teams working on different parts of the client.

I found a talk with some history of the Spotify client's transition:

https://www.youtube.com/watch?v=9UsnX5X_DF0

It was originally native, then native with some web-based bits, and then the web-based bits slowly ate the whole thing. It seems the ease of development with web-tech compared to C++ (also the better font rendering and screen reader support) was just too tempting.

Interestingly the Spotify client was never based on electron but instead arrived independently at the "chromium + web app" architecture at around the same time as Atom did.

You're remembering correctly.

https://news.ycombinator.com/item?id=28203654

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.

(The comment is from a 2021 post about another Rust-based Spotify client.)