Interface Design: Serializing Java Graphics to D3.js [closed]

Question

I'm currently in a debate at my workplace about the design of an interface between a legacy Java Swing application and eventual output of d3.js graphs. The current application is a desktop statistical exploration tool that parses data and outputs graphs using Java2d. The application is being converted to a server/client application with a web frontend.

Currently the graph logic is tightly coupled with the Java2d code. While technically an implementation of Wilkonson's Grammar of Graphics, each component in the graph's tree renders out to a java component.

I'm proposing refactoring the graph system to output a structured spec for the graph (json, xml, whatever), which can then be passed on to the consumer (front-end web, ipad, etc) for actual parsing and rendering. This would decouple the graph structure from the actual rendering, theoretically allowing the same output/blueprint to be used for in any client side library or rendering format, be it d3.js, three.js, svg/canvas/webgl, or even native code.

This seems to make intuitive sense to me, but my coworkers are very much against the idea. Instead they suggest tweaking the system to generate d3 javascript code on the server side, which the client will then consume directly. This would require implementing all graph setup code on a per-graph basis (theoretically using some template engine to conditionally include js in resultant html). Our resulting would be directly tied to d3 itself. They say the upside is that the client wouldn't have to do anything to render the graph output.

Am I missing something here? Is the latter approach somehow more desirable in the long run? Or am I on the right track with the former design? Are there some benefits I should be considering in the generative javascript approach? Alternatively, how should I structure my argument, in favor of a serialized graphic spec, in order to get more people on board with my design?

Answer 1

With my limited knowledge as a given, your solution seems to be more generic. Can't you do yours and then run a client locally and grab the D3 JavaScript and output that to the server? I.e., do both in series, with the initial output from your approach as an intermediate stage.

Additional development time may be why they are making their suggestion, so you may have to be able to prove that this won't take you much longer and will provide added benefit.