On Third-Party Javascript - In Production Case-Study

Posted by Gergely Nemeth

23 December 2015

Note: this is a guest post by RisingStack co-founder Gergely Nemeth

Third-party JavaScript is a pattern of JavaScript programming that enables the creation of highly distributable web applications. Unlike regular web applications, which are accessed at a single web address, these applications can be arbitrarily loaded on any web page using simple JavaScript includes. — Ben Vinegar, Anton Kovalyov (Third-party Javascript)

Google Analytics, Mixpanel, Disqus – just to name a few products that heavily rely on third-party JavaScript development.

This is the second part of the “On Third-Party JavaScript” series, the first one dealt with the very principles you have to understand when dealing with third-party JavaScipt.

In this post we are going to take a look on how companies out there solve the challenges of third-party JavaScript development.

Disclaimer: we do not work for any of these companies (as of the date publishing this post), so the findings here are based purely on reverse engineering.

The Mixpanel Way

Mixpanel is a company that provides an analytics platform that can be integrated with your web applications – so they heavily depend on third-party JavaScript.

Integrating with Mixpanel

To integrate with Mixpanel the very first step you have to do is include the following snippet in your HTML’s head section:

After this you can use the full power of the library – but what happens behind the curtains? This tiny include snippet only does the following:

Size, cache policy

The full mixpanel library is only 16.2K – so far so good. Check.

Regarding the distribution: Mixpanel uses Akamai as their CDN provider. Check.

Mixpanel sets the Cache-Control:public, max-age=3600 header on their library. This tells the browser to keep the current version for 3600 seconds (1 hour) then download it again. This, combined with the 16K in size can have a huge impact on both their Akamai bills and the users bandwidth usage (no, not in a good way).

Things to improve at MixPanel

The Disqus Way

Disqus is a great tool for connecting the audience of a website or blog and start a discussion on each content. Unlike Mixpanel, Disqus has to take care of a user interface as well.


Integrating Disqus is pretty straightforward:

Let’s take a closer look!

The very first thing you will notice is the configuration variable – it is used to initializes Disqus to work with your site. What comes after that is very similar to Mixpanel – the loading of the main application’s JavaScript file. Also, pay attention to the <noscript> tag – if a user does not have JavaScript support, it will give him/her a warning.

The mechanisms behind Disqus

The embed.js file is what the small include snippet will require – this is relatively small, and has a very short cache lifetime set: 300 seconds. This file contains some basic configuration, like the version of Disqus you are using. This information is then used to fetch more resources the application needs. This setup works really great, as only the embed.js has to have a small cache period set, other resources can be cached for a really long period of time.

For configuration management they are using a config.js file which is cached for a very short amount of time to enable rapid changes in the configuration. This file contains settings on how Disqus will appear – but not just that: it contains feature flips, and service discovery information as well.

Disqus not only loads static resources with embed.js, but modules as well, staring with lounge.load.js. For this, they are using AMD, which stands for Asynchronous Module Definition. The library that helps them is RequireJS. These modules are referenced with a unique version/commit tag, so they can be cached for eternity – if they want to roll out a new version only some configuration has to be updated, which will mean a new URI for the resource.

CSS and images files are handled in the very same way: they are versioned, and cached for a month. To send images to the client Disqus uses sprites to minimize the number of requests the client has to make.

A summarized overview of what is happening:

disqus script

One more thing about the implementation of Disqus – bug tracking! They use Sentry to collect and report JavaScript errors – you should give Sentry a try as well.

Things to improve

The Disqus team made an incredible job developing their product, hats off! The only thing I could come up with is that they include snippet leaks the disqus_shortname variable into the global scope. A possible way to solve this:


Building third-party JavaScript is a hard task – but there are companies out there who made a great job solving this. When in doubt, you can always try to examine how they do things, so you will have options to choose from.

UPDATE 1: Disqus uses their own “smart” file versioner, which can be found here: https://github.com/disqus/grunt-smartrev. Thanks!

Need help in developing your application?

RisingStack provides JavaScript development and consulting services – ping us if you need a helping hand!

This post previously pubished at RisingStack’s blog.

comments powered by Disqus