Jack Welch had Six Sigma. George Bush had his "vision thing". And an animated sponge has his "This is going to be the best day ever!". So forgive me for enunciating GChart's fundamental principles in this grandiose "GChart Manifest" (and no, I did not forget the "o").
I'd like to say these principles guided me in every step of GChart's design and implementation. In fact, after many attempts at something better, I ended up choosing the only strategy I was actually able to code, and then came up with the these principles to rationalize what I'd done (a statistical justification is planned for the next version).
Why leave the GWT-Java sandbox just to add a few charts?
Want to trace into your chart library in the Eclipse IDE and tweak a line that isn't working the way you want it to? GChart gives you this level of complete, Java-based, source-level, control.
And, because it's layered on GWT's standard library, your deployed application is fully optimized by GWT's compiler, and compatibility with all GWT-supported browsers is practically automatic.
OK, I admit it: our simple "just say it with rectangles" implementation strategy often leaves us no choice but to forget the flashy eye candy and embrace our inner squareness.
So, we aim for charts that clearly communicate the meaning of a data set in, say, an engineering or scientific application. We scorn 3-D pie charts with perfectly manicured edges. Instead we ask: "Why insist on solid fill pie slices when banded-fill uses a fraction of the HTML elements?"
Square is simple and fast and works even in IE6 quirks-mode. Or, in the words of SpongeBarSquareCharts (no relation), "This is going to be the boxiest chart ever!"
Sure, you can generate great charts from a server. Indeed, with the new Google Chart API, you can even generate them for free off of someone else's servers. But if you need off-line charting, or simply prefer that your application's performance be constrained by the client computer, not by the connection and server, you need a client-side GWT charting solution.
Flexible Apache licensing and zero out of pocket costs isn't enough.
You have to be able to easily understand the code, so you can fully exploit, and even change it, as needed.
The library also needs complete docs, a full set of examples, on-line demos, and a thorough test set so you don't spend more figuring out how to use it than you saved by not having to buy it.
Fortunately, GChart's straightforward implementation frees up a lot of time that can be devoted towards making the library reliable and easy to use.
These are our principles. We stand by them. Until, of course, we figure out a better way to implement the darn thing.