I can vouch for that. I have been using FusionCharts[1] for some years now and I have never faced any browser compatibility issues. But I can understand Cyph0n sentiment here. It's amazing that they still support IE6+.
Same. Before I found Highcharts, I'd switch between a few different graphing libraries, based on the needs of the project. I'd always find that each graphing library had its own set of limitations - there'd always be something it couldn't do (besides D3, where you can do basically anything - it's just quite complicated).
Highcharts was the first library I found where, even when I assumed what I wanted to do would be impossible, it could do anything I threw at it. The number of settings and formatting options is incredible. Such a fantastic library.
(By the way, for maps, there's Highmaps. It's an additional license fee but it integrates nicely and provides a bunch of cool choropleth map features, etc).
I tend to always go with FusionCharts[1]. And AFAIK, it offers way more charts and maps than any other library out there. 90+ chart types and 965 maps last time I checked.
It's extremely customisable and has tons of readymade fiddles[2] and business dashboards[3] for inspiration(ready copy). I recently used full code of one of their dashboards for my project. I've never failed to convert my designer's or PM's concept into exact same working code with FusionCharts. Highly recommended.
Highcharts is beautiful but it's quite expensive for a startup in my country (VN). While the budget for a nascent webapp is around $1000. I choose Flot as the replacement. It's flexible and nice enough with responsive layout, compound charts, clearly script.
The only downside I dislike about flot is that it depends on JQuery. As I otherwise don't rely on JQuery at all, it means another ~80kb of additional JS code. Beside that, flot seem to be a very good free alternative.
I started out with flot after noticing the high cost of Highcharts. But now have been switching out flot with dimple.js and d3.js. The charts are much better with dimple/d3.
Interesting. I considered graph libs based on-top of D3. But D3 is equally big in JS file size to JQuery. And SVG wasn't supported in older Android (2.3) and slower in Firefox and Chrome 3 years ago. So flot with its Canvas rendering "won" in the end.
How so? It's less than $400 for an unlimited use single developer license without support. That doesn't seem very expensive for a good product that saves time and helps productivity. I'm sure they might offer discounts if you contact them about the startup situation.
It's 90$ for a single web page that's not considered a web application, which has a dubious definition "A web application is a website that has customer specific data or charges for its use."
Most tech startups probably aren't going to meet that definition. It looks like a 1-developer license for a typical SaaS offering is going to run you $390. Five developers is $1500.
I wish they would open source the rest of the charts. When I worked there we had some amazing visualizations that weren't included in the open source portion.
It seemed like the project went a bit dormant and Novus was not supporting it that well so a community fork [1] was made that was just recently merged back in [2]. I have seen the support uptick (though a tiny issue I made was closed while still wrong before I made a PR [3]).
And we already do that in other domains, e.g. NumPy covers most people Python number crunching use cases, Cocoa covers 95% of OS X people UI use cases, etc, MySQL and PostgreSQL cover 80% of the web app db use cases, Rails covers 90% of Ruby's webapp uses cases, Django and Flask do the same for Python, etc...
Why do say it's a relatively small field? Outside of mobile, the desktop web is the front end target in all of computing these days, and JS is the only reasonable way to write for it.
I would consider D3 not to be a graph making library, but more a Data Frame & Document Object Model data binding library with a collection of stats functions.
Great list! I personally use http://c3js.org for all charts on https://wakatime.com/ because it's easy to use like highcharts, but comes with an open license. It's basically a wrapper around d3.js for all the common reusable charts, which makes it very easy to style and customize.
This. I've seen developers try to do all these crazy client-side optimizations hoping it will make the graph drawing faster, when all they have to do is sample the data in the server. You don't need an array of 1 million data points to visualize the general sample.
You might want to rephrase it to "Graph drawing" because there is the graph data structure and I thought that this link was about graphs. It might be just me but I can imagine people getting confused by the title.
As someone who works in that field, to me "graph drawing" relates even more to drawing and arranging mathematical graphs of nodes and edges (called networks on that site); the conference on that is called Graph Drawing, too. It's also a frequent confusion of potential customers who ask us whether our library handles line and bar "graphs" ...
negative filters might be useful too. i.e. non-jQuery non-d3, or at least make selecting multiple dependencies show the union of both sets, rather than the empty intersection.
Interestingly enough, I had a problem with ChartJS that no one seemed to be able to remedy. It was quite bizarre and at first seemed to be a cross browser issue, but after further investigation it seemed to just be some type of strange cross-machine issue. See it here http://stackoverflow.com/questions/30063762/side-effects-fro...
Given that, I had to do some hacky stuff upon every refresh. Instead of using destroy() on the canvas, I had to remove the Canvas DOM object itself, building it back up, and inserting it again. Because of this I am a bit skeptical about using ChartJS again, which is unfortunate because I do love their Charts. I feel like maybe SVG might be the better way to go for analytics.
hey nirkalimi, I'm one of the maintainers of Chart.js. I know of a previous issue where the behaviour you described occurred on devices with window.devicePixelRatio greater than 1. Your JS fiddle didn't reproduce on my machine and it appears to use v1.0.1 which was the version that fixed the bug with devicePixelRatio. Calling destroy() on the chart object should be enough to reset the canvas to it's original state. If you'd like, file an issue on github and I can have a more detailed look.
Very nicely done! I am just about to choose a charting library and this will be a great help.
Have you considered adding some sort of user rating system? I find myself kind of just wanting to know which one is most popular or highest rated (i.e. take some of the work out of choosing between 30+ libraries myself).
IMO rating would be a difficult thing to do as there are many factors[1] to consider. What best for one use case, might be the worst choice for another. A more qualitative comparison would be more useful:
The things that people would most likely vote on are not really relevant. "I successfully made a simple chart based on the examples with this library" -> 5/5. If you need more than the examples, most people will have different backgrounds and requirements. What library they can best use depends on that.
I've been looking for a chart library to display timeseries graphs and integrate well with react. The best one I found so far is react-d3. Unfortunately, it's still somewhat awkward.
Shameless plug: you may want to have a look at my library https://github.com/andreaferretti/paths-js which is made for exactly this purpose. My frustration was that D3 wants to have control over the DOM, but most frameworks let you write components in a declarative style using templates or databinding. So I started paths-js , which takes the data as input and provides an abstract description of the graph as output, that you can then use in your framework to provide rendering. One of the demos that you find on the page I linked is actually made with React
Awesome site! I would love to see which ones are for Android, JS, of iOS. For example, I'm actually looking for a charting library for iOS but can't seem to filter for that. Here's another site I use to sort of see a lay-of-the-land view of charting libraries:
I've just looked at dimple. It looks quite a bit simpler than implementing d3, I will have to play around with it, but from your experience how would you rate it in terms of ease of use, learning curve, performance, etc.?
- It is a lot simpler than D3
- It works best when your use case fits into the explicit examples given here : http://dimplejs.org/examples_index.html
- If you are wanting something from the advanced examples, you should be proficient in javascript and understand d3 already
- If you want something not in the examples at all, you should really understand d3.
It's pretty quick to get up and running with it, you can always get access to the underlying d3 selections to do more complicated operations, and the main developer is fairly accessible through stackoverflow questions or github questions. There are some gotchas I've run into but nothing that has made me consider switching. We evaluated a few different libraries before choosing it.
I can't speak for performance really because we don't have huge datasets. For ordinary business data (not looking at 1000s of points on a chart), it's fine.
Yeah, my experience exactly. It's a great start if you're prototyping and your initial use-cases map well to their demo pages. Once your designer gets excited, you'll have to write a lot of code on top of it and may well consider ditching it entirely.
It would be fantastic if this comparison included average render times for graphs of various dimensions and number of data points, and/or maximum number of data points that can maintain a render time faster than 1/60s. Especially on Firefox for Linux, which doesn't have Direct2D available.
While we're on the topic, I'm beginning with js with a goal to create some materials for maths classes. Which library would let me do, for example, graphs of quadratic, cubic functions AND possibly drag/move the line to see how the equation translates? Thank you
If you want to create class material, have a look at http://challengeu.com - they've built an entire service around providing a platform for teachers to share content. It's pretty cool! (Disclaimer: I used to work with them)
Just what I needed (a while ago, but again soon I'm sure). There are so many options with JS graphing now, it can be a bit overwhelming just assessing the options and their capabilities.
If you are interested in network visualization you might consider Cytoscape.js. It's being used e.g. in bioinformatics (visualizing networks of interacting genes, interactively inspecting & manipulating their layout etc). Open-source license, and seems to be becoming quite featureful:
Are any of these charting solutions being actively used in a cacti-like application? I feel like with how old the RRD technology is, something would have replaced it by now.
Nothing beats the power and flexibility of GNUPLOT. Still going strong after almost 30 years, with excellent documentation and loads of support on the web, too.
What are the advantages of SVG or Canvas in that use case? Which one (SVG, Canvas) is principle faster on current browser with thousands of data points?
Canvas
* Bitmapped graphics
* Immediate mode
+ Fast for simple things
+ Minimal drawing overhead
- Interactivity has to be handled manually (e.g. by checking whether click coordinates coincide with a drawn button)
- Animating things (usually) mean redrawing most of the canvas for every frame
+ Ability to manipulate pixels if needed
* Everything is drawn manually
SVG
* Vector graphics
* Retained mode
+ Fast for simple things
- Everything that needs to be drawn has to exist in the DOM
+ Interactivity can be handled via events by the browser on every element if needed
+ Animating things (usually) just mean to manipulate that thing in the DOM
- Limited ways of arbitrarily manipulating the composed result
* Everything is drawn by the browser
+ CSS support
+ Sophisticated text rendering support
It's mostly a trade-off of what you want to do. The things marked with * above are not clear benefits or drawbacks.
For a chart that consists of axes, ticks, a plot and maybe a few other things I'd always go for SVG unless compatibility constraints force me to go to bitmap graphics. It just maps much better to vectors than to pixels, but there are limits, of course. Heatmaps often are better drawn via canvas, especially those where there are no discrete shapes but rather blurry blobs of colour.
Performance is a difficult topic and hard to compare, beyond simple things: In canvas (mostly) your only option of optimisation is to draw less, i.e. touch fewer pixels; with SVG being rendered and composited by the browser it often boils down to »don't move elements that don't have to move« to enable the browser to render less and not throw away every partially composited texture. In IE and Chrome SVG has quite great performance, in Firefox you have to be careful what you do. Uusally it scales well to a few hundred or thousand DOM elements, though, depending on what you do.
3 years ago, I benchmarks it with thousands of lines: SVG was faster than Canvas in Internet Explorer 10, probably due their extensive long history with their VML legacy rendering. But SVG was a lot slower in Chrome and Firefox than Canvas probably due graphic card accelerated Canvas implementation. SVG wasn't supported in Android 2.3.x. From my experience back then working directly with raw-SVG in HTML5 wasn't a great experience SVG is based on XML after all. Working with raw-Canvas meant implementing a basic render loop myself which refreshes the area and the Text related API is a bit complicated and slow.
SVG performance in IE (since IE9) has really been and is stellar, indeed. Chrome caught up mostly by now and at least at work the difference between Chrome and IE for certain tasks is that Chrome spends more time rendering and IE spends more time JavaScripting. Firefox SVG performance has been disappointing, mostly and mobile browsers are often better off with canvas as well since performance is generally constrained there.
SVG performance in IE doesn't date back to VML, though. They just made hardware-accelerated rendering a major feature of their browser back then, while no one else was doing it properly. Similar to how Chrome started with JITting JavaScript to make it fast and everyone else caught up on that afterwards.
You don't necessarily need a million DOM elements. Data points could mean points of a single plot, in which case you have a single path element with lots of points. Generally you can almost always bunch things together in a single path to reduce the number of DOM elements (with other tradeoffs, of course).
Thanks! It would also be nice if the license types of each library were included as well. Graphing libraries for the web can be surprisingly restrictive!
Dygraphs (http://dygraphs.com/) has treated me well in the past. No dependencies, tiny library, handles millions of points, and it's html5 canvas based.
That tells you everything you need to know about Javascript/browser graphics for data science. A. The DOM cannot handle as many nodes as are needed for large datasets and/or B. even with Canvas/webgl etc the browser platform itself chokes on dataset sizes much bigger than 1/2 gig (ie, "small" data). So Javascript is fantastic for explanatory graphics, but forget about exploration.
Our JS lib (not listed here) outperforms best-of-class native. We basically connect your browser's GPU to a GPU cluster in the cloud, but the data analyst doesn't care. We focus on real-time interactions with big graphs (e.g., connecting to your spark cluster) and include intensive visual computations like real-time edge bundling. We previously applied the same techniques to big time series (horizon) and treemaps.
Happy to chat more if relevant. You can see a bit at graphistry.com .
Completely agreed. Problem is while you're exploring to find the correct dimensional reduction / chuckout strategy, you're typically rapidly scanning through lots of scatter plots / density plots / whatever in grids and my experience is that the browser and javascript don't cut it here for reasons of throughput. If it's not the DOM that's blocking things, it's the commmunication channel to the browser that is too slow, and you can't dump all your data into the browser to avoid the communication slowness, because it then chokes. Chrome will barely allow a JS object a mere gig in size. Firefox dies well before that. This is not to say that we're not moving in the right direction on javascript/browser-based exploration, just that for now it's premature. BTW I'm succesfully using Jupyter (ipython notebook) as a hybrid solution. Bit of a best of both worlds. But then we're no longer talking JS for the graphics.
as someone that soon enough hopes to need evaluating graphing libraries for a side project (implement the types of charts cachegrind [and similar] provide) this post came at a great time.
