1. 5
  1. 1

    Having dealt with another form of this kind of stupid, I cannot stress strongly enough that people just learn how to draw charts their own damn selves.

    For some reason, people think D3 is the end-all and be-all of graphing, and the fact of the matter is that it is both way overkill and oddly underpowered for certain perverse datasets (as the author here discovered).

    With the major caveat of don’t do this if you need interactive hover/click elements, I would strongly advise doing the charting in raw canvas or, better, WebGL.

    Using the SVG scenegraph has super gross performance issues past a few thousand points, and most of the time a simple raster image does an adequate job of displaying the data without murdering performance.

    If you need to draw a lot of realtime data, use WebGL with dynamic vertex buffers.

    1. 2

      I’ve come to believe the following analogy:

      DOM manipulation : jQuery :: data visualisation : D3

      Better abstractions haven’t been widely socialised.

      1. 2

        Very true! Canvas seemed like an obvious approach when we realized its performance would only vary with the size of the chart instead of the number of points. However, we moved forward with D3 and SVG for a few reasons:

        • time: we had already invested a decent amount of time on the d3 approach and our timeline didn’t allow an entire rework
        • the built-in scales and axes D3 provided: these took a lot of the pain out of a “roll your own approach” leaving us with less overall code to maintain
        • developer familiarity: a lot of our graphs were line charts (which don’t run into the “too many dom elements” problem) and were moving in the direction of D3. Team familiarity with the technology was important for us to be able to continue to implement changes.

        It would be great to explore the canvas option but sometimes the context is just as important as the solution.