Robust Web Application Charting in Grails

So I'm working on a web-app development project where my customer wants some nice "dashboard" charts for the status of pieces in the system. I'm building it in Grails (which is t3h s3x.), and my initial approach was to use the JFreeChart library. I've used JFreeChart before in school J2SE development projects, and was familiar with its API, so it seemed like it would be a good alternative.

Using JFreeChart is really easy in Grails. Here's a quick recipe:

1. Download JFreeChart and JCommon jar files
   
2. Place the jar files in the "lib" directory of your grails-app
3. When you want graphs, import them and use them as regular jar files, like so:

Using JFreeChart in a Utility class

I find that it's generally good practice to encapsulate dependencies, so I created a class to wrap drawing that essentially follows the example given in the JFreeChart source for creating a dial chart. Then, I created a service to handle charting, since that is something that I expect to use in many controllers (DRY is good)

Creating a Service to manage drawing

Using this service in my controllers becomes really easy.

Controller

View

This was all well and good...until I viewed the images. They're ugly. Pug fugly. Like, ugly ugly.

So what's a boy to do? Well, I found a cute little library called HighCharts. Its graphs are sexy. They're fairly easy to make, too. So I built one. It was cool. Now I was going through the odious task of removing JFreeChart. Why?

1. its added a lot of bloat to the code
   
2. it's not good to mix approaches for doing the same thing in different places

But it's an "odious" task and I'm loathe to do it, because the charts generated "work." They're just "not pretty", which can probably be adjusted with some parameters and a deeper dive into the JFreeChart Theming API. It's just extra work, and this solution seems to work better...

Just as I was about to remove JFreeChart, I realized something: I had switched my charting approach from server-side to client-side. Good for processing. The client-side implementation relies on Javascript, of course. What if it was turned off? That could be a 3am support call...so should I do everything in JFreeChart?

Until I remembered my old friend, the <noscript> tag. If I use that, I have a configurable approach. If Javascript is enabled, make a HighCharts chart. If not, I still have my old server side chart ready to go.

One could argue that worrying about Javascript being turned off in this day and age is silly. Plus, managing both libraries and mechanisms for chart drawing is a maintainability concern moving forward. But in so doing I get some functional robustness.

I'm fairly certain the trade-off between robustness and efficiency/ease of maintainability is fairly common. The correct resolution of the tension of these forces depends on the requirements. Nevertheless, it's a good thing to look out for:

If your server side code can avoid doing stuff, avoid it by doing it client side. But keep the flexibility in there in case the client side can't.