Beautiful, only complaint is it's 100kb minified - that's a lot of JS. Would love to know if there is any kind of modularization (if I only need 1 kind of chart can I lose some of the weight?).
Oh dear. 100kb is bad for this sort of thing? Does anyone know if that's a commonly held view?
I've been working on a Canvas library for full-powered diagramming for a year and a half and it currently weighs in at 597kb minified. (private alpha going on right now, so its nearing final size)
It's super awesome and covers an enormous amount of enterprise diagramming needs like customizable nodes, links, layouts, an undo manager, data binding, models, overviews, events, commands, tools, you get the idea.
But do you think people will reject it based on the size? Do you think not having a slimmer version would be a deal breaker?
> Oh dear. 100kb is bad for this sort of thing? Does anyone know if that's a commonly held view?
Not at all. For what you are actually getting 100kb is awesome.
However I like to develop really light pages especially for mobile. It's not even all about download size, mobile browsers can bog down even just parsing and keeping JS in memory.
Just the core of Google Charts if 150kb. 100kb seems light to me and certainly not a deal breaker.
But grandparent question is still a good one, is it possible to slim it down if you just use one chart? Probably a common usage is just to have one or two graphs of the same type on a site.
Well it only matters if it's going to get loaded a bazillion times. I mean, if you're focusing on something that's really good at a small domain, than I don't think you have anything to worry about. People keep optimizing crazily based on the assumption that it's going to be everywhere, which seems to be a bit overly optimistic.
Maintainer here. It is ~30kb gzipped, and is modular but there is no modular build yet. Individual plugins and chart types are not required, which cuts out a lot of the size.
The 100kb minified unzipped is a concern of mine, however. As the library evolves, keeping it trim and trimmer is a goal.
Realistically, a few static PNGs would exceed 100KB in a lot of cases. Any image-heavy page is going to have a few hundred KB of data. I wouldn't hold it against them.
It seems I always stumble upon these awesome graphing libraries right before I'm supposed to post an interesting dataset somewhere.
This invariably results in complicating my life far beyond what is reasonable and never managing to publish the dataset/graphs because it's too fun figuring out how everything works.
My only criticism right now is that your demo site breaks back button functionality (click on a chart on the landing page and then hit back to see what I mean).
Version 2 has a lot of great new features. The went in search of this because I need to draw a client side chart with 300,000 points on a scatter plot, and I wanted to see if canvas could do it. Turns out it can. At least with Chrome http://jsfiddle.net/vN4C3/
Can it also be used with socket.io? I'm working on a real-time app and I'm using socket.io to transport the data and graphing it on canvas. I'd be happy to use a graphing library that 1) looks good, and 2) works with real-time data, instead of my custom solution.
I looked into it briefly, right now i'm more focused on getting the charts right. Once I've done that I was going to work on different data transport options.
I have written another library, envision.js, which is more suitable for realtime data. Here's an example: http://humblesoftware.com/envision/demos/realtime. Envision here is adapted to Flotr2, but working with it is higher level than working with Flotr2 directly.
We need to visualise power usage data in the browser. The more tools we have the better. We're currently using dygraph but this looks much more flexible. I hope that the browser support is good.
Envision is a visualization toolkit for fast composite, interactive and animated visualizations. It's adapted to work with Flotr2.
Flotr2 & envision support Android, iOS and new Blackberries, any modern browser with Canvas, and IE7+ with FlashCanvas / excanvas. I've seen it in IE6 too, but I do not test that browser.
I used to use the original flot, but lately, we've been playing with jqplot. How do you feel this compares? I like the plug-in system in jqplot and recently we added 2D plots (heatmaps) in our local version.
I'm currently using GnuPlot's HTML5 canvas terminal for the dashboard of a in-house app. It's worth considering if Flotr2/Google Visualisations don't quite fit the bill.
I can't test this on IE<9 right now, but comparing to flot it seems they added the option to put axis labels, which I think is a big deal. In flot you can do it, but you need a plugin.
Now if they add also a 3rd parameter to points (x,y and identifier) it will be amazing.
Neat, I used Flotr for a personal project a long time ago and really liked it. The author also helped me with a problem and implemented a feature I needed. I'll keep this around for any future uses.
Is there any charting library which supports fetching data from server as the chart is horizontally scrolled? I want to chart some historical data that spans over years.
The docs don't say much about stacking area charts, and when you add lines : { fill : true } to a line chart it seems to overlap the areas. Anyone know how to do it?
Last I looked most of the cooler Google charts were Flash based, which was a problem for me at the time as I was looking for something that works on iPad.
From what I can tell this is one of the better HTML5 chart libraries i've seen but in general these days I like to build stuff with d3 instead.
Some time ago I used both Flot and Google Charts to build a dashboard. Each of them have it's own strengths. I believe that flotr2 is not so different than flot to what I've seen.
By the time I was woking on this project Google Charts was fragmented into 2 different libraries, Google Image charts and Google Visualization API.
My project was to draw a dashboard with multiple charts and connect them to data sources that collected the charts data on the backend. So every time you loaded the dashboard it fired multiple AJAX calls one for each chart's data.
Flot was very easy to work with, the interface to load data is simple and makes sense. It offered good options to customize charts. It offered Mixed charts where you could have lines and bars on the same chart. That was the only reason I brought flot to the mix, there was no way to draw charts using bars and lines on Google Charts back then.
Google Charts on the other hand was a little bit harder to work with. The interface to input data is less obvious and has some strange decisions. Important to notice that Google Charts also defines a protocol to load data into charts, the protocol was called "wire protocol" back then but was renamed to "Chart Tools Datasource Protocol"[1] currently on version 0.6. Sometimes the chart design was inconsistent and that was apparent when you had a bunch of different chart types on the same page. The Geo charts also had a weird behavior, different from most other charts, possibly because they were rendered using flash. The protocol Google establishes for chart data is hard to get started but once you integrate with it is very easy to change the visualization and creates good structure.
Google Charts got a big update a couple weeks ago, the previous version are being deprecated and all charts are now rendered using HTML5 techniques, most of the time SVG. The protocol also got a big update and fixed a lot of bugs that made my life somewhat miserable weeks ago. Now it also supports mixed charts (bars and lines), so I don't need flot anymore.
I'm in the process of creating another dashboard now, and I've been using Google Charts only this time.
My advice is that if you're planning to draw only a couple of charts and flotr2 does the work go with it. It's easier to work with and lighter.
If you're building something that depends on charts a lot go with Google Charts. The protocol will come handy and it has some helpers to connect to backend data sources and Google Spreadsheets built-in.
If you need to create a product that relies on the charting library too much you probably want to support more than one charting library and possibly have the option to switch the library on the fly. The deprecation of the previous Charting library. The deprecation policy for Google Charts may be a little frightening[2].
I looked into this, and apparently flotr2 is forked from flotr. flotr was "inspired by" flot, but uses Prototype instead of jQuery. Note that flotr2 removed the Prototype dependency so:
flot: the original uses jQuery
flotr: inspired by flot uses Prototype
flotr2: branch of flotr no dependency
