title: d3 and batik: Advantages and disadvantages of server-side svg generation with client side behaviours
body: <p>My company currently has an SVG graphing library an in-house engineer has developed (following the spec laid out in Wilkinson's Grammar of Graphics), which they are keen on reusing in a browser-based data exploration tool. The only thing is that this library serves up static SVG images without any support for interactions.</p>
  
  <p>I'm looking to replace some of the home-baked code with Apache Batik, and augment the graphs with a javascript library to supply interactivity through d3. </p>
  
  <p>For example, a scatter plot would generate on the server side with known css classes, and be included in an html page the user would access, which in turn would utilize d3.js and our javascript library. On load we would select the graph and add the proper mouseover/click/zoom/etc. handlers.</p>
  
  <p>This seems like it will work in theory, but I'm wondering if we're overlooking something.  Is this is a valid/reliable way of doing things, or should we be focusing on one library for creating interactive graphs rather than two?</p>
  
  <p>The area I think might become problematic is with streaming data. It seems to me that we could start with a static graph, but once you start dynamically creating points/lines/etc., you really need to know what rules the graphic abides by (e.g. which variables actually map to a graphed line, its color, etc.), which makes it seem like redundant definitions are needed on both server and client side.</p>
  
  <p>So...what do you think?</p>