Lately I have been evaluating several web-based charting packages.
Each has their own unique advantages and disadvantages in terms of
price, performance, functionality, and licensing constraints.
At the same time, I have also had a few discussion with aquaintances
about the 'ideal' methodology for building web apps.
Most of the discussions centered around the age-old debate of thin-client vs rich-client.
Though new technology acronyms come and go, we have been through this debate
in all sorts of past products (POS, kiosks, gas pumps, games, as well as web).
I put together this quick forecasting and charting demo as a simple
example of a browser-based rich-client using Flash and Javascript
as well as a test for different charting tools.
(Click to skip straight to the demo)
In the extreme case, a thin-client is a device or application that only does trivial I/O:
display preformatted data and send raw user responses back to the server.
On the other extreme, a rich-client could be an interactive application that does
advanced processing and rendering: the server is nothing more than a remote database service.
Unfortunately, the real world is a bit more complicated and most systems fall somewhere in-between.
In the case of interactive web applications, there are several choices of technologies
including standard HTML as well as plug-ins like Flash/Flex, ActiveX, and .NET Smart Clients.
The latter provide more flexibility, but most still favor traditional HTML and Javascript
due to their widespread use and platform independence.
Still, the HTML/AJAX route has some pitfalls
due to the variances/quirks in the different browser's handling of (X)HTML, Javascript,
and the XML/HTML DOM's. There are also many ways to implement and segment an N-tier system
so a long line of decisions need to be made:
- Which technology acronym to use on the server: ASP, JSP, PHP, RoR, etc?
- Is the HTML rendered server side or client?
- If client, is the data transformed to HTML using XSLT or Javascript/AJAX?
- Was the data sent as XML or JSON?
- Was the data shipped with the original request or a separate service call?
- If service, was the request SOAP or REST?
- Does validation and business logic happen on the client, server, or both?
- The list goes on...
Personally, I love the scalability and performance of pushing work onto the client.
I also love the responsiveness and interactivity of technologies like AJAX and Flash.
At the same time, there is still some potential for compatability and support headaches,
so my preference is to only use AJAX or Flash in targeted cases (not for the entire site).
I'd reserve ActiveX and Smart Clients to intranets where
compatability issues and objections have already been addressed.
Charting packages seem to run the gamut of dynamic client-side Flash to server-rendered static images (and even static Flash content).
The presentation and business logic layers in an N-tier system are usually easily scaled
by adding more servers/bandwidth/caches without too much of an additional cost.
So while it is feasible to render charts on the server,
you can't beat the interactivity of generating them on the client.
At this point my preference is client-side Flash.
You can pull data from a static file, a web service, or generate it on the fly using Javascript.