Dependency Graph Viewer — Free HTML CSS JS Snippet

Dependency graphs, service maps, and package trees are usually rendered with heavyweight libraries like D3-force, Cytoscape, or vis-network — multi-hundred-kilobyte dependencies for what is, at its core, two simple physics rules applied every animation frame. This snippet builds a force-directed graph layout from scratch: no physics engine, no charting library, just a requestAnimationFrame loop that nudges node positions based on repulsion and spring forces until the layout settles into something readable. It renders a set of services (API Gateway, Auth, Orders, Billing, a Postgres core, a Redis cache, a couple of shared libraries) as SVG circles connected by lines, and lets you hover or click any node to trace exactly what it depends on and what depends on it.

The two forces: repulsion and springs

Every pair of nodes repels each other, the same way charged particles push apart in a simplified Coulomb's-law model. For each pair, the code computes the distance between them and applies a force proportional to REPULSION / distSq along the line connecting them — closer nodes push apart harder, distant nodes barely notice each other. This is what keeps nodes from all collapsing into a single point. Independently, every *edge* in the dependency list acts like a spring: the code measures the current distance between the two connected nodes, subtracts a REST_LENGTH (90px) to get the stretch amount, and applies a force proportional to that stretch times a spring constant SPRING_K. Stretched-too-far edges pull their nodes together; compressed edges push them apart. Nodes with no edge between them never feel a spring force at all — only the constant repulsion. The interplay of these two forces is the entire layout algorithm: repulsion pushes everything apart, springs pull connected things back together, and the graph naturally organizes into clusters where tightly-connected services sit close and unrelated nodes drift to the edges.

Why damping is non-negotiable

Without friction, a spring-and-repulsion system oscillates forever — every force calculation adds velocity, and with nothing removing energy from the system, nodes would swing past their equilibrium position, get pulled back, overshoot again, and never settle. Real springs lose energy to heat and air resistance; this simulation fakes that by multiplying every node's velocity by a DAMPING constant (0.86) at the end of every frame, after forces are applied but before the position update. Each frame throws away about 14% of the node's speed. Early on, when forces are large and nodes are moving fast, damping barely dents the motion and the layout unfolds quickly. As the layout approaches equilibrium and forces shrink, the same proportional damping increasingly dominates, so velocities decay toward zero and the graph visibly stops jittering rather than vibrating indefinitely. A small constant center-pull force (CENTER_PULL) is also applied toward the canvas midpoint on every node, which keeps loosely-connected corner nodes from drifting off toward infinity since repulsion alone has no bound.

Integration: velocity, then position, every frame

The tick() function runs once per animation frame. It first zeroes nothing — velocities persist between frames — and accumulates every repulsion and spring force into each node's vx/vy. Only after all forces for the frame are summed does it apply damping and then update x/y by adding the (now-damped) velocity. This order matters: computing all forces before touching any position means the physics for this frame is based on a single consistent snapshot of the graph, not a partially-updated one where some pairs used old positions and others used new ones (a subtle bug that produces asymmetric, jittery layouts if forces are applied node-by-node instead of batched).

SVG for rendering, not canvas

Nodes are individual <circle> and <text> SVG elements rather than a single <canvas> bitmap. This trade-off costs a little performance at very large node counts, but it means each node is a real DOM element that can receive its own mouseenter and click listeners directly, and CSS classes like .dim and .edge-active can be toggled with ordinary classList calls and animate via CSS transitions instead of manual redraw logic. For the dozen-to-few-dozen node counts typical of a service map or package tree, this is both simpler to read and cheaper to maintain than a canvas hit-testing layer.

Hover-to-trace highlighting

Selecting a node (via hover, or click to pin) computes its direct deps (outgoing edges) and dependents (incoming edges) by scanning the edge list. Every edge touching the selected node gets an .edge-active class; every other edge gets .edge-dim, which CSS fades to 12% opacity. The same happens for node circles and labels not in the connected set. This is purely a CSS-class-toggle operation layered on top of the physics loop — the simulation keeps running underneath regardless of what is currently highlighted, so hovering never interrupts or resets the layout.