<分区>
我目前正在我的工作场所就遗留 Java Swing 应用程序和 d3.js 图形的最终输出之间的接口(interface)设计进行辩论。当前应用程序是一个桌面统计探索工具，使用 Java2d 解析数据并输出图形。该应用程序正在转换为具有 Web 前端的服务器/客户端应用程序。
目前图形逻辑与 Java2d 代码紧密耦合。虽然从技术上讲是 Wilkonson 的图形语法的实现，但图形树中的每个组件都呈现为一个 Java 组件。
我建议重构图形系统以输出图形的结构化规范(json、xml 等)，然后可以将其传递给消费者(前端 Web、ipad 等)进行实际解析和渲染。这会将图形结构与实际渲染分离，理论上允许在任何客户端库或渲染格式中使用相同的输出/蓝图，无论是 d3.js、three.js、svg/canvas/webgl，还是原生的代码。
这对我来说似乎很直观，但我的同事非常反对这个想法。相反，他们建议调整系统以在服务器端生成 d3 javascript 代码，然后客户端将直接使用这些代码。这将需要在每个图的基础上实现所有图设置代码(理论上使用一些模板引擎有条件地在结果 html 中包含 js)。我们的结果将直接与 d3 本身相关联。他们说好处是客户端无需执行任何操作来呈现图形输出。
我是不是漏掉了什么？从长远来看，后一种方法是否更可取？还是我在以前的设计中走在正确的轨道上？在生成 javascript 方法中我应该考虑一些好处吗？或者，我应该如何构建我的论点以支持序列化图形规范，以便让更多人参与我的设计？