Drawing Graphs on Your Browser?
Pieroxy queries: "I recently had a look at various ways to draw a graph (lines, bar chart, pie chart...) for a web-based enterprise application. As we need some interactivity, the GIF image generated on the server-side is not an option. Here is the list of technologies I can think of: Flash is probably over kill and a closed technology. Java is very flexible but slow (to start and run). SVG (discussed here) still requires a plugin. VML is supported only on IE5+, but it is natively supported. Which one of these technologies is the more flexible and interactive? Is it reasonable to require a plugin from the end users of our enterprise application? Is IE5+ a wide enough target for an enterprise application?"
If you can get away with just bar charts, take several gifs/jpegs/pngs that are just single colour pixels and have your server-side program fiddle with the heights and widths to draw your bar chart without having the server generate an actual image file.
Internet Explorer 5 and above are very widely-used. However, they are still flawed browsers and, due to the announcement that these browsers will no longer be updated as standalone applications, many people may switch to another browser. Also, those using a Unix-based platform (read: GNU/Linux) no longer have any viable way of using Internet Explorer. If it is not easy to change back and forth, the already limited audience VML will reach even less as time goes on.
As an opinion only, if SVG is an option, it may be best in the long run. Assuming it is not easy to acrobatically jump from one option to the next (if that was possible, you could serve VML to IE 5.5+ and SVG to Mozilla, and some raster format for any other browsers), SVG holds the best promise. SVG is already supported as a plug-in (much like flash). It is about to be tested as a native part of the Mozilla browser. Over time, compatibility will actually improve--not something Java or VML can say easily. Also, as compatibility improves, simple scripting can make the charts interactive or real-time (or other neat fancy stuff).
2) No. If it doesn't work on (at least) Netscape/Mozilla then you're excluding too many people (unless you know something about your target audience that I don't).
Surely you can do something with DHTML/Javascript to dynamically resize bar charts...
Use ImageMagick (http://www.imagemagick.org/) and do it all server side and save your self a lot of user dissatisfaction. The chances of finding a format that everyone will see is pretty much nil. Just send them GIFs or JPEGs from the server.
Reliable, Great Value Hosting: $7.95/mo 2.4G/120G
I've recently had to do something very similar, well okay almost identical. Interactive graphs of various types and of various data sets from a Web Based interface.
:)
We have larges amounts of data which is very hard to interperate by a human in something like a spreadsheet. The only really feasable way to do it was graphs. Of course with the amount of data we had transmitting it to the client to do client side rendering (ie Java) is also out of the question.
In the end we settled on JPGraph with an interactive interface built using PHP. So a wizard style interface to choose the type of graph, what data to graph, how to group the data, and finally the outputted graph with the option to change all the settings.
With good indexed data making PHP generated graphs with JPGraph interactive is quite painless and very powerful.
Just one suggestion, make sure you have a way for people to save the settings of the graphs they make so they can pull em later, keeps the PHBs happy
I'm me. I think.
For serverside interactivity, a generated image (PNG,JPG,GIF) is more than suitable...
You can even make it an imagemap, if you need image-based feedback...
Just a thought...
"Go to CNN [for a] spell-checked, fact-checked summary" -- CmdrTaco
As we need some interactivity, the GIF image generated on the server-side is not an option.
Surely an image with an onClick and some Javascript will do what you ask of it?
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
well in my experience i can create great interactive STANDARDS COMPLIANT sites that work completly in Opera, Mozilla and Safari, then have to go bugger it up to get it working in IE
This may not be ideal for you, and its a bit of a kludge, but others might find it interesting...
It's relatively trivial to use VBA to get Excel to generate a nifty graph. Now use the 'save as html' format and it will save a nifty gif of the graph. I have written a wrapper for this process which means I can pass in a dataset and end up with a reference to the graph file.
All things in moderation; including moderation
Is IE5+ a wide enough target for an enterprise application?"
sorry for trolling, but that sounds like a dumb question.
no matter how much this site hate micro$oft, we still have to accept the fact that window$ still dominate the market.
at least 8 out of 10 of my randomly picked friends are using windows.
Facing the same question, we are taking a route where people can have either SVG (if they have a plugin) or a standard image format. Then server side we render the chart onto the required format. SVG is really nice - compact (if compressed), simple, scalable, ability to have dynamic interaction etc. but PNG etc are good to have as fallbacks...
.. and that interactivity is hard to achieve in a web browser, maybe this application doesn't belong in a web browser. Just a hunch.
The MING library can generate SWF from PHP et. al.
I've been pleasantly surprised by Flash MX, actionscript is a fully featured programming language that runs across all the platforms Flash is ported to. You can pass variables from your html page, so your graphing application should be writable as 1 single 'movie' that accepts data, rather than writing a new one every time you need to draw a graph.
The only problem is that the tutorials and manuals are aimed purely at designers, not at programmers, so the concept of a variable is given a 20 page explanation whereas the syntax of the more complex commands is glossed over in a 'do this and it works, you probably don't need to mess with it' manner.
A pizza of radius z and thickness a has a volume of pi z z a
For simple histograms, you can go quite a long way with TABLE TD and TR, and a few 1x1 coloured GIF files stretched to suit. Primitive perhaps but very portable to most browsers. OK, lynx users will get cross ... maybe generate ASCII art for them
If you want the interactivity, you should at least try an optimized pared down applet. It's true that most applets are slow, but it is frequently also true that they are written badly and/or contain heaps of additional libraries that they need to download. Use as much of java's built-in code as you can with the possible exception of the GUI library.
Look at lightweight graphical libraries like lwvcl (commercial) or thinlet (LGPL) for the controls. The zaval people even have a charting library for their lwvcl system. (I have never used the lwvcl library, it just looks cool - try their online demo. Thinlet packs amazing capabilities into a very small package.)
If you need to display 15 graphs at a time with limited interaction, then this may not be the way to go, but if you need to display one at a time with very rich interaction, this might be the ticket.
dhk
A while back I created a small Java applet that did some minor client-side image mangling. There was a delay of a fraction of a second bringing up the image. Not "slow" by any means. Most of that delay was probably the time it took to download the image from the server.
The real problem is that you have to stick to what is available to the 1.1 runtime. Yes, that's "1.1" from the previous century, because that's what most Windows users have.
Corda might do what you need. It will output the images in Flash, JPG, PNG, GIF, SVG and others. I believe it uses XML files to generate the graphs. I'm sure I'm missing a lot of the other things that it can do, but it's worth taking a look. Oh, and unfortunately it's not free, but it might be worth it if it does what you need.
Note: I do not work for this company. I have seen the results of using their product. We use it where I work and everyone seems to like what it can do.
In perl.
Blazing fast with mod_perl.
Very easy to learn.
More info here.
I once wrote a piece of javascript that would do this client side. It was for a corporate intranet, so I knew which version of which browser was going to be used.
.js file can be cached, so only the data has to be sent, measuring a large multicolor pie graph in bytes rather Kbytes.
The idea was simple: I created a table with every cell one pixel large, and set the colors accordingly to the input for the frame. It started out as a simple line graph, but in the end it could do bar and pies too.
This should be doable crossbrowser now that JS has stabilized enough between IE and Moz. If implemented right, it can really do with much lower bandwidth than pictures (which was the main requirement then): the
the pun is mightier than the sword
Yes, but it costs thousands of dollars!!!
There were a few options that I rejected:
- Flash - probably extremely good at this sort of thing, as vector graphics and user interaction are its big target. However, we have no in-house expertise, and the end-users will all be professionals who may very well not have Flash installed (and furthermore, their firewall may not even give them HTTP access to download it)
- SVG - Great! It's W3C approved, as opposed to the officially deprecated VML! Whoop-de-fucking-doo. When our clients complain that our application doesn't work, I'll point them to the W3C spec and have the warm glow of righteousness as all of the lawyers' letters demanding refunds come in.
- Java - Well, it can handle drawing and events just fine, we have in-house expertise, but the whole point we're doing this through the browser is to avoid having to write an application from scratch in the first place. Now calling it an "applet" and changing main() to start() doesn't alter the fact that IMO writing user interfaces in Java sucks my grandma's clit.
So, VML. We have the luxury of knowing that the standard desktop is Windows running IE. I suspect that at least 95% of your target desktops (you did say enterprise, right?) will be IE too. Furthermore, if they're running Windows then you know that even if they are running, say Mozilla, that they have IE to hand.At the risk of posting flamebait, do you really have to worry about the possibility of end users running a non-MS operating system? Almost certainly not. Even the few that use Macs can presumably view VML. So go with VML and mandate the use of IE.
Unless, of course, you do wish to use Flash and have the expertise - although I still think you'll run into issues of people not having installed the plugin.
http://ostermiller.org/bargraph.html
It is done using only HTML with CSS. There was some reason that the bars come down from the top rather than up from the bottom, but I don't remember what it is right now...
You can dynamically call it with javascript.
You can use an image map and some javascript.
You can put results in a frame or an iframe if you don't want the entire page to reload.
I wouldn't write the whole thing in javascript alone -- why reinvent the wheel?
In considering possible solutions, I would take a crack at PDF. I've never done PostScript programming, but as I understand it, you can create vectors, arcs, and splines pretty well. Actually, since I don't have a good graph-generating package myself, I may just look into this ... hmm.
For my own use I would also look into CAD software formats ... what was it, DXF? I gather that's pretty simple for vector stuff, but it's not readily supported in browsers.
--- Jason Olshefsky
Karma: Poser (mostly affected by adding this line long after everyone else did)
I think it depends what you mean by "Enterprise application".
If you mean this is for a company intranet or something where you can control the browser they're using, then having to install a plugin for SVG or Flash wouldn't seem to be a problem. Neither would dictating IE5+, although you might find that limits the companies options later.
If you mean it to be "professional looking" for as many customers as you can, then obviously going IE only is about as short sighted as you can get (remember Mac users are about to be excluded) leaving you with probably 10-20% unable to use your application. Requiring a plugin might be a hassle but if it works on everyones browser choices then maybe that's still ok.
But I don't understand why Java is the wrong answer here? Most people have it, it really isn't slow to start and run unless you're doing something boneheaded with it like sending many megabytes of libraries you don't need.
You can even do some surprisingly powerful things with Javascript, although coding them to work in buggy browsers (all of them, especially IE) can be a real pain.
- Muggins the Mad
Why not check the HTTP Accept header? If SVG's in there, use it. If VML's in there, use it. Etc.
(I don't work for them, but I have used their products)
If you can control the browser to be IE5+ and don't mind using a plugin, you could..... write a .NET control using the System.Drawing namespace. Very easy to use.
I have done something similar where I generate .png files on the fly based on user input and a resulting DataSet.
p.s. I will preceed to duck now, trying to avoid the flying tomatoes.
I rarely comment, but I can't help it here. I work for Wal-Mart, and I'm on a team that needed to be able to graph a system's performance (CPU/mem/network/disk usage, et cetera). Similar situation to what you're in, I think. I'm not sure what they were using beforehand, but everybody, managers included, is extremely happy that they've switched to Ploticus. They rave about how fast it generates a graph. It's very, very flexible. And it's open source; I noticed a subtle bug, and a few days after notifying the author he gave me a fix.
We have the raw data points coming in from a server-side scripting language (proprietary, unfortunately). These points are passed to a Perl script which parses the data and stores it in a format Ploticus can recognize. It also generates the configuration file used by Ploticus.
I'd really highly recommend Ploticus. No plugins needed. Once you figure it out, it's a dream.
Use flash - I don't know how you can dismiss it as overkill when you consider using java.
.swf
If you just need the basics, you can use ming to generate the graphics, and most of the vector drawing programs will save as
You get cross platform support (pc, mac, linux, IE, opera, moz) and no plugin download for >80% of your audience. ECMAscript-like actionscript for interactivity, and a whole shedload of developers to help you when you get stuck.
OK, so it's not quite OSS, but you *can* get the source, generate your own swfs using OSS etc.
Someday the net will get over those flash intros and see flash for what it is - a compact, cross platform plugin
Argh - way to many 'but java applets suck' posts already. They do. Wrong tool for the job. Just about any servlet textbook will give an example where an image was created on the server side, set the appropriate response type, and stream it back to the user. As long as you are creating the image on the fly, there is nothing stopping you from also creating an image map/html that gives you user interactivity. Odds are post/re-paint will be enough. Take a look at mapquest.com or most interactive maps that push you a gif for an example.
Reliance on the client will lead to nothing but heartache IMHO.
+++ UGUCAUCGUAUUUCU
Finally, it should be noted that the upcoming Adobe SVG Viewer 6 (available now in beta plays nice with Mozilla / Netscape 7. (Although a win32 binary only is provided, the team at Adobe stated that they are building for Linux and OS X, too.) Assuming ASV6 will be out by the time your project is done, platform breadth isn't a problem for you.
Beware of statistics... This google graph is very good and someone else has quoted 5% of world wide web viewers are not IE
The internet statistics site estimates 605.60 million online so a litte itsy bitsy (statistically) 5% of that works out at 30.28 million NOT USING IE!
Anyway - besides the point really - it's an enterprise application - how many people (not percent) in the OP's organisation are using IE vs others - if that number is high enough, then go for IE, but make sure you generate standards compliant markup so the enterprises choice of browser is not down to bad coding, but down to features, ease of use, familiarity and other good reasons like that.
Would Flash work for something like that? I'm not sure how the speed compares to Java, though...
I rolled by own active-x dll using Graphics Server 6 to produce jpegs, the image map, and all the supporting html. Upside, Graphics Server is a very robust graphing tool; downside, still has some issues with concurrency. Plus; no client side components needed.
By "enterprise application", I take it this is an application with a large number of users (10,00+), but still internal to your company.
I'd agree with the above post for an external website. About the only two plug-ins that you can reasonably count on people having are Flash and Acrobat Reader. And IE 5+ would limit you to about 90% of the browsing public - you don't want to turn away 10% of your potential customer base.
However, if the application is internal to your company, requiring a plug-in is very reasonable. You do need to make sure you have an easy way to distribute the plug-in and that you have your support people ready when you implement your app. In fact, part of your app should be detecting if someone has the plugin then directing them to the correct page to install it. A plug-in based system linke SVG or Flash is a little easier to install than a Java Runtime Environment. However if you plan on creating more web applications, you may find yourself needing a standard JRE eventually.
I wouldn't limit myself to IE - a better standard would be the W3C's recommendations or you could check out the Web Standards Project. If you must use IE, I strongly recommend IE 6. Again, you may need to upgrade some people's browsers; you just need to include that in your implementation.
first the word "ENTERPISE" is a pet peeve of mine.
exactly what does it mean?
as far as I can tell, its supposed to mean high end software with every feature possible and a much lower than average bug count.
but that dosen't tell you if ie5 is a large enough target market, and itdoesn't tell you if a plugin is acceptable to use.
If you have 100% control over the machines you will be installing on then yes ie5 is an aceptable taget.
it is always acceptable to expepect the user to intall a
plugin if
1. your software is a useful AND
2. your software will be used many many times.
don't expect a user to install some fucking plugin to visit your site once.
as for the technical aspect.
I would use java, based completely on the fact that I know how to use java.
there would be a huge learning curve for me to use flash, or SVG....but I'm not the issue.
go to the guy who is going to do the coding and ask him what technology they know best.
then use it.
--meh--
Take a look at www.sodaplay.com, or news.bbc.co.uk.
Tell me again that Java applets are too slow.
Try to reimplement those applets in Flash, then tell me
again.
-I like my women like I like my tea: green-
SVG to Mozilla
A solid reliable freely-redistributable implementation of SVG, and in Mozilla, would be one of the finest things, IMNHO.
A really good SVG implementation could make give web documents the elevated precision of presentation, akin to PDF, but in a W3C standard.
With extensions such as MathML and dynamic SVG, the format could form the basis of not just web documents, but paper documents (eg, stuff that currently is done in Word, Quark, Framemaker, TeX), as well as dynamic presentations (eg, Powerpoint) and, simple interactive applications that are currently done in text boxes in JavaScript.
Once a freely-available SVG renderer is available, then editing and composition tools for SVG documents should really take off. BTW, I don't count Adobe's SVG viewer because it is restricted to only a handful of platforms and no source is provided.
From what little I understand, the Mozilla SVG effort has been a one man show and entangled in licensing clauses.
It would be really nice if this were all cleared up and a big push into SVG by the Mozilla team were made.
"Provided by the management for your protection."
Here's a link to an adobe site with SVG demos. If you look 4 down from the top, you'll find an interactive chart demo.
I think this may be a good example of what you're looking for.
In terms of support, if you plan on having this application around for a while, SVG is only going to get more popular.
Flash is a good way to do that.
.swf files (as long as your scenes are clean)
- It usually generates small
- It's scriptable so that you can generate dynamic charts without a big effort.
- Everybody's got a flash plugin, as it exists for nearly every OS.
And as the Flash community is really huge on the web, you will easyly find many resources and tutorials about building that kind of animations.
____
nico
Nico-Live
I had to deal with this for the web GUI for one of our products. The solution has gone through a few revisions. The graphs consisted of two pie charts and a bar chart.
:)
Version 1: images generated on the server (perl script using GD). This worked well, but I came to dislike how it had to download a new image every time you refreshed the page. Some of our customers were on pretty slow links. Also, we wanted the next version to work on Windows (v1 was on linux), and the perl/GD thing was going to be a pain. Our product is a web cache, so obviously I'm a bandwidth conservationist, and the bandwidth needed to download the images over and over offended me.
Version 2: images generated on the client using a java applet (purchased...it was only $50 or so). Nice, because the images are generated client-side, but the applet took awhile to download on slow links, and the startup time is BRUTAL. I came to hate this solution.
Version 2.1: pie charts done with Flash, bar charts done with DHTML/javascript. This has been working great! Flash starts up instantly, and almost everyone already has it. The numbers for the graphs are just included in the HTML code, and Flash/javascript uses those numbers to generate graphs. There are 2 numbers for each pie chart, and 60 numbers for the bar graph. Being text, they take up very little bandwidth.
slashdot is pathetic... rules by 12 years olds with a grudge.
DHTML and CSS are probably your best option. you can specify exact screen coordinates which DHTML and place pixels. All the display crunching is done on client side and the layout is done on your side. I have used this same thing for doing placements on a map of the world.
anime+manga together at last.. in real time.
I would note that ColdFusion has tags that draw various graphs. True, there are probably some open-source equivalents, but if you already are using CF, then give it a try. Like everything else, CF makes it pretty easy to get started[1]. (I found some of them buggy, but maybe they have since been fixed.) I believe is generates the graphs on the server, and then just sends a GIF to the browser.
[1] Fast learning/starting and long-term productivity are not necessarily related, I would note. CF is pretty easy to learn, but it is somewhat hard to build certain types of frameworks with IMO.
Table-ized A.I.
I've been using TWiki for collaboration notes, and one of its features is a plugin for charting. It manages to draw jpegs and pngs using the perl GD module and the gd library.
Of course, you'd need to write your own server side to generate the chart you want, but these tools put you easily along that path.
The biggest issue will doubtless be deployment issues in the it department?
1) is it an intranet -- if so then you can use anything.
2) is it an extranet -- if so then you cannot use any plug-ins with IE without runninginto firewall isuues.
3) are you deploying for IE or windows-- usually it deployments are very targeted. If IE then use VML not because it is good, but because you will not have firewall problems. (We had to deal with this) If mozilla, then use svg and require the special mozilla build with integrated svg to be deployed.
YOU DO NOT WANT TO BE IN A SITUATION WHERE A USER CANNOT INTERACT BECAUSE OF A FIREWALL BLOCKING ACTIVEX OR JAVA>
http://www.walterzorn.com/index.htm
haven't used it, but the demo is fast and interactive.
Just use a java whiteboard applet. They are all over, search google.
It's 10 PM. Do you know if you're un-American?
Flash isn't just for animation any more. It's an interactive UI delivery platform.
Write a generalized interactive graphing tool in Flash. Then have it fetch a simple data file (delimited text or XML) via HTTP.
You can update the data dynamically and transmit the results with extremely low overhead.
Flash kicks Java's butt when it comes to availability, reliability, predictability and performance. Flash on Linux is absolutely the same as Flash on Windows or the Mac. It just works.
We have used Flash's ability to fetch dynamic data via HTTP to build "live" traffic and weather maps and perform other integration of constantly changing information.
Two options we use are
JFreeChart (http://www.jfree.org/jfreechart/index.html), which is totally serverside generated. Not sure what you mean when you say you need interactive charting - we let the user spec some params and toss them a graph.
On the other side of the spectrum we also use
SpotFire (http://www.spotfire.com/) which is not at all free, but which is REALLY powerful. Scientists and statisticians seem to love it...
Why don't you try one of the Blue-Pac's Turbine FLASH generation products?
.NET, C++. You can download a free-trial version and follow one of their tutorials. You can even check out great sites that use their products.
They are very cost effective and most important: they are very robust and are able to generate a great deal of already designed and ready to use graphical charts. You just have to select your data-source (DB based, XML, flat text, etc.), quickly configure it and voilá!
It works with PHP, ASP,
Since the formats for a .swf file are publicly available from Macromedia.com or openswf.com and since people and companies outside of macromedia have written software that creates and plays .swf files, how closed is closed? Is it the fact that the format is actually owned by someone and enforced by a license?
If so, we might as well say that Linux is a "closed technology" because of the GPL.
If we have to have FUD, can we at least keep it off the main page?
No Zen is good zen
Flash is probably over kill and a closed technology.
Flash isn't overkill at all. Except for sound. This is essentially the sort of thing it's designed for: to quickly render vector graphics. Notably, it's got a far larger deployment than SVG, Java/Javascript, or VML. Also, because the viewer is closed, it's both compliant with its own standard, and relatively stable. Moreover, it's ubiquitous; it ships with pretty much everything, and can be downloaded in a form appropriate to nearly every major web browser in short order.
But it's not closed technology. Macromedia set up OpenSWF some years back (april 1998, to be specific.) They release all of their specs usually a month or two late; F6MX is indeed out.
Moreover, PHP (and presumably others) have Flash support libraries set up. It seems that PHP+Flash is exactly what you want. It's a little bit of a pain in the butt the first time around, but once you get used to describing everything in terms of arcs, it's actually kind of intuitive. Plus, you get all of the graphics effects that Flash provides. And you can see it on your Palm Pilot. And probably your watch, these days.
StoneCypher is Full of BS
Putting together the responses to date, it seems like this is the story:
SVG: lots of potential; the ideal solution if the plugin is installed or easily installable; XML based
Flash: the pragmatic choice; installed nearly everywhere; works reliably on all platforms; can be driven via XML
VML: good fit for IE 5+ browsers, since it's supported in a default install; unsupported in Mozilla; deprecated technology; XML based
Java applet: slow to startup; JFreeChart looks very powerful provided startup times are acceptable and browser support is available
In case you can't tell, I'm facing the same problem as the original poster. I also can't deploy server-side solutions, so PHP, Perl GD, etc are all out.
Based on this, I'm inclined to build a generic XML solution, then rely on plugin detection and XSLT to deliver either SVG or VML as appropriate. That covers me for IE 5.5+ and anything with SVG support. The largest group that I don't have covered is Mac users and people with older browsers, and I could probably come up with a different XSLT to cope with them if the demand made it worth doing.
The main point of my post was finding a method that would entail the least amount of updating and overall work over the long run. I admit that GNU/Linux is not a threat yet. It is already excellent, but it has not yet worked its way through the market, and it is not yet perfect. However, it is inevitable that Linux will, at the very least, keep its current user base size for some time to come, and this is a substantial enough amount to avoid alienating, if possible.
First of all, seeing all of these flamebaits means one thing, and one thing only.
I wasn't clear enough earlier. Sorry everyone!
Okay, here's take 2:
And of course the obligatory comments about how SVG is easier to script for. (More compatible: DOM/ECMAScript, etc.)
...Flash is not a closed format. The SWF file format is open, and if you have a good reason (i.e. one to boost their interests), macromedia will send you the source code to the player.
Kind regards, Devon H. O'Dell
I'm looking to do this too, and I think I've decided on using perl and gnuplot. You can write the output of a gnuplot to a jpg file quite easily using a few lines like:
/tmp/data.dat" smooth unique
/tmp/data.dat
/tmp/plot.jpg. Now just put this plot into the html. While I haven't done this yet, it was the easiest/cheapest way I could think of.
set terminal jpeg size 480,300
set output "/tmp/plot.jpg"
plot " awk ' { print $6 } '
replot
The $6 corresponds to plotting the 6th column of data in the file
Incorporate these lines into a perl script, and there you go, a jpg image saved as the file
I had to do something like this at my job a few years back, and being unfamiliar with other technologies, I produced graphs using single-pixel wide div tags with the appropriate color. While this worked, and was easily extended to produce axis, labels, and so on, the overhead is far too large. What would have otherwise probably been a 20k gif file ended up being a 2Mb html file.
One of the other comments about drawing with javascript got me curious. Drawing bar charts is easy, just stretch gifs and presto. However, I wanted to do pie charts and found this interesting article.. Probably wouldn't be too hard to throw some trig at it and expand it either.
Server side graphics are a sure way to bog down a web server fast.
Frankly, this a silly question to anyone who knows how to write java applets. They are not slow. You may have require the user to download a recent jre. But aside from the jre download, applets are ideal for this and many other client side code. Do youself a favor and learn how to do them right and you'll be developing much richer portable apps for a long time to come.
I am speaking from experience. Don't let people talk you out of java applets or applications. See for youself. They really do work very well.
http://www.tcl.tk/software/plugin/ for more information, i've kind of figured this is quite interesting stuff though i have no experience but the plugins.
free dom(inion) - free energy - free your mind - whee!
I've been playing with this open-source java charting library for a while now, and it's quite impressive. It can be easily integrated into applets or JSPs.