Hire D3.js Developers

D3 earns its place at the boundary where charting libraries run out - network and dependency graphs, timelines with irregular structure, custom geographic work, anything with a bespoke interaction model. The cost is real, so the honest position is that most charts should not be built with it, and a good D3 engineer will tell you that unprompted.

D3 is not a charting library; it is a set of tools for mapping data onto visual properties, and treating it as the former is how teams end up hand-building a bar chart that a library would have produced in nine lines and maintained for free.

The library-first rule, and the exceptions that survive it

Our own products use ordinary charting libraries for ordinary charts, and that is deliberate. The exceptions worth reaching for D3 on are consistent: a layout no library implements — force-directed graphs, hierarchical edge bundling, irregular timelines; an interaction model that has to be exactly yours, such as brushing that drives four other views; or a rendering requirement, typically point counts a library’s DOM-based renderer cannot survive.

A candidate who cannot name the case where they used a library instead has not made this decision on cost yet.

There is a second-order argument for standardising too. It is easy to end up with two charting libraries in one application, each brought in by a different feature, each with its own theme, own tooltip behaviour and own bundle weight. Once that has happened it is very hard to reverse, which makes “which library, and only that one” a decision worth making early and writing down.

Keep coordinates in data space

The single most useful discipline in custom visualisation work is to store positions in the units your data is in, and convert to pixels only at the moment of drawing.

We have an interactive tool where a user drags four corners onto a photograph to mark a surface. Those corners are stored normalised to the image, from zero to one — never in screen pixels — so zooming, resizing the window or switching devices cannot move them. The projective transform that warps the preview is recomputed from those normalised values on every frame.

If a resize can change your data, you stored a rendering artefact instead of a value. That is the same lesson D3’s scales exist to teach, and it applies whether or not you are using them.

Re-rendering, which is where the bugs actually are

D3 and most charting libraries are imperative, and the frameworks around them are declarative. Everything awkward comes from that seam.

Two rules avoid most of it. Destroy the previous instance before drawing a new one, and on unmount — otherwise every re-render leaves behind listeners, a canvas and, most visibly, the previous chart’s tooltip. And let the framework own the container element while the visualisation owns everything inside it, so the two are never both trying to manage the same nodes.

Continuous interactions — drag, zoom, pan — need one more thing: coalesce pointer events with an animation frame and do the work once per frame. A handler that recalculates on every pointer move is how a visualisation feels heavy on a laptop and unusable on a tablet.

SVG, canvas, and where the ceiling is

Every element in SVG is a DOM node with styling and hit-testing, which is exactly why it is pleasant for a few hundred marks and why it collapses somewhere in the low thousands. Canvas draws pixels and scales far further, at the price of writing your own hit detection and losing accessibility for free. WebGL goes further again and is a specialist commitment.

The honest engineering answer is often neither: aggregate, bin or sample the data first. A scatter plot of two hundred thousand points is rarely a better answer to the question than a density plot of the same data, and it is never a better answer to the question of what the reader can perceive.

Accessibility, which is not automatic here

A custom visualisation is invisible to a screen reader unless someone deliberately made it otherwise. The floor is a text alternative that states what the chart shows and what it concludes, the data available as a table, keyboard access to whatever the mouse can reach, and encodings that do not rely on colour alone.

This is where the cost of custom work shows up most, and it is a reason to choose a library that has already done it.

What we interview for

Ask what they built in D3 and why a library could not do it. Then ask about accessibility and about performance, since a custom visualisation is invisible to a screen reader unless somebody deliberately made it otherwise, and SVG stops being viable somewhere in the low thousands of elements. Engineers who understand visual encoding talk about the reader. Everyone else talks about the animation.

One last question, which is really a values question: show me a chart you removed. Deleting a visualisation that was not answering anything is a skill, and the people who have it are the ones worth hiring for this.