jgCharts
jgCharts uses the
Google Chart API but does not support all features from it. You can't color a pie chart with jgCharts, for example. Yet, most of the shortcomings originate from the Google Chart API. First, jgCharts do not impress visually compared to flot or jqPlot, which is not surprising since the charts are intended to be loaded as ordinary HTML image elements. This means that the API is the only way to customize the charts as CSS and javascript are out of the question. Animations and interactions like drill-down urls are naturally missing too.
Others
jQuery Sparklines didn't impress visually and I couldn't do even basic customizations to a pie chart. There is a reason for that. A
sparkline is a type of information graphic characterized by its small size and data density. This is probably the optimal use for Google Chart API too.
Visualize demo charts look nice, but the feature set is quite poor. Interactive features and animations are not supported, and there are only a handful of parameters. All data is scraped from a HTML table, which means that you'll have to explicitly hide the tables you don't want to show. With other controls, the problem is exactly the opposite: you need to do extra work to show data
also in a HTML table. But every jQuery plugin can easily scrape data manually from a table once it is there, which is much more flexible than creating tables in the exact format that a plugin needs. For example, in the previous jqPlot and jgCharts pie charts data was scraped from an ASP.NET datagrid. Visualize couldn't use that table directly. In the picture below there is a HTML table in the upper left corner and a corresponding visualize chart with default settings, as seen in Firefox and Chrome:

With IE8, the outcome was not so good, but at least those black spots in percentage shares were gone:
Flash
Flash is the technology of choice for professional web charts, as witnessed by Google Finance and Analytics. Silverlight certainly has potential too, but because of the relatively small
install base I decided to drop
Silverlight Toolkit from this review.
Technology
The worst part of Flash is the Flash development itself. ActionScript is not exactly known as the language of choice in software development. Developing Flash also requires
Adobe Flash Professional or
Flex. But if you don't intend to develop Flash chart controls yourself, none of this really matters. Right now and in the near future, Flash chart controls are the most sophisticated ones around, both in their visual outlook and in the features they support. But you should expect Javascript
libraries to close the gap pretty soon, at least from an end user's point of view.
Data access methods in Flash are a superset of the methods available for Javascript. You can use Javascript to feed Flash objects and the Flash charting tools provide good Javascript APIs. In addition, you can use the Flash object's parameters for data access. The urls defined in the Flash object are subject to different rules than the urls inside Javascript.
Authorized cross-domain data loading is available and is controlled with policy files. Second, some but not all Flash charts support printing data directly to a swf parameter.
Developer experience
If you can avoid Javascript, Flash charting is extremely simple. Well, it is just HTML objects then. Any developer should be able to use these kind of charts. If you cannot avoid Javascript, the experience is similar to jQuery development.
FusionCharts Free
FusionCharts Free (FCF) is a free older version of the popular FusionCharts, the market leader in Flash charting. First time I took notice of FusionCharts when they started to show up in popular web applications, especially RescueTime uses them heavily. Creating the example email tracking charts was no problem in FCF: FCF has all the polish of a commercial product:
- example charts that look good
- compelling feature set, but these features are yet very easy to use
- high-quality documentation and support forums.
- support for multiple server-side technologies
FCF's .NET interface is extremely simple. You replace a literal with a Flash object:
litFC.Text = FusionCharts.RenderChartHTML("/FusionCharts/FCF_Line.swf", strUrl, strXML, chartID, width, height, False);
XML data and settings are provided via an url, or are embedded direcly to a HTML Flash object. Great thing is that .NET interface does not try to act as a wrapper to XML, you generate the xml yourself and pass it as a strXml parameter to the above FusionCharts.RenderChartHTML function. FCF reads xml settings liberally and does not mind if you use settings from different chart types in one setting xml.
Each FCF chart type has a separate swf file, which is a minor complication because you need to know multiple pathnames in using the API. I wrote a helper enumeration to get correct filenames using IntelliSense.
The only problem with FCF is that it is a legacy product. The actively developed product is Fusion Charts 3, and the
differences between the two are substantial. Good thing is that you have an upgrade path, but don't expect any new features in the free version.
FCF is the easiest charting tool to work with, and even nontechnical people should be able to draft chart requirements with it.
Open Flash Chart
Open Flash Chart (OFC) is a popular open-source alternative to FusionCharts. OFC sample charts look good, they are definitely the best looking ones from the charts I've tested here. But this does not help too much if you won't get your charts to look good. And unfortunately OFC is not too easy to work with. 
OFC documentation is PHP-centric. For other environments, there are support forums but not much more. To use .NET you can compile the
shipped .NET library or use an
alternative one.
Unlike FCF, OFC has only flash binary, open-flash-chart.swf. Chart type is defined in the JSON-formatted data file. Compared to jQuery plugins, this JSON it is quite complicated to create manually. Good thing is that there are server-side libraries to create OFC charts that handle the conversion to JSON. But you still need to use javascript to pass the data to the chart. This is not as simple as passing XML data directly to the flash object parameters, as in FCF. You need Firebug to debug things, tolerate Firebug/Firefox crashes etc.
The default .NET API acts as a JSON wrapper class and is not nearly as simple as in FCF. The bad thing is that this abstraction leaks, you can't control every setting in JSON with the .NET API, or at least you have to spend a lot of time finding out how to achieve this.
One particular annoyance was that OFC dates use PHP mktime() ticks, that are otherwise the same as Unix/Javascript ticks but are counted in seconds instead of milliseconds.
My first impression was that OFC is hard. I wouldn't let my boss use it.
ASP.NET
It should be noted that the RIA controls I tested are free or open source but the ASP.NET chart controls are commercial products, usually shipped inside a larger toolkit. The controls are well productized and strive for high user productivity while offering the maximum feature set. This is not easy to achieve, and therefore it is important to support the user when the inevitable troubles arise. Money does not buy you a solution to every business charting case, but it does buy you many well-supported scenarios.
Technology
ASP.NET charts are technically using the same client-side web platform as the jQuery charts. In practice, there are probably quite a few constraints in developing a generic .NET chart control that do not exist in pure Javascript development. I wouldn't expect ASP.NET charts to visually match the best Javascript ones. But at least it would be nice to have some interactive features and animations, which are mostly missing now.
Rich data access is the strongest point of ASP.NET controls. You can use native ADO.NET data structures directly instead of serializing to JSON or XML. Another .NET advantage is that the chart controls are usually built as generic all-in-one charting solution for both ASP.NET and WinForms. The same chart control is also used in the vendor's reporting solution which can be useful.
Developer experience
Visual Studio IDE and the .NET tooling support in general are great, sure, but the focus here is on the usability of chart controls. Commercial server-side chart controls typically have lots of features and the learning curve can be steep. In the best case you have decent Visual Studio design-time support, which is intended to work like WYSIWYG for UI programming. In practice this means property grids to make settings and some visual output on how these settings affect the chart. But if you can't get design-time support to work, you'll only see the IntelliSense code comments and external documentation while coding, and the final outcome is visible only in the browser.
Generally, getting an example chart up and running takes more effort in ASP.NET than with jQuery plugins or Flash charts, because you have to set up a IIS web application and prepare an aspx page, a code behind file and a web.config. Development and testing cycle is slowed down by the time it takes to compile the solution and reload the ASP.NET site. Reloading is particularly slow if you have
lots of dlls in the /bin folder. But again, this same reload happens when using a Flash chart .NET API, or when doing server-side .NET data access with any front-end charting tool.
I don't like the ASP.NET heavy lifting needed to draw a few charts. But if your boss is an ASP.NET developer, and you provide the environment and a few samples, things should be ok.
XtraCharts
XtraCharts is a part of the DevXpress toolkit. Deployment requires 16mb of DLLs to be loaded in every application restart, only for charting. That's heavy and takes a few seconds in your dev machine.
Demos are nice, I liked the
spline plot, but as you can see, the chart is a .png image, which prevents any cool animations or mouseover interactions
inside the chart. Outside the chart image you can have tooltips as in the "
Weather in London" chart.
For some reason, I couldn't get the Visual Studio designer support work in a DotNetNuke module project. The designer showed an error:

Probably some setting is wrong as I was developing in a Visual Basic project. Working manually with the code-behind file is fine with me, but the bad thing was that I already faced a problem after a few iterations of the pie chart. Below is the chart with labels but no legend:

Setting the legend visible caused the chart to disappear:

Issues like this arise in every complex control, but debugging them makes you appreciate the fast develop/test cycle of the client-side tools.
Telerik Charting
I have used Telerik RadChart previously with Telerik Reporting, and my perception was kind of lukewarm then. But I should have more perspective now.
First the good news. Designer support for Telerik Charting works pretty well, even though the property grid is hard to use when fine-tuning the chart. WYSIWYG works even in the data level: you can put data items in the aspx, and they show directly in the designer, as pictured below!
Having data in aspx also means that you need not to do anything in the code-behind to get a working report. But frankly, I don't find any use for data-in-aspx other than simple demos.
Compared to XtraCharts, some useful chart types are missing, or they don't look as good. For example, a line plot
demo has labels but not visible data points. XtraChart
demos are more complete, easier to navigate and better-looking than their Telerik
counterparts, but the difference is not big. Both tools produce static image-based charts that support only
image map interactivity,
zooming support in Telerik line charts being an exception. It should be noted that Telerik also offers
Silverlight charts that are on par with Flash with respect to pizzazz.
And then the bad news. I couldn't get the Telerik charts working at all in the browser. All that I got was an error message:
BC30560: 'ChartSeriesType' is ambiguous in the namespace 'Telerik.Charting'
Normally, I would debug for an undefined time to get some results. But this time I have to call it off. No more ASP.NET debugging today.
Final words
Programming is a profession of solving real-world problems with tools that are built to look great in demos. But you shouldn't blame the tool if you can't ever achieve the same results in the same time on your own, no matter how much you spend time debugging with the tool. This is the reality. But sometimes you do get positively surprised by a development tool that just works as promised. FusionCharts Free is such a product. The people who designed and implemented it five-to-ten years ago have done a hell of a job. Thank you!
I chose Fusion Charts Free for our company, and it is probable that we upgrade to the latest commercial version in the future. FCF has the looks, simplicity and support required for a business where charting is a nice-to-have but not a critical feature. A great thing is that FCF with inline dataXML data and no mandatory javascript is a fool-proof charting environment that is safe for your boss too.
Open Flash Charts was the runner-up, entirely because of its looks, but it is too complicated for occasional use. If I was doing serious charting I would compare OFC more carefully with the commercial version of Fusion Charts.
jQuery plugins are promising, but so far they are fit for only lightweight charting tasks, mostly because they lack features. Javascript is still not for everyone, but for javascript-savvy programmers the developer experience is extremely productive, until you hit any edge cases.
It makes sense to use .NET chart controls if you can piggyback some of the work you have done with the other controls in Telerik or DevXpress toolkits. Or if you are doing WinForms charts too. But as standalone web charting tool, RIA charts are better.
-mika-