August 15, 2019Tomas Piga16 min read
Reviewed the 6 most recommended React libraries and found the following answers among them:
Read on to find out why 🙀🚀📈👾
I've witnessed projects lose time and trust because they picked a library that didn't match their needs. Don't make the same mistake and use this guide to make a better decision about both your graphing library, but also about other types of libraries in the future.
There's several ways the top x libraries can be chosen: asking colleagues, reading online forums, or articles. For a strong consensus, I reviewed the first 6 articles [1, 2, 3, 4, 5, 6] I found after searching for top React libraries. By seeing which library was listed the most, I was able to reduce the list from over 100 to the following 6 most recommended libraries:
To build a great product using many libraries, you need to turn your requirements into the correct technical decisions almost daily.
When working on new features, or even new products entirely, I've noticed 7 elements which can be important to saving time. I've turned these into criteria in order to easier guide you through these decisions.
Although not all may be relevant for every library, reading through these can at least help raise questions to clarify the intention and product characteristics. If you know the answers, then pick the ones that are relevant to your project.
An easy instant indicator for the general appeal of a library and how well it has performed in the community over a long time
A graphing library is a product at the end of the day which is why the ratio of good reviews to general use can help discriminate between good and bad implementations
Not all graphing libraries offer every kind of chart and the features you need. The important thing here is to:
Sicara asked the CTO of a data visualisation company what was the first thing he checked to choose the right JS charting library. His answer was: the activity and popularity of the Github repository.
The presentation of graphs in a library is a very opinionated topic. A library coming with a great design out-of-the-box can:
There are so many variables and use cases of libraries that the docs and examples are absolutely key to both saving time, and having a stress-free developer experience in general, more specifically:
To gauge the popularity, I looked at the number of package downloads over the last 2 years.
Number of downloads of the top 6 React graphing libraries. This chart won't stay updated, but you can check out the comparison directly.
As you can see Recharts has double the number of downloads than the second-best. And even Chart.js for React (react-chartjs-2) has a few times more downloads than any of the others.
The chart allows us to see that downloads are not only currently high, but have been historically high and so a good indication for a lot of community experience and time with these libraries.
To try to estimate the general quality of a library, I contrast the stars of their GitHub repository versus their downloads.
Legend: Where rating is the stars over the number of downloads.
Nivo and VX are really well received with about 1 in every 4 people starring the library. Meanwhile, only about 1 in every 50 people star the Chart.js (React) library. This really shows popularity is not necessarily correlational with quality.
There are 4 main functions for graphs and so first I define what types of graph could be expected for each. Then, I look through the libraries and see how well they cover these to give
|VictoryLine (polar property),
|Areas demo (time),
Stats plots demo,
|BoxPlot + ViolinPlot,
Legend: Green means good support, yellow means partial support, and blank means either no support, or very limited support.
|NIVO||Best||No, PRs exist but outdated||vx-typescript-kitchensink|
|Chart.js (React version)||Not easily||Partial|
Legend: Green means good support, yellow means partial support, and red means either no support, or very limited support.
It's unusual to find libraries natively typed in TypeScript, in which case you can search for the separate NPM definition here. If there's no official definition, Definitely Typed contains high quality definitions. Alternatively, you may find some that people have submitted through various issues or open pull requests.
All of these libraries currently have an MIT license. This means they are free-to-use for both personal projects and commercially. In general, you can find licensing in the top-right of a library's GitHub page.
The pulse of a library is GitHub's way of showing you the contribution to a library in terms of commits over time. You can find it in the insights tab of each repository.
React-Vis (Feb 21, 2016 – Jul 20, 2019)
Victory (Jul 26, 2015 – Jul 20, 2019)
Recharts (Aug 2, 2015 – Jun 29, 2019)
VX (Mar 19, 2017 – Jul 20, 2019)
Nivo (Apr 10, 2016 – Jul 20, 2019)
Charts.js, React (May 1, 2016 – Jul 20, 2019)
Chart.js (Mar 17, 2013 – Aug 12, 2019)
Victory looks to have the best pulse, with React-Vis and Recharts also having fairly regular contributions.
The distribution of commits across the top contributors can show its support structure and the likelihood of continued support. Under the issues tab, you can see both bugs and features that have been previously reported (open issues), and solved (closed issues) - a great indicator of the library healthiness.
|Creation||Contributors||SPOF (%)||Chance of bug|
|React-Vis||Feb, 2016||40||39||1 in 255|
|Victory||Jul, 2015||31||71||1 in 333|
|Recharts||Aug, 2015||51||79||1 in 376|
|VX||Mar, 2017||28||90||1 in 889|
|Nivo||Apr, 2016||11||96||1 in 300|
|Chart.js (React)||May, 2016||13||50||1 in 687|
|Chart.js||Mar, 2017||97||57||1 in 1,257|
Legend: contributors are the number of users who made at least 2 commits, SPOF is the Single Point of Failure chance calculated by taking the highest contributors commits over the top 5 contributors' commits, and the change of bug is the number of open issues over the number of downloads (essentially the likelihood that you'll encounter an existing issue).
The libraries which look to have the least bugs are VX and Chart.js. Bear in mind that this is only an estimate as some may be more common than others. Regardless of this, most libraries reach a common number, with an exception of VX which is exceptional in keeping open issues low; only 33 open.
To find out the size of a library, you need to both look at its own size and also the size of its dependencies. Bundlephobia gives you an instant computed response, and allows you to see the library size growth over time.
|Compressed size (KB)||Dependencies||Modularised||Notes|
|VX||52.4||-||Yes||@vx/grid, @vx/group, @vx/shape, @vx/axis, @vx/scale|
|Chart.js (React)||120.4||5||No||Also requires charts.js|
Legend: Size is the min-zipped size of the library including all of its dependancies, modularised means whether the library is split into components so you can import only the parts
For a simple graph, in a standard 3G network at 50KB/s:
Though the former will tend towards the latter as you start to add more complex charts.
This is a subjective topic, so this section is for determining the generally preferred design and UX philosophy. To confirm this, I asked colleagues and contacts throughout London to rank these 6 libraries in order of best to worst. The final statistic is their average rank (from 1 being the best to 6 being the worst).
The results showed that Nivo and Recharts were much preferred over the React-Vis, VX, and Victory, with Chart.js sitting somewhere between.
The Nivo design was said to be accessible. Although VX appeared stylish, the impression was that it was trying too hard to have an opinionated great look, whilst disregarding some standard UX.
|Search||Resources||Examples||CodePen / JSFiddle|
|Victory||Docs||In docs||Responsive docs|
Victory leads in this area with each of its examples being responsive - allowing you to easily add and quickly test parameters. The search worked for both graphs and props to the graph which made it very easy to find whether certain features existed.
Nivo is the follow-up as the interactive demos allow a very clean way for even a UX/designer/product manager to find the right combination. However it lacked a thorough search throughout the library and the demo code itself wasn't directly editable.
The most important part of all of this is to find out what your requirements are. What are you building?
Once you know that, then you can pick the library that suits exactly your need and enjoy the benefit that comes from that. Whether this is an improved user experience on mobile, or an excellent prototype to show to your stakeholders. Unsure about your requirements? Go with the catch-all React-Vis.
If you've found this useful, you'll probably like some of the other articles we've posted on our Theodo blog, so check them out! If you'd like to join us, or start a project with us, visit our website for more info!
Web Developer at Theodo