tags:

views:

598

answers:

7

I'm trying to establish whether we are better off rendering charts serverside and pushing them to the browser as images or using a javascript charting library to draw the charts clientside.

I'm looking at the JFreeChart and Dojo Charting libraries, my target is an existing JSP site that runs in JBoss.

Does anyone have any experience with this who might be able to point out the merits/flaws of each.

At the moment I'm seeing Client side rendering as being a hell of a lot more efficient unless the dataset is Huge.

+3  A: 

I would like to recommend a library I wrote: charts4j which is a server-side charting solution. Here are some features:

  • Supports nearly all features of the Google Chart API
  • Hides the ugly details of creating the URL parameters that are necessary for communicating with the Google Chart API
  • Can be incorporated into any Internet enabled Swing or web application environment (JSP/Servlet, GWT, Spring MVC, etc.)
  • 100% pure core Java solution. No need for special graphics libraries, etc.
  • Super-scalable & Lightweight. Only one 160Kb jar and an Internet connection required
  • Well documented
  • Best of all, it is FREE!

Here are some testimonials. Also check out the FAQ.

I have an example of incorporating this technology into a Spring MVC (using JSPs) app on my blog.

Julien Chastang
Looks interesting, the reason we've strayed away form the google api is that it (seemingly) requires a connection to the google and the internet, whish is bad becuase our applications often have to run in intranets with no outide connection.
Omar Kooheji
That's right. No Internet connection, no Google Charts. It solves some charting problems very well, but not all.
Julien Chastang
A: 

JFreeChart is very well established and has been about for many years. I've used it on previous projects and it's worked very well. It can be used from a rich client application or from a web application. It has example applications for both scenarios. If you're distributing your application it's also GPL licensed.

The advantages for doing it server-side are that you can render the resulting chart as an image and not worry about cross browser compatibility. I've incorporate JFreeChart by rendering from a Servlet and from Struts, works very well.

I can't speak for Dojo charting, as it's reasonably new.

Jon
A: 

The first deciding factor should be whether or not you need the charts to be accessible with JavaScript disabled. If you do or think you might, it rules out JavaScript completely.

VirtuosiMedia
A: 

I see a lot of valid points on either side, but one thing that I like about doing the charting client side, is the ability to do some interaction with the chart. Using the Dojo charting library, you have a variety of methods for chart interaction such as dojox.charting.action2d.Highlight and dojox.charting.action2d.Tooltip. You can also have you charts update dynamically without the need to refresh, and I can see some situations where that can be useful.

Of course, this is all up to you, but I like charts I can interact with a whole lot better than images rendered from the server, and I think a lot of people agree with me on that one.

Jesper Karsrud
+1  A: 

I would recommend determining your performance/provisioning needs and making the decision from there. If you are expecting a large number of clients, each requiring a large number of charts which may need to update periodically, offloading the processing onto the clients will likely be the better solution. As jesper mentioned, you would also be able to do more interaction directly with the charts on the client, rather than requiring callbacks to the server for more complex functionality.

If the general use-model for your charts is simple (e.g. static charts being generated on the fly by the server, w/out needs for updating), and the number of clients is low, you might be fine using hardware to better improve performance. Server-side would probably be sufficient in this case.

Scalability and performance can be hard to implement later down the road. If you have the potential to mitigate this from the beginning, you should do so, since current use models so often change as future users decide they need faster/better functionality.

bedwyr
A: 

If you go with javascript you may also want a server-side solution, in case javascript is turned off.

If you use unobtrusive javascript then if javascript is turned on it can change the links for the server-side solution to use a javascript charting tool.

I found it best to use php on the server-side as gdlib is nice, and my tomcat server would throw errors at times due to not being able to connect to an x11 server even if it was running in headless mode.

There are many solutions possible, or you can do it yourself. Graphing isn't hard, it depends on what you need. For example, if you can go with using svg then that would allow animated charts, but needs a plugin for many browsers.

James Black
A: 

I'm also trying to figure out which to use. This page seems to have a good analysis of ads and disads:

http://www.linux.com/archive/feature/124993