American vision

How is Javascript used within the Spotify desktop application?

Answer on @Quora How is Javascript used within the Spotify desktop application? : JavaScript on top of C++ which handle files retrievals but JS handles GUI

Answer by Mattias Petter Johansson:

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 just 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.

If you like my writing, don't miss out on more of it – 
follow me on Quora and Twitter (http://twitter.com/mpjme)

How is Javascript used within the Spotify desktop application?

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s