Reorg

The layout is one pass of a tidy tree

The contract is small and worth stating plainly: children are centred under their manager, siblings keep their order, and two subtrees never overlap no matter how deep or lopsided they are. The tree is placed in one linear pass — each subtree is laid out once, then shifted as a unit — which is why a relayout costs about the same whether one person moved or a hundred did. That algorithm is Reingold–Tilford as generalised by Buchheim, and it ships here as d3-hierarchy's tree().

Variable card widths are the one thing tree() does not do by itself, and they do not need a different library: nodeSize([1, ROW_STEP]) makes the horizontal unit one pixel, so a separation function returning cardWidth(a)/2 + cardWidth(b)/2 + 24 is an absolute pixel clearance. In the sample above that is 251 px between the centres of the widest adjacent pair — exactly the 251 px the rule asks for.

Two measurements decided the dependency, both taken before it was added (esbuild bundle, gzip -9; Node 24.6.0 on macOS arm64, 7 runs, 2026-08-31). Importing { hierarchy, tree } costs 1 831 B gzipped, and the median layout of a 5 000-person org takes 1.26 ms. Those are Node numbers on one machine. The figure to trust is the layout reading in the scene readout above: it is the real cost of the last pass, measured in your browser, on your machine. On the machine this was verified on, the shipped route relaid out all 5 000 expanded people in a median 3.4 ms (seven expand-all cycles, 2.5–4.7 ms) — more than the isolated prototype, because this figure includes building the hierarchy from the store, and still far inside a frame. The first relayout after switching dataset costs three to five times that while the code paths warm up. That headroom is the whole reason a full relayout on every edit is a design rather than a compromise.

DOM, SVG or Canvas — and why editing settled it

This is the question the route exists to answer, and it does not have a single-renderer answer. Each column below is honest about what it is good at; the three rows marked with a dot are the ones that stopped being theoretical the moment the org became editable.

The rule as shipped: three tiers, one per frame

The split is not DOM-or-canvas, it is a zoom ladder with three rungs. Cards render as DOM when the zoom is at least CARD_TIER_MIN_K = 0.8 and the culled set is at most MAX_DOM_CARDS = 400. Below either bound the node moves to the canvas — a name pill down to PILL_TIER_MIN_K = 0.28, and a department-hued slab carrying its headcount under that. Zoom alone would not be enough for the first bound: a wide org just above the threshold can still put thousands of cards on screen, which is exactly the case the count catches.

The tier is chosen once per frame for the whole scene, so a view is never half cards and half pills — mixing them reads as a rendering bug rather than as a level of detail. What is decided per node is only whether the text fits: a pill keeps its name while the pill affords at least two characters of it, and a slab keeps its digit while the slab is at least SLAB_TEXT_MIN_W = 24 screen px wide.

Edges are always canvas — every ordinary elbow batched into one path and one stroke, with a second pair for the handful on the path from the root to the selection, which is drawn in the accent. They carry no text, no focus and no input, so they lose nothing by never being elements, and they are the majority of the primitives on screen.

Screen space is what moved the boundary

The first version of this route drew the low tier as filled rectangles with no text, and defended it with a real argument: below the zoom threshold it used, k = 0.35, the narrowest card is under 59 px wide, so its text would be illegible. That argument is true of world-space text — type that lives inside the transformed card layer and is scaled by the camera along with everything else. It is false of screen-space text, which is drawn with the transform reset to the identity and each node’s rectangle projected by hand, so the glyphs stay the size the reader needs however far out the camera is.

Once the label stops shrinking with the camera, the question stops being can we draw a card and becomes can a person read this. That is the whole of the change: the old threshold marked the point where cards stop being drawable, and all three v2 boundaries mark points where something stops being readable. MIN_LABEL_PX = 9 is not a taste — it is the size the shipped card already uses for its smallest line, so the floor was in the stylesheet before it was in the camera.

What the slab tier does not claim

A slab shows its headcount only when it is at least SLAB_TEXT_MIN_W = 24 screen px wide, and a card is between 168 and 288 world px, so the digit band is arithmetic rather than judgement: the widest card first affords a digit at k = 0.0833 and the narrowest one at k = 0.1429. Below that band the number is gone, and at the zoom floor MIN_ZOOM = 0.05 it is gone for every node without exception — a digit would need 480 world px of card and the widest card the width rule can produce is 288.

So this page will not tell you the slab tier is labelled all the way down. At the floor a node’s hue and position are the information: which department, and where in the shape of the org. Identity comes from the surfaces that are still text at that zoom — the breadcrumb naming the path to the selection, and the list pane, which is an indented tree of names and never changes size with the camera at all — while the minimap says where the camera is inside the whole layout, which is the other half of being lost. That is the honest trade: the chart gives up names at the floor, and the surfaces around it do not.

Why the label pass stays cheap

Drawing a label for every node sounds like the expensive choice, and it is bounded by construction instead: a legible label is large, and large labels do not fit next to each other, so the number of them a viewport can hold is capped by geometry rather than by the size of the org. There is one ctx.font assignment per pass, truncation is estimated from an average glyph advance instead of measured, and no per-node state survives a frame.

Measured on the 5,000-person org with every branch expanded, sweeping the camera across the whole tree for the densest region it contains: 76 labels at k = 0.30, 72 at k = 0.15, and 0 at k = 0.05, where nothing is wide enough to label. The whole loop callback — physics, culling and both canvas passes — held a p95 of 0.6–1.7 ms across the three tiers, worst single frame 2.3 ms, against a 25 ms budget. Repeating each drag with the label pass switched off moved the p95 by at most 0.3 ms and made one tier measure slower, so the labels cost less than the spread between two runs. No optimisation was applied, because none was warranted. (2026-09-02, production build, 1360×580 chart in a 1440×900 window, Apple silicon, macOS 26.5, headless Chromium.)

Why editing moved the answer

A viewer could have been pure canvas. An editor cannot. Renaming needs a text field where the card is; dragging needs a hit-test that knows which person is under the pointer; a screen reader needs a real element to point aria-activedescendant at. In DOM all three are free. In SVG the input means foreignObject, which works until it does not. On canvas all three would have to be rebuilt from scratch — more code, worse result. So canvas carries the edges, the pills and the slabs — every label below the card tier — and DOM carries the tier you can type into.

What the switch gives up is the input and the hit-target, not the information. The card tier ends at 0.8 because that is where the card’s own 11 px name, scaled by the camera, reaches the 9 px floor; below it the same name is drawn in screen space on the canvas instead. What does disappear is the field you could type into and the target you could aim a drop at. That is also why editing zooms in first — starting a mutation from an overview tier brings the person into view at 0.8 or closer before the input appears, so an inline editor can never mount on a pill. Selecting a person from the list pane or arriving on one from search goes through the same guard, for the same reason.

The three single-renderer answers, and why each lost

Pure SVG

The same per-element ceiling as DOM, with a worse text story and foreignObject for inline rename. It buys nothing DOM does not already have.

Pure canvas

Focus, text input, hit-testing and the entire accessibility tree would be ours to reimplement — strictly more code, ending up strictly worse.

Pure DOM

No answer for the fit-to-screen view of 5,000 people, which is the first thing a visitor does.

What keeps the DOM bounded

The render set is the culled set plus the focused card plus the dragged one, so the two cards that must exist always do, even when they are off screen. It is a rectangle intersection over an array we already own — no windowing library — and the camera never enters React state, so a pan is one transform write plus one canvas pass and zero re-renders. Watch rendered in the readout above while you pan: it stays a small number.

Smaller, now, than the cap that is supposed to protect it. The card tier only holds at k ≥ 0.8; a card is never narrower than 168 world px and rows sit 120 world px apart, so at that zoom a 1360×580 chart has room for a few dozen cards and no more. The viewport is the real bound and MAX_DOM_CARDS = 400 is the bound of last resort. Swept across all three dataset sizes at the card tier’s floor, with the list pane open and closed — 15,645 camera positions — the count peaked at 37 cards — an order of magnitude under the cap, which at this viewport size is no longer reachable at all. The cap stays because a much larger window, or a much wider card, would make it reachable again; it is honest to say it is not what is doing the work today. (2026-09-02, production build, 1360×580 chart in a 1440×900 window, Apple silicon, macOS 26.5, headless Chromium.)