There are now thousands of charting libraries floating around out there on the JavaScript sea. When it comes to charting, it’s very easy for us to be enthralled by a beautiful interface. But, it is to our great detriment to jump into bed with a charting library without knowing the real substance behind it.

A nice interface and copy / paste code are all well and good if we need something generic to our needs, but realistically, most of the time we need something tailored to our use case. And more than that — we need a reliable charting library that we can build upon.

In this post, I aim to review certain aspects of the most popular JS charting libraries to help you make an informed decision when it comes to implementing one for yourself. Some of the aspects of the libraries we will look at are:

• Technical prowess / performance
• Ease of implementation
• Suitability & customisation
• Compatibility
• Aesthetics

Alongside these factors, I will implement real scenarios, comparing which charting library suits each scenario, and discuss the upsides and drawbacks.

From my experience having implemented charting in the past, I realise that charting can be a very individual requirement. So, of course, I’ll review the customisation options of each charting library as we move along.

Customisation is one of the most important factors to using any open source technology. It’s worth remembering that the library wasn’t built specifically for our needs. To avoid major headaches later (ever have to tell a designer that you can’t match the production JS charts to their Photoshop designs?), we need to be sure that we have as many customisation options as possible.

In addition to examining how customisable a charting library is, I’ll look at the performance implications and the technical impressiveness of each library we document. Ensuring that our charts actually work is unspeakably important when it comes to choosing a library. Don’t forget, the ease of integrating a library into an application is just as important as its technicality.

Before we start, the JavaScript libraries I will be reviewing are: HighCharts, Chart JS, C3.js, Chartist, Plotly.js and NVD3.js.

Brief introductions

Before we get into the scenario comparisons, I’d like to briefly introduce each library we will be using.

HighCharts: Being based upon SVG technology makes HighCharts a modern charting library, and with it having fallbacks for older browsers, makes the compatibility for this library good too.

Apparently, they serve over 70% of the largest companies in the world. Whether this is accurate or not, the product is well rounded, and incredibly fully-featured. Particularly with this library, I am a fan of the dynamic charts, which enable the end user to tangibly interact with the data.

HighCharts is a generic JS library, meaning that integration with all of the major web frameworks is very simple. The documentation found on their project website is also very thorough.

Chart.js: After recently releasing Chart.js 2.0, the product has improved markedly. We now get access to much more pleasing data animations and transitions, date / time and logarithmic functionality and the ability (as with HighCharts) to mix different types of data chart together into one. Chart.js is a much lighter product than HighCharts, and doesn’t offer quite as much choice. However, their documentation leaves a little to be desired.

C3: C3 is a simple wrapper around the D3.js library. By wrapping D3, we are no longer required to write any D3 code. C3 is fast to render, has good compatibility across browsers and is very simple to integrate. The biggest thing to note with this library is the slight lack of functionality (not as fully featured as the other leading libraries) and the simplicity of the visualisations themselves.

The charts produced with this library will never win an award for artistic styling, but they are functional and clean. If you’re looking for no-frills, C3 is a decent choice.

It also includes good documentation for what is an inherently simple library.

Chartist: Another thoroughly modern, SVG based library; Chartist was built upon the idea that other libraries were simply not giving enough customisation options. The biggest feature, arguably, is the SVG animations in the charts produced with this library.

If a modern browser is used, one can implement CSS3 animations on SVG attributes that turn standard charts into something much more visually pleasing. One can also implement much more extensive animations with SMIL.

Happily, Chartist’s looks aren’t just skin deep. It has a solid technology base and is very easy to implement. Within minutes, one can have incredibly impressive, expressive charts that interact easily with any backend data source. A great all rounder, but maybe not quite as fully featured as HighCharts.

Their website contains excellent documentation.

Plotly: Another charting library built atop of D3.js, Plotly is one of the most common libraries used. Visually, plotly is not as stunning as Chartist, but for technical prowess, Plotly steals the top spot of all the libraries in the article, in my opinion.

However, once very large amounts of data points are included, I noticed that Plotly struggled to run on an old machine of mine, and actually managed to crash Chrome. That being said, it is a fantastically rich library and has outstanding documentation, including a tutorial for each of the chart types.

NVD3: As a direct competitor to the aforementioned C3, and another of the most popular libraries, I thought NVD3 was worth bringing into contention. Built upon D3.js like other libraries above, it does have a solid technical base. Much like C3, it is focused more around function than form, and is quite sparse in the aesthetics department.

Its performance is relatively good and it does have basic animations to inject some visual stimulation in an otherwise fairly plain interface. Data can be pumped in directly from .json files, meaning NVD3 is very easy to integrate with existing data API solutions.

My biggest gripe, though: Their documentation is almost nonexistent, comprising of samples only, and not going into depth on customisation.

Technical scenarios

Now that we’re familiar with the libraries we’re reviewing, I’d like to take some real scenarios and compare the charting libraries against each other to see which comes out on top. All of these scenarios have been generously provided by colleagues of mine, and cover common uses for charting libraries that we may all encounter one day.

For the common scenarios I’ll go into below, I’ll look at which library fits best overall into each scenario based on a number of factors. I’ll discuss the upsides and downsides of the most appropriate library for each scenario, and cover both the aesthetic and technical factors applying to each.

Financial detailing

Realistically, in the modern web world, one of the most common uses for charting libraries, comes in the form of financial data. From banks to betting applications and shops to currency exchanges, financial data needs charts, like charts need data!

For our first scenario, I’d like to imagine that we wish to do something entirely common, and something that every company may have to implement internally one day; tracking stocks. Tracking any financial data is always a complicated business, but especially when it comes to stocks, shares and currencies. The sheer amount of data used to populate the charts we see on major financial websites is huge.

If we wanted to track stocks ourselves, we really need to take performance into consideration. We should also be thinking about both the clarity technical demands of the data display.

Front-end Application Monitoring

Identify Fix Track

Get a Free Trial >

When I compared the charting libraries in a Stock Tracking scenario, there was one clear winner; HighCharts.

HighCharts actually comes with a built-in library specially created for financial data named HighStock. Initially, I thought that one of the simpler interfaced libraries would have produced a more clear result, and with a higher level of performance due to their relative lightness.

After testing the D3 libraries against HighCharts in this financial stocks context, I immediately became aware that not only would HighCharts allow me to map an extremely large amount of data with minimal effort, but it would also remain rather performant, even compared to the lighter libraries.

Here is a sample of JSON mapping data I sourced directly from the Google Stocks API. This is a very standard data format of simple timestamps and data points, so it’s safe to assume we can utilise it.

/* Oct 2017 */
[1506902400000,154.26,154.45,152.72,153.81],
[1506988800000,154.01,155.09,153.91,154.48],
[1507075200000,153.63,153.86,152.46,153.48],
[1507161600000,154.18,155.44,154.05,155.39],
[1507248000000,154.97,155.49,154.56,155.30],
[1507507200000,155.81,156.73,155.48,155.84],
[1507593600000,156.06,158.00,155.10,155.90]
]);

Now, with a JSON file filled with tens of thousands of records of this data, we can then pump it into HighCharts, and form a spectacular financial data chart without writing too much code:

I believe HighCharts would be the best charting library for one to utilise when mapping financial data. It is easy to install, highly compatible, performant, and neat.

The data is displayed in a concise and easy to understand manner. Whether you are a large corporation or a small startup, HighCharts would impress anybody looking at your data visualisations. The one thing to bare in mind here, though, is that HighCharts will need to be licensed if one is to use it in a commercial setting.

You can find details of HighCharts licensing here.

Dashboard analytics

Almost every startup that collects user data on signup needs some kind of dashboard. If, for instance, we pretend that we are an API provider company, we need to be able to offer our customers usable, concise and most importantly useful data and statistics on their usage of our service. GitHub offers us commit history charts, SendGrid offers us detailed email usage statistical charts, and Auth0 offers us usage charts on our users. They all have a concise and agreeable way of presenting this data to us, without massively slowing the page down, or being too intrusive.

More and more often, startups are focusing very heavily on having the most serene UI and UX for their user dashboards. A big part of that is the way in which they convey data to their users. Naturally, we need to be able to keep our user dashboards from getting cluttered, and we need to keep them performant. Alongside those factors though, what we really want in this case, is for our dashboards to look fantastic.

I’m not sure how you feel about this, but I think there isn’t much out there that’s more appealing than beautifully visualised data. In my last startup, we spent weeks trying out every major JS charting library to find the one that could visualise our data in an epic way, but also stay performant and be highly customisable.

In this scenario, my choice has to be Chartist.js. Chartist is not only performant, even with lots of data thrown at it, but is also hands-down the most beautiful and visually-pleasing way of presenting one’s data. The creators of Chartist have focused on building a technically-solid-based product, that allows enormous amounts of customisation, and really does look fantastic.

Below, I’ve created an animated line-chart that would not be out of place on a user dashboard. With barely any code at all, I’ve created something I would very happily ship with any product. (If the animation has already played, click on the rerun button on the bottom left of the Codepen embed.)

Time-based tracking

Another very common scenario is plotting data over a time series. In a fairly similar way to the financial scenario above, but without the same level of data. Now, if we wanted to use HighCharts for plotting time series data, that would be fine. However, if we want to use a library that is lighter, a little easier to implement, and more importantly; free to license, I would very much recommend taking a look at Plotly.js

Plotly has a very solid technical base, being built atop of Python, R, etc. It has API libraries available across most major languages, but we’ll be looking specifically at Plotly JavaScript. The reason I would choose Plotly.js in this scenario, is that I want something a little less full-on than HighCharts.

Plotly is very easy to implement, whether simply hard-coding a small amount of data, or feeding in a JSON data file as I have below, Plotly.js stays very performant, and looks clean and concise. I’m a big fan!

Conclusion

With charting being something we all need to implement so often now, it’s no great surprise that there are many open source charting libraries available for us to choose from. The libraries I mentioned above are some of the most popular, and are all libraries I have had a chance to either implement in a production environment or to experiment with first-hand. The scenarios above are also directly sourced from colleagues and reflect some of the obvious ways in which we need to implement charting in the real world.

As technology develops, it is nice to see charts actually becoming lighter and more performant libraries. A few years ago, it was a heck of a struggle to implement data-heavy charting without conflating our application and driving our app users crazy by the factor in which we’d slowed it down, and cluttered it up.

All of the libraries I mentioned above have very good browser compatibility and fallbacks available for people using legacy browsers. The libraries built upon D3 have a solid base, but personally, I find them a little bit underwhelming from an aesthetic aspect.

My favourite from the above libraries is most definitely Chartist. I’m a huge fan of its beauty and its ease of implementation. I love how performant it is, and it most definitely takes my prize for best user experience. Chartist is brilliantly featured and can be adapted to fit into almost any scenario, making it an ideal choice for one’s needs, regardless of data format or situation.

I’m more than happy to chat about charting libraries if you have any questions, and I’d love to hear your stories of implementation. Drop me a line at robin@percy.pw.

Thanks a bunch for joining me!

• @rbin

Plug: LogRocket, a DVR for web apps

LogRocket is a frontend logging tool that lets you replay problems as if they happened in your own browser. Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket lets you replay the session to quickly understand what went wrong. It works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store.

In addition to logging Redux actions and state, LogRocket records console logs, JavaScript errors, stacktraces, network requests/responses with headers + bodies, browser metadata, and custom logs. It also instruments the DOM to record the HTML and CSS on the page, recreating pixel-perfect videos of even the most complex single page apps.