The Protovis stays
We have decided to stick with Protovis despite the fact that its creators seem to be abandoning it. This question keeps coming up: Why not move to the new and shiny D3 where the development is taking place?
For one, we didn’t choose Protovis because of its development operation. Protovis’ development process was never very open anyway, its authors only releasing stable versions now and then. That the authors have moved on means nothing; Protovis is already stable and mature — and even if we were to move to D3, there is no guarantee that the authors would continue to stick around with that once it becomes similarly mature.
What it really comes down to is the frameworks’ fundamental architecture. Protovis has abstractions we want but D3 doesn’t.
As users of the libraries already know, D3 is lower-level than Protovis. This enables its users to leverage a wider range of the browser features. The difference does not end there. The two, while superficially similar, are in fact fundamentally different.
[D]ifference is that D3 code describes transformations of scenes (scene changes), whereas Protovis describes representations (the scenes themselves). See →
Protovis users are only able to build and render scenes with objects that the library provides — Labels, Panels, and such — while D3 users interact directly with any type of element or their attributes.
Protovis’ two-step process is, however, its winning characteristic. The rendering is done by a modular rendering layer which is the very reason we have been able to support MSIE. We “simply” replace the SVG renderer with a VML one. D3 would require a full rewrite for all charts.
We are currently serving static charts from a Node.js server using the exact same chart code we use on the client side. It doesn’t take much imagination to see how much a PDF, EPS, Postscript, or Canvas renderer would benefit this setup. This is simply not an option with D3 without chart rewrites. Also, as we add more and more chart types to DataMarket, it will scale a lot better to maintain 2 renderers and a dozen charts, than 1 renderer and two dozen charts.
So that’s why we’re sticking with Protovis.