[noxToken]

Add to that the massive start-up time for the Windows client. A fresh instance Spotify from a rebooted machine takes ages to gain full functionality. If you quit in the middle of a good playlist, most of the time you'll be able to continue playing from where that playlist left off. If you opened Spotify to find a song or move to another playlist, you'll be waiting a while.

I just started Spotify with a stopwatch:

2:26 for the main Browse to completely render

2:42 for the live search window to give suggestions

2:52 (+10 seconds) for the search to return a result

I once thought it was because of the massive local library that had to be loaded and sorted into Spotify, but I've done away with local files to try to speed up the start up. The results on my laptop are not any better. Maybe it's because I've been updating the same client since 2012?

[1_player]

Wow.. I agree that Spotify isn't the most lightweight application, but it doesn't feel much heavier than, say, Chrome on my Linux installation.

Are you on a mechanical hard drive perhaps?

The network performance though is quite bad, searching for some song often fails or just is very slow to load and render.

[wlesieutre]

Should a music player be anywhere near as heavy as Chrome? A web browser is a pretty immensely complicated thing (CSS, DOM rendering, Javascript JIT compiler, etc.).

Similar criticisms have been made of iTunes over the years (though I find it's not bad in the current version). Things like laggy scrolling are a bit understandable there, since they've defaulted to the grid of album covers view for a while. But Spotify looks like it's all just columns of text and a few thumbnails on the side?

[JohnTHaller]

Considering that a good many "music player" are basically written atop browser rendering engines... they're equivalent in some ways. Plus, they have the added overhead of checking tens of thousands of files for changes (if they do so on each start as some do).

[91bananas]

I assume this thing is just a web app rendered in their "browser"? So doesn't it need to do all the things you list? Needs css to layout the DOM, needs to parse and execute javascript.

I'm a recent convert from grooveshark, so I've been using the spotlight web player and I find it a pretty nice web app to be honest. I haven't dealt with any of the actual desktop clients yet, so don't know if anything I said above is true.

[detaro]

> I assume this thing is just a web app rendered in their "browser"? So doesn't it need to do all the things you list? Needs css to layout the DOM, needs to parse and execute javascript.

From a users perspective, that is an implementation detail and doesn't matter. A users only cares if his music player feels slow or not.

[wlesieutre]

Yes, it appears to be developed on CEF, which could explain the slowness.

"We decided to develop it on HTML and JS" is a lame excuse for slow mobile apps, and IMO it's even worse on desktop.

Related: http://techcrunch.com/2012/12/13/facebook-android-faster/

[to3m]

It would take a bit more than using a hard disk rather than an SSD to create a 3 minute load time. It must be downloading the entire program over the internet every time.

[goldfire]

Something is wrong there. I just tried the same tasks on my system; from clicking the shortcut to the Browse view rendering was 5 seconds, the live search displays suggestions almost as fast as I can type more characters, and the full results appear within a second. I am running it off an SSD, but that's not enough to account for all that time. I don't have a guess what it is, but something else is going on.