Choosing a Javascript charting library in 2016

Given the overabundance of tools available to a Javascript developer in 2016, finding and choosing the right one is often a challenge.

Especially when it comes to visualising data, either drawing animated charts or implementing custom interactive infographics, the choice becomes harder since there are a lot of tools out there: Wikipedia’s “Comparison of Javascript charting frameworks” currently lists 44 different libraries, currenty stands at 72(!) different charting tools and – to make matters worse – the Google search result for “best javascript charting libraries” over-delivers with approximately 786K results, out of which the first 20 results are all links with titles like “{{integer in multiples of 5}} best javascript libraries”.

Naturally, most of the relevant Stackoverflow questions of the”what is the best tool” nature are “closed as not constructive”.

In this article I aim to help with the above challenge by means of a slightly unconventional approach: In my research I tried to quantify the merits of the most popular libraries, given a series of “developer-friendly” metrics.

Sounds weird and subjective? It is. Read on.

Step 1: Understanding declarative vs imperative approaches

Before we start comparing, it is essential to understand how almost all of the available libraries can be split into two distinct categories based on their approach. Let us borrow from classical computer science and use the “declarative vs imperative” paradigm comparison for this.

The declarative approach

The majority of JS charting libraries follow the declarative paradigm: You write code that describes what you want to end up with, and the library ensures it happens dealing with all the minutiae.

FusionCharts, Highcharts, amCharts, Chart.js etc. all follow this approach: You pick a chart type (column, bar, pie), you specify a configuration object and the library outputs a nice looking interactive chart based on your wishes.

The imperative approach

On the other hand, tools like D3.js, Paper.js or Snap.svg follow the imperative paradigm. They provide you with helper methods which you then need to use to write code that visualises your data step-by-step.

For example, to create a bar chart with D3.js you will need to initialise the canvas, calculate where to draw the axis, draw the axis, calculate where to draw the columns, draw the columns, the legend, the point data, add the events etc.

It does feel a little counter-intuitive to choose any tool that follows the imperative approach, until one sees the amazing work implemented by Mike Bostock (creator of D3.js) for the New York Times, with animated interactive infographics such as the 2012 “512 Paths to the White house” to understand how powerful a library like D3.js can be.

In the next step I made an effort to establish “winners” in each of those two categories.

Step 2: Quantify the popularity of each tool

2.1 Mentions in Google articles

One needs to start from somewhere so my first step was to revisit the “best javascript charting libraries” Google search, filter out to show results only from the past year, open the first 20 hits (first two pages) and note down which libraries were mentioned.

95 libraries in total – see the “Mentions” tab of this Google sheet for a full reference (it’s the first tab – and yes, there exists a library called “Aristocharts”. Seriously).

I then filtered out the list to include only the libraries with at least 4 hits:


Some surprises here already. No amCharts? No mention at all of Paper.js or Snap.svg? Interestingly, the fact that N3-charts “made the cut” here can be construed I believe as a testament to the popularity of Angular.js.

What comes as no surprise is the popularity of D3.js. It is also the only library in this list that follows the “imperative” paradigm making D3.js the clear choice when it comes to that approach. I marked D3.js as the “winner” in the imperative category, filtered it out and continued.

2.2 Licensing

Next step was to establish the license of each library. Many developers are partial to tools that are either open source or come with really relaxed licensing.


Some reading is involved if one wants to make sense of Google custom license for their “Charts” library (it’s free with a lot of caveats). Interestingly ZingChart offers a free (albeit watermarked) version of its library.

Please note that personal bias prevented me from filtering out the commercial offerings at this stage. I’ve used both Highcharts and FusionCharts in the past to great success and as a result I opted to not judge based on price – until I had all the metrics that is.

2.3 Github stars and watchers

Does the library have a repo in Github? And if yes, how many people are watching, how many have starred it? I intentionally steered clear of other Github measurements such as number of contributions or PRs since each repo has owners and each owner has his / her own personal approach towards how “open” they are to contributions.

On the other hand, a project’s star rating is a clear indication of how many developers (rather than simply users) “like” it. The “Watch” metric also tells us the number of devs who actively want to be notified when new things happen in the project.

javascript charting library

Google Charts had a few github repos but they were for projects that wrap / package their “Google Charts” project, e.g. GoogleWebComponents.

Two things stood out for me in the table above. The massive community support for ChartJS  – almost the same number of stars as Backbone.JS (!) – as well as the number of people who are watching Chart.js.

What is also surprising is that out of the three commercial offerings, Highcharts number of stars is orders of magnitude higher than the rest.

2.4 Stackoverflow tagged questions

Another metric that can tell us how many people are using a library is to see the number of questions that are “tagged” in stackoverflow for a specific library.

This is not foolproof – one might argue that extremely well designed and structured libraries will be so intuitive in their use that people will not be asking questions about them – but my personal experience has shown that even the simplest of tools generate a lot of questions when used by a lot of people.

javascript charting library comparison

Is Highcharts the most difficult library of all? Or is it perhaps the most widely-used one? Perhaps its developers are extremely responsive to the questions of the community? We cannot answer this with 100% confidence. What these counts show however, is that highcharts has more tagged questions in Stackoverflow than all rest of the libraries combined.

Choosing the winners

Since I’ve already opted for a (completely) subjective approach, what better way to pick a winner by simply…. adding everything up.

Here are the top 5 libraries sorted by “Score”, i.e. the sum of github stars, github watchers and stackoverflow tagged questions:

javascript charting library comparison

Full data available on the “Final results” tab of this Google sheet.

Declarative approach – Open source – Chart.js

If the Github stars are anything to judge by, there is a lot of developer enthusiasm for what Chart.js offers.

The documentation is clear and concise – – with several inline examples, browser support is solid (as long as <canvas> is supported chart.js will work – this means no IE8 and some inconsistencies on <= IE 10) and the 8 chart types it offers should be more than enough for most needs.

Declarative approach – Commercial – Highcharts

I’m an avid user of Highcharts and I was pleasantly surprised to see it “rising” in the ranks of my little quantitative experiment. The massive number of stackoverflow questions clearly signifies that despite its commercial nature, the community uses it… a lot. The high number of github stars – (I repeat: for a commercial project) – is also quite indicative of the “developer feelings” for Highcharts.

The documentation is stellar (with a really powerful “Demo” showcase where every single example is linked to a working JSFiddle), the API browser / reference is a great resource and browser support is not an issue since Highcharts auto-falls back to VML rendering for older IE browsers.

Check out this JSFiddle to see how easy it is to visualise a table like the one shown in “Choosing the winners” above:

choosing a javascript ibrary

Imperative approach – Open source – D3.js

The central principle of D3 is to enable developers to programmatically construct SVG objects and render them as they see fit. As long as you can visualise it, D3.js can help you (a) draw it, (b) make it interactive and (c) animate it.

D3.js is the tool to use when a charting library simply won’t cut it. And the community demonstrates this very clearly:

Github stars – 54848
Github watchers – 2653
Stackoverflow tagged questions – 22036

If I had to score this the same way I scored the charting libraries, then D3 leaves everyone behind by a factor of 2 with a score of 79537.


Using Bash in Windows – today

using bash in windows today

“… However, when we talked with web developers, they still struggled with using Windows as their primary devbox.”

The above quote is from Kevin Gallo, the VP of Windows Dev platform, and was delivered around mark 0:38 of his presentation in Microsoft’s Build 2016 keynote. He then continued with the observation that “… many of them have workflows which rely on open source command line tools, scripts and frameworks”, and finished with a slide that his audience was – at first – slightly unsure on how excited to get about: Bash is coming to Windows.

Screenshot #1: Kevin Gallo’s slide from Build 2016 announcing Bash coming to Windows
Screenshot #1: Kevin Gallo’s slide from Build 2016 announcing Bash coming to Windows

If you let the video play for another 7 seconds, you’ll also catch a glimpse of Gallo’s audience. You can see the emotions depicted on their faces form a picture that explains perfectly the complex (and sometimes tumultuous) relationship of Microsoft with Linux and the Open Source world. Three persons are smiling excitedly and beginning to slow clap (the ones that suddenly realise how much easier managing their OS stack or scripting their Windows environment will become). You then have the classic cautious indifference of the majority of developers that wait to see whether this is “worth getting excited about”. Finally, you can also detect some unguarded annoyance from the fanboy crowd (“Seriously? I have to sit and hear about Bash? What’s wrong with PowerShell?”).

Personally, I belong to the first group. Despite working with open source technologies since the beginning of my professional career back in 2003, I’ve never managed to move away from Windows. To this effect, when I saw Rich Turner and Russ Alexander casually doing a apt-get install git on Windows to install git, I was excited. A lot.

But until the functionality showcased in the video above is mature and stable enough to be rolled out, I’ll continue using my current workflow which has served me faithfully since 2011: And that is bash on Windows (To be precise: A more “cut down” version of Bash. Read on for details).

The challenge: Production-strength command line workflow in Windows.

One might argue that Windows was never meant to be “driven” from the command line.

Microsoft tried to mitigate this back in 2006 by rolling out PowerShell, a shell and scripting language that gives users full access to their whole Windows environment. For Windows devs this was a great extra tool but for all other developers it was still not enough to lure them away from the power and versatility they found on the Linux command line.

Add to this the strongly opinionated naming conventions and approaches that PowerShell inherited from the .NET Framework (did you know that cd is but an alias to the “proper” command which is Get-ChildItem? That’s camelcase _and_ a dash that autocompletes with tab even if you type it in lowercase. Strange stuff) and you can see why it’s really hard for e.g. a PHP developer to consider it for his dev workflow.

When every single blogpost or article or tutorial written about a subject, e.g. “how to rebase branches in git”, includes instructions and screenshots that clearly demonstrate the flow in a Linux shell, it’s only natural for the developer to assume that this is the correct way of doing things.

Towards a solution: Install Git for Windows

For my frontend-with-a-bit-of-PHP-but-from-a-Windows-OS workflow I always relied on certain “battle proven” tools. WinSCP was the weapon of choice when files needed to be moved from one place to another (either via FTP, SFTP, SCP or even rSync). Putty allowed me to connect via SSH to all my dev boxes. TortoiseGIt ensured that I could use git directly from my Windows explorer interface.

The first “lightbulb / aha” moment for me occurred when I installed Git for Windows after being prompted to “try it out on the command line” by a colleague.
One of the steps of the install wizard prompts you to choose “How would you like to use Git from the command line?”:

Screenshot #2: Choosing how to use Git for Windows
Screenshot #2: Choosing how to use Git for Windows

… and it mentioned “Bash”!

Installation completes and suddenly I get a shell in Windows that looks suspiciously similar to what I’m used to in Linux or iOS installations:

Screenshot #3: MinTTY terminal emulator window
Screenshot #3: MinTTY terminal emulator window

Bash in Windows: How it works

Kudos? To the awesome devs that worked to bring Git to windows –
In essence the installer sets up a unix-like shell environment (MinGW – “Minimalist GNU for Windows”) which – very roughly speaking – creates the needed Unix layer that shells like Bash can run onto.
A terminal emulator called MinTTY is also installed (shown in screenshot #3 above) which is a Windows program that runs the Bash shell which in turn enables you to use quite a good subset of the Linux commands needed for an open source dev workflow.

Looks are important

… especially if you are an ex-designer-turned-frontend-developer. Going from the black and white severity of cmd.exe (where you could not even resize the window to the dimensions you wanted) to MinTTY definitely boosted my “developer happiness” feeling:

Screenshot #4: MinTTY terminal emulator window
Screenshot #4: MinTTY terminal emulator window

In the above example, I manually mapped the colours from the famous Solarized colour theme to the default 16 ANSI colours. For the font I chose the crystal clear Consolas font set at 12 point, although I’ve recently been experimenting with Adobe’s Source Code Pro as an alternative.

The MinTTY window can be resized to any dimension of your choosing. You can also use the same shortcuts as you use in the browser to resize the text on the fly (CTRL+plus, CTRL+minus or CTRL+mouse wheel). Finally you can launch as many instances of MinTTY as you want, enabling you to lay out a series of windows into your codebase and file structure, exactly as it suits you:

Bash in Windows Screenshot #5: Multiple instances running at the same time at different dimensions and font-size
Screenshot #5: Multiple instances running at the same time at different dimensions and font-size

I can now do {{thing}} from the command line

The list below demonstrates just a small subset of the stuff you can do with Bash in Windows that I found particularly useful and / or helpful.

  • Git
    No more “download and unzip”. Git clone any repo of your choosing in any directory in your filesystem. The handy “GIT Bash here…” shortcut that appears when you right click any folder is particularly useful here.
  • Linux command line
    MinGW supports a subset of the various commands and programs available in Linux, things like awk, sed, grep, find are all here, ready to be used. Shortcuts are also available (CTRL+U, CTRL+K for inline editing, CTRL+R to lookup on Bash history etc) as well as piping and redirection.
  • SSH
    OpenSSH works right out of the box. Set up your keys by using ssh-keygen (exactly the same way you would do in a Linux box) and then connect to any of your machines. You can also setup an ssh-agent (exactly the way Beanstalk or Github or Bitbucket explain in their online tutorials) to ensure you don’t retype your password all the time. Of course ftp and scp are available as well.
  • Vim
    No more notepad++ for me. After I went through the steep-as-mount-Everest learning curve I found out that vim was the best tool for quick text edits (I’ve strongly resisted the urge to play with emacs. We’ll see).
  • Bash scripting
    The very first bash script I experimented with (and use constantly nowadays) is z: I no longer rely on lengthy cd statements such as:
    cd /some_directory/nesting/nested/my_work
    But rather do a:
    z my_work
    … and I’m immediately taken to the directory I want.

“You should really switch to {{enter Linux distro name here}}”

Indeed. But even if I do so, there is still a vast number of devs out there who still need / have to work with Windows. One year ago, Isaac Schlueter (co-founder and CEO of the Node Package Manager – NPM) had this to say:

Bash in Windows: this matters
If you want devs using your code, this matters

Until WSL is out … Bash in Windows

The soon-to-be-released Windows Subsystem for Linux is a brilliant (and much-needed) step forward in making the Windows environment a first-class citizen for open source development workflows.Nevertheless, there is no need to wait for Microsoft to make WSL available to everyone.

I’ve been using Bash in Windows – in my daily workflow – for the last 5 years and it’s working like a charm.
If you want to do the same, simply install Git for Windows.