Early in my career at Apple, I learned a great deal about building products. I gained exposure to the world-class manufacturing processes that enabled Apple to ship its hardware products on time and at quality, and later transform itself into the most valuable company in the world.
My experience at Apple also taught me how the principles behind manufacturing optimization could be applied to software engineering and architecture design.
Software development continues to trend toward reusable and interoperable components rather than bespoke engineering for everything. Like optimizing processes in manufacturing, choosing the right frameworks and libraries is the key to fast, efficient development.
If you’re building an application with data visualizations, an early decision you have to make is whether to use D3 or a React chart library.
If you’re not familiar with D3, it is a Javascript library that provides the necessary building blocks to build data visualizations by manipulating SVG and HTML. It has become the backbone of the most popular reusable data visualization libraries — such as ChartJS, eCharts, C3, NVD3, and Plotly — which make it easier to generate D3-based charts while writing less code. Most of these libraries have a wrapper library for usage in popular frameworks, such as Ember, React, Vue, or Angular.
If you want to minimize writing custom code and time, I recommend using a React chart library instead of creating your own charts in D3.
But after you decide to use an existing library, the decision to invest time and energy into a new chart library can be overwhelming. Where do you start?
React is a relatively new ecosystem and there are perhaps fewer chart library options than there are for Javascript, which might make you feel a bit limited. As a starting point, I would suggest that you look at these React-specific libraries:
There are also some great wrappers out there, such as react-chartjs-2 and React Highcharts. But before you weigh the pros and cons of each library, I’ll outline below what I think are the most important criteria for your decision.
Top criteria for choosing a library
Your first step should be to clearly define your use cases. It sounds obvious, but knowing what you are looking for is the most important criteria in your decision.
What chart types does your application require? Depending on the type of application you’re building, you might require simple instead of complex charts. Often, line/area, grouped/stacked bar, and pie/donut charts suffice for most applications.
What kind of customization, formatting, and interactivity do you require in your design? Do you need to be able to customize tick marks? What about showing or hiding grids and axes? Will you need to custom tooltips, legends, and margins? Will you need to format and style your charts significantly? These are all important questions you should also ask.
After you have concretely defined your requirements, here are the top four questions you should consider:
- Is the project well-documented with examples?
- How active is the project?
- Is the project free or commercially-licensed?
- How easily customizable are chart components, like tooltips and legends?
Documentation and examples
A good chart library should have a dedicated documentation site that is both interactive and includes many examples. Raphaël Benitte did an amazing job building the documentation site for Nivo. It allows you to customize attributes and see a live simulation of each chart with randomized data directly in the documentation site UI, which makes prototyping and iterating on design 10x faster. Nivo and React-Vis both use Storybook for UI demonstrations of their various examples, which can dramatically shortcut the time to build a chart.
The Nivo documentation site allows you to easily customize attributes from the UI.
Project activity
Before you invest too much time, you should check to make sure the library is being actively maintained. Most chart libraries have 1 or 2 active maintainers. You should check how recently and how often the project is being updated. The date of the last commit in GitHub can be a good indicator. Charting libraries built specifically for React are generally updated more frequently than their Javascript counterparts.
Chart libraries ranked by the number of days since their last commit during a snapshot in January.
Free vs. commercial
While there are many great free libraries out there, some would argue that a paid license might be worth the time you save, especially if you’re building a commercial product. Three popular paid charting libraries with a React wrapper are HighCharts (there are several flavors, but this is the official wrapper), ZingChart, and FusionCharts. A license for Highcharts, which is known for its breadth and flexibility, starts at $1,510 for a single developer for the Highcharts Suite.
Customizability
It’s important that you spend enough time researching the full capabilities of the library. Specifically, be sure to check out the documentation for tooltips, legends, axes, and titles. Readability of the codebase can be important here in case you need to go to GitHub and find the code you’re trying to customize.
As I mentioned before, you should pay close attention to the types of charts supported, especially if you need to go beyond line, bar, pie, scatter, and other standard charts. Need a line and bar chart together? Recharts has a composed line and bar chart. Need a grouped and stacked bar chart? Recharts has a mixed bar chart as well. If you are looking to have a visually consistent application and make your code reusable, you will want to choose a chart library that supports all the types of charts you need.
Recharts is good for charts composed of multiple chart types.
One constraint you might encounter is the number and variety of charts. In my opinion, chord, sankeys, and other complex charts can be confusing and are generally not needed for most applications.
If you’re looking for a library that is closer to the metal, I’d recommend VX. Shapes are the core element behind VX (the main package import is @vx/shape). If you observe the constructs of the code in the package, Harrison Hoff also uses base D3 components like xScale and yScale.
Other criteria to consider
There are a number of other important criteria to compare when choosing a library. In terms of popularity, you should also check out each library’s stars, forks, and contributors on GitHub. Of the React-specific libraries, Recharts had the most stars (10.7K) as of late January, followed by Victory (6.7K), VX (5.6K), React-Vis (4.9K), and Nivo (4.8K).
GitHub stars for popular chart libraries
Another good proxy for popularity is package downloads on NPM.
Chart generated using NPM Charts
I also like to see how quickly pull requests are opened and merged, which is a good indicator of the velocity of new feature requests. Commit frequency in GitHub Insights is a good proxy for activity, though you may find very helpful and responsive maintainers with less frequent updates.
VX is an actively maintained repo with weekly commits
One benefit of choosing a paid product is that you will have access to support. If you choose a free, open-source library, you’ll have to rely on other people who are willing to help and share examples. While you will generally find more help from a larger community on Stack Overflow, I also consider whether or not the library has an active community forum. Nivo, for instance, has an active Discourse community and Victory has one on Gitter.
If you’re working in React, being able to theme your chart library is another big win. Whereas Chartist, for instance, uses a highly customizable Sass file, Nivo let’s you create your own theme constant across all of your charts, like in this example below.
Example using Nivo theming
You should also investigate whether or not your library supports server-side rendering. Some libraries assume that your code will only be executed in a client-side environment. If you want to produce charts outside of your application’s user interface — such as in an email client or in a blog embed — you need to be able to render your charts server-side. Some libraries support rendering your charts in SVG, HTML, and Canvas which can give you greater flexibility and control over where you display your charts.
Don’t forget about browser and device compatibility. If you’re building a desktop app with plans to build a mobile app using React Native, currently Victory is the only library that makes components for React Native. Also, if your app is responsive, then some chart libraries might work better than others. Nivo comes with out-of-the-box responsive components whereas React-Vis, for instance, might require a custom wrapper with breakpoints.
One last criteria I like to consider is code splitting, which makes your imports more manageable and maintainable. Some chart libraries (such as VX and Nivo) are bundled into multiple smaller packages that allow you to load individual charts components instead of the entire library, which can result in better performance. If all you need is a line chart, it would be a shame to import an entire library. For instance, Nivo lets you use import { line } from @nivo/line instead of importing the entire package.
Choosing Nivo
In the project I’m working on (Code Time), we started with React-Chartist because the documentation was clear and simple. However, we ultimately decided to switch to Nivo because it met all of our use cases and had a thorough documentation site.
The most frustrating part of experimenting with a new library is making an attribute change and being unable to detect if the change is working or not. Nivo allows you to tweak attributes in the UI and quickly see the effect, which helps speed up my development. There are some things that could still be improved, like being able to see your own data in the UI and creating variables for formats, but these are minor details that I am looking forward to seeing improved in the future as the library grows.