Before starting your search for a JavaScript charts package, you need to know that creating good data visualizations (dataviz) is a huge time investment if you are planning to build a serious application. Having clear answers to questions like what exactly your dataviz is going to achieve, on which devices will it be used, how much time you have got to build the application etc. will help you make the best use of guidelines mentioned in this guide.
It will be great if the library you choose satisfies all the factors mentioned below, but it’s not possible all the times. So choose wisely which factors are more important to you and which ones can be ignored.
Enough for the introduction, let’s get started with the meat of the article!
1. Cross browser compatibility
Whether you need a charting library that’s compatible with all browsers or just modern browsers depends on your target audience. If you are building for government or for enterprise clients, there’s a very good chance that they are still using older versions of IE. So charting libraries that only work with modern browsers might not be a good choice.
It is a pain to handle cross-browser compatibility issues, and we believe the library you choose should do it for you.
Examples of libraries that work only on modern browsers: D3.JS, Chart.js and Chartist.js.
Examples of libraries that work in all the browsers: FusionCharts, amCharts and Highcharts.
Here’s a handy link for global browser usage statistics. This will help you take an informed decision whether you want to focus on all the browsers or just modern browsers.
2. Cross device compatibility
Will your application be used primarily on desktop or are you targeting mobile users as well? If it’s just for large screen viewing, most of the charting libraries will work for your dataviz component, but if you want to ensure a consistent experience across hand-held devices as well, the charting library you choose should be responsive. This is becoming increasingly important because of changing user habits in recent times.
If you are making an application only for mobile, then you need to consider size of the library as well. This is because of lower processing power and browsing-speed issues in smartphones. A library with lower footprint is highly recommended in this case.
You don’t need to worry about cross-device compatibility if your application will run only on one type of device (mobile or desktop).
3. Input data format
Although JSON (JavaScript Object Notation) is gradually becoming the standard format especially when it comes to charting libraries, there are still many cases where you’ll have to deal with XML. If you need XML data for your dataviz, it will be good to know whether your charting library supports it.
Most of the times you will have to load the data from a database like MySQL, Oracle or SQL Server. In this case you need to take into account the format which is acceptable to both your library and other parts of the application.
Other popular ways of loading data are CSV, text, HTML tables etc. In most of the cases you will have to write custom code to convert data into the format accepted by the library you choose.
4. Customizability
This is one of the biggest decision factors for many. Is the charting library flexible enough so that you can make it do what you want, or will it just look good on defaults and you are on your own if you try to customize it?
There are hundreds of things that one can play around with such as adding custom shapes, configuring legends, managing chart lifecycle, attaching event handlers (click, hover, key press), leveraging drill-down of data, and applying themes etc. If you want to create a beautiful design, it’ll be good to have a library that is easily customizable so that you can mold it according to the design of your application.
But with great customizability, comes great complexities. A good example of this is D3.js. It practically allows you to configure every element on the chart, but doing so is effort intensive. Then you have libraries like FusionCharts and Highcharts which strike a perfect balance between these two. Here you get a lot of freedom to customize your charts with minimum effort on your end.
5. Range of available charts
This one is a no brainer. Whatever visualization you want to create should be a part of the library. But it’s not so easy as various charting libraries have collective packages in which similar charts are grouped such as maps, widgets and stock charts. So depending on the use-case, you might want to go for a particular package only, or you can get the complete bundle.
One useful advice here is that you should always consider your future needs as well and not just present ones. If for a slightly higher price you are getting a package which contains charts that you might need in future, our advice will be to go for that package.
If you want to compare different charting libraries based on range of available charts, you’ll find this detailed comparison table of nine popular JS charting libraries very helpful.
6. Learning curve
Some data visualization libraries like D3.js have a steep learning curve. No doubt D3.js is very powerful, but if you are running on a tight deadline or using a charting library for the first time, it is not recommended to use D3.js.
On the other hand, if you are getting started in dataviz and have lots of time on your hands for experimentation, you should by all means try libraries that are beautiful but require some time investment.
Whether you want to emphasize on this point completely depends on the application you are building. If charting/visualization is a small part of your application or you just need simple charts, then you should go for libraries that are easy to use and support various chart types out of the box like FusionCharts or Chart.js.
If you are building something where visualization is the focus and you have to visualize something complex, then there is no alternative but to dive in and learn how to use libraries like D3.js. Some examples of complex visualizations: How the Recession Reshaped the Economy, Where We Came From and Where We Went, State by State.
7. Compatibility with other parts of code or compatibility with Web-frameworks
Imagine you are comfortable using PHP, ASP.NET, AngularJS or jQuery and are not familiar with vanilla JavaScript very much. Wouldn’t it be great if you can build charts using framework specific plugins or wrappers?
Some libraries have free plugins and wrappers that generate the required JavaScript and HTML code for you, which is then used to render charts on a web page.
Here is a page containing all the plugins and wrappers for FusionCharts. For example, if you are building an application using AngularJS or ReactJS, then using the plugins linked above you can include interactive charts the AngularJS or React way.
8. Performance
Performance is dependent on many factors like size of library, memory usage, rendering and re-rendering time, garbage collection and number of browser repaint cycles. We tend to value performance very highly, but optimizing only for performance is not always the best idea. This might sound contradictory so let us explain this point with an example.
Let’s assume you are building a dashboard which will be used on local intranet. Do you think using the library with smallest package size makes sense here? In this case we can choose a library that comes out best based on other factors discussed here. Saving on library size should be the least of our concerns.
If you have to plot fewer data points then most of the libraries will perform on a similar scale and you can neglect this factor. On the other hand if you have to render millions of data points, then performance becomes a major deciding factor as each fraction of second saved will have a huge impact in aggregate.
9. Exporting
This point is not applicable for every use case, but only for cases like reports and dashboards. If you are building a dashboard for business audience, your users might want to export charts to PDF or images. It will be better that the charting library you choose supports export feature out of the box. Common export formats to look for are JPEG, PNG, PDF and SVG.
There are two ways to export charts – client side and server side. Libraries like FusionCharts and Highcharts support both the ways of exporting. Only adding one line of code is enough to get this working. While for some libraries you will have to write custom code to achieve this functionality. It’s better to know before hand if exporting is something you need in your application. If you do, it is better to choose a library that does it with minimal effort.
10. Design and interactivity
Design is more than just look and feel of a chart. It should not only look good (themes, color scheme), but it should have meaningful interactivity (hovering, click-through drill downs, live data updates, etc). For example, clicking a legend icon in multi-series line chart should toggle the visibility of related data plot. Custom code should not be required for that.
Themes: another important design feature is the ability to theme your charts to match the design language of the rest of your application. A centralized theme manager – one place to manage the theming of your charts – will make your job much easier.
Space management: as number of data points and labels go up, there is always a fight for space. What gets displayed and what is hidden? If a library is fairly new, space management issues are expected. It’s only through repeated testing over the years does a library mature to get rid of all edge cases and have a perfect experience in all circumstances.
11. Community and support
If you are building an application, data visualization might not be your core strength. So when you face a problem, you might need some external support to solve it. Support can come in many forms like personal, forum or community sites like StackOverflow. If you are on a tight schedule you would not want to wait for an answer on StackOverflow. Personal support or dedicated forum would be very useful in this case.
In case of popular libraries, most of the answers to general questions are easily available, but you are bound to face dead-ends at times while testing edge cases. If you think you might need dedicated support, it is recommend that you buy a commercial charting component instead of using an open source solution (given it meets all other requirements, of course).
12. Accessibility
Accessibility is a topic that comes up a lot when you are developing something for the web, and the same is true for charting libraries as well. Generally government websites tend to have stricter policies regarding accessibility – does a charting library comply with 508 standards? Are screen readers like JAWS able to read the charts rendered by a library? etc.
If accessibility is not addressed right out of the box or through a plugin, then you might need to write your own code to address it. Here are some resources to help you out regarding accessibility of a JavaScript charting library:
13. Pricing and licensing terms
Most of the libraries now give away their source code when you buy a licence, but that doesn’t mean you are free to do whatever you want. It’s important to know what all permissions you’ll need for your project and buy a relevant license. Terms and pricing varies depending on factors like number of users, type of application (SaaS, intranet, web) and number of servers.
For pricing it’s better if you take overall cost into consideration and not just the upfront cost of the license. Don’t choose a library with the lowest upfront cost as things like maintenance, upgradation and support can cost a fortune in future.
A good place to learn about licensing is here.
14. Open source or commercial
Open-source is in fashion nowadays, but it’s not the right solution for every need. Especially when it comes to charting solutions, there are tons of tiny open open-source libraries available on GitHub. But be careful about the licensing terms and the project’s activity before you try to implement one of those in your application.
Pros of open source libraries: free, full source-code available, and community support if project is famous and under active development.
Pros of commercial libraries: dedicated support, maintenance, reliability, proper documentation, and ability to influence development of features.
Here’s a very good article that answers when a commercial library makes sense over an open-source one.
As you might have realised while going through the guide that it’s not an easy decision to choose the right charting library. But it’s worth the time and effort as you’ll have to spend a lot of development time with the one you choose.
We have tried to cover all the possible factors that one needs to consider, but if you think we missed anything feel free to ping us on GitHub.
➤ This post originally appeared on Fusion Charts
Read next: Master JavaScript coding with this Essentials Bundle (97% off)
Get the TNW newsletter
Get the most important tech news in your inbox each week.