[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/