This page may be out of date. Submit any pending changes before refreshing this page.
Hide this message.
Quora uses cookies to improve your experience. Read more

How is JavaScript used within the Spotify desktop application? Is it packaged up and run locally only retrieving the assets as and when needed? What JavaScript VM is used?

3 Answers
Mattias Petter Johansson
Mattias Petter Johansson, former Software Engineer at Spotify (2012-2017)

I would bet that the Spotify desktop client is among the top 25 most intricate uses of JavaScript in the world. The Spotify desktop client UI is completely built with JavaScript, resting on top of the same C++ core that the iOS and Android clients uses. The C++ core is responsible for things like playback, providing offline editing of playlists and local files, but rendering and interacting with the UI is handled by JavaScript. The communication between the C++ parts and JavaScript is done through a simple messaging interface simply called bridge. The UI itself is HTML/CSS, which is generated by Handlebars and LESS.

Spotify is internally divided into small (3-12 people) teams called squads. A feature is generally owned by a single squad, and during normal conditions the squad has all it needs to develop and maintain its feature. It's normal for a squad to have iOS, Android, web, and backend developers under its roof. The general idea is that every squad should have the ability to work on its feature pretty much on its own, minimizing the need for the squad to ask other parts of the organization for permission and/or help.

This organization structure, combined with the global-ish nature of JavaScript in the browser, has made us build the desktop client UI out of many small, self-contained web apps called Spotlets. They all run inside Chromium Embedded Framework, each app living within their own little iframe, which gives squads the ability to work with whatever frameworks they need, without the need to coordinate tooling and dependencies with other squads. While this approach has the disadvantage that we have many duplicate instances of different versions of libraries, increasing the size of the app, but it offers the massive advantage that introducing a library is a discussion between a few people instead of decision that involves ~100 people and their various needs. Not only would such a big discussion extremely time-consuming and hard, it would also force us to use a least-common-denominator approach to picking libraries, instead of picking the ones specifically tailored to the problem domain of each squad. Considering the size of a single song compared to the size of a JavaScript library, this trade-off is a no-brainer for us.

The latest versions of all Spotlets are zipped and bundled with the desktop client binary on every release, assets and all. However, we can also live-deploy new versions of the apps into the running clients of users. This is very useful for emergency releases, but we can also release Spotlets to certain user groups, such as employees or designated testers only. We can even release apps that aren't originally bundled with the client, which is very handy during our hack weeks, allowing us to quickly get apps into the hands of non-techie decision makers in the company. After demoing your thing, you end off with "and now type this uri into the search field of your desktop client, to try it out with your own account!". This whole system was originally invented as part of the now-defunct Spotify Apps initiative, to support third-party developers adding functionality to the client.

While teams are autonomous, there is functionality that we all would like to share because we explicitly want it to work the exact same way in all apps. For instance, we have a CSS framework called GLUE. It was originally a fork of Twitter Bootstrap, but we've diverged heavily from that over time. Generic functionality such as some list and buttons, we also provide shared components for, but it's very easy for squads to just use templates, or just partially use functionality from the shared frameworks. It's important that squads are able to control their own reality and can pick the best solution for their problem domain, instead of having a company tool forced down their throats just because it's in-house.

We use npm extensively. We have our own internal npm repository where we publish internal modules, and we package the code together using a Browserify-like tool. npm has been magnificent for us. For the browser-specific testing, we use Mocha and PhantomJS.

Shameless plug: If you like my ramblings about programming on Quora, you might enjoy my YouTube show: Fun Fun Function

Manjunath Hirapur
Manjunath Hirapur, Computer Geek, Network Engineer, Desktop Support Engineer, Microsoft & Cisco Certified Engineer, PC Solutio...
Your feedback is private.
Is this answer still relevant and up to date?
Felipe Ribeiro
Felipe Ribeiro, works at Spotify
All the JavaScript/HTML/CSS assets needed to run the client are bundled in the app and run locally.

They are responsible for the client UI, and the core functionalities like playback and talking to the backend (to fetch your playlists data and stuff like that) are handled by the native (C++) layer.

To render the Web interface of the client and make these two layers talk to each other, we use Chromium Embedded Framework.
Your feedback is private.
Is this answer still relevant and up to date?