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?
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.
The 100kb minified unzipped is a concern of mine, however. As the library evolves, keeping it trim and trimmer is a goal.
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).
Edit: back button should be ok now.
Looking for something easier to work with then d3.js/cubism.js.
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.
Now if they add also a 3rd parameter to points (x,y and identifier) it will be amazing.
Made a simple page with graph of common O-notations:
The library is still young, and that functionality you see there will mature a bit yet.
I wasn't a big fan of color scheme initially (very powerpointy mind-you) but I looked at the source and saw the colors can be changed. Great work!!!
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.
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" 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.
flot: the original uses jQuery
flotr: inspired by flot uses Prototype
flotr2: branch of flotr no dependency