Why I built graphraum
I built graphraum because a graph is not just a scatterplot with lines added.
In an interactive network, nodes and edges have identity. Edges must follow node updates. Picking must return stable graph IDs. Selection, focus, hover, labels, layouts, and level of detail all depend on graph topology. A general visualization engine can draw the primitives, but the application still has to build and maintain this graph-specific contract around it.
graphraum makes that contract the product. It is a small, framework-neutral WebGL engine for interactive node-edge graphs in 2D and 3D—not a charting suite, map application, graph database, or complete analysis UI.
What I needed
Section titled “What I needed”Graph-native customization
Section titled “Graph-native customization”The visual API maps typed node and edge attributes to size, shape, color, and presentation metadata. The renderer preserves stable IDs, incident-edge relationships, selection states, picking, and incremental position updates. Applications keep ownership of domain semantics and can build their own labels, inspectors, accessibility tree, and actions above the canvas.
That separation matters. A knowledge graph, fraud investigation, dependency map, and biological network may all use circles and lines, but they do not mean the same thing and should not inherit the same product UI.
Layouts without locking the renderer to one algorithm
Section titled “Layouts without locking the renderer to one algorithm”Positioned data remains the renderer input. applyLayout() accepts transferable XYZ batches, so layouts can run in a worker, on a server, or incrementally.
The package also provides a dimension-aware force simulation for applications that need a default. It supports static, live, and data-clustered operation with tunable repulsion, link distance, spring strength, center attraction, and damping. In 2D, Z stays zero; in 3D, the same contract operates across XYZ. The helper is optional rather than embedded in the render loop.
Predictable graph performance
Section titled “Predictable graph performance”The baseline renderer uses one instanced node mesh and one edge line geometry: two draw calls. It updates affected buffers instead of building a component or scene object per entity. In 2D, viewport materialization and density LOD bound the visible node and edge work; diagnostics expose candidates, visible counts, LOD decisions, draw calls, CPU frame time, and GPU timing when the browser supports timer queries.
These choices do not prove that graphraum is universally faster than another library. Performance depends on fixture topology, update frequency, node size, overdraw, pixel ratio, browser, and hardware. The playground Prove protocol reports its method and lets the claim be tested on the machine that matters; the Explorer is for live visual checks, not published scores.
Open source deliberately, under Apache-2.0
Section titled “Open source deliberately, under Apache-2.0”graphraum is deliberately released under the permissive Apache License 2.0. The renderer is infrastructure: applications should be able to inspect it, profile it, fork it, replace parts of it, and ship it without a framework, hosted-service, or reciprocal-license commitment. Apache-2.0 also provides an explicit patent grant.
Open source is not a unique advantage over every alternative. deck.gl, Kepler.gl, Plotly.js, Sigma.js, and Cytoscape.js are also open-source projects, and several use MIT. The decision is about graphraum’s own contract: the rendering hot path, limits, diagnostics, and benchmark protocol stay inspectable, and product teams are not asked to trust an opaque performance claim.
Shift graph and performance decisions left
Section titled “Shift graph and performance decisions left”graphraum treats validation and observability as development-time tools rather than production surprises. Public inputs fail with actionable errors. Diagnostics report draw calls, resource counts, visible candidates, LOD state, CPU frame time, and GPU timing when available. The executable benchmark records fixture size, browser, pixel ratio, protocol, and distributions instead of publishing one context-free FPS number.
That is the “shift left” goal: discover invalid topology, unstable layouts, excessive overdraw, memory pressure, and unsuitable LOD thresholds while designing and testing the graph experience. It does not mean every workload is fast by default; it means the decisions and their consequences are visible early enough to change them.
How the alternatives differ
Section titled “How the alternatives differ”| Project | Primary abstraction | Where it is stronger | Why it did not replace graphraum | | --- | --- | --- | --- | | deck.gl | GPU-accelerated visualization layers | Large geospatial and general-purpose visual layers, map projections, a mature layer lifecycle, binary attributes, and custom layers | Nodes and edges remain separate layer data. Graph identity, incident-edge updates, graph layouts, graph-aware LOD, and presentation semantics must be assembled by the application. | | Kepler.gl | Complete geospatial exploration application and React component | Uploading, filtering, styling, aggregating, and exploring large location datasets with a ready-made map UI | Its product boundary is geospatial analysis, with MapLibre/deck.gl layers and Redux-managed application state. graphraum needs no basemap, latitude/longitude contract, React, or prescribed explorer UI. | | Plotly | Declarative scientific and business charts | Axes, legends, annotations, statistical charts, notebooks, dashboards, and publication-oriented output | A network is typically assembled from scatter and line traces after layout is computed elsewhere. That is useful for presenting a graph, but it is not a graph-native mutable rendering contract. | | Sigma.js | WebGL graph renderer backed by Graphology | Mature 2D network rendering, Graphology integration, extensible node and edge programs, reducers, and graph-focused interaction | Sigma is the closest conventional renderer, and it is often the better choice for a Graphology-first 2D application. graphraum was built for one typed contract spanning 2D and 3D, bounded viewport materialization, and a deliberately small two-draw-call baseline. | | Cytoscape.js | Graph theory, analysis, visualization, and layout ecosystem | Rich graph operations, selectors, styles, compound graphs, and a broad layout extension ecosystem | Its larger graph-analysis and styling surface is valuable when those features are required. graphraum keeps analysis and product semantics outside the renderer to make the hot path smaller and more predictable. | | Cosmograph | Large-scale GPU graph visualization and GPU force simulation | GPU-accelerated force layout and an integrated exploration stack aimed at hundreds of thousands or millions of graph elements | Cosmograph is the stronger choice when GPU force simulation is the central requirement. graphraum instead prioritizes a framework-neutral rendering primitive, application-owned UI, interchangeable layouts, typed visual compilation, 2D/3D parity, and observable render decisions. |
The important trade-offs
Section titled “The important trade-offs”graphraum deliberately gives up breadth:
- It does not provide a complete analysis application like Kepler.gl or Cosmograph.
- It does not provide chart grammar, axes, or publication output like Plotly.
- It does not provide the graph-algorithm and layout-extension breadth of Cytoscape.js.
- It does not provide deck.gl’s map projections and general layer ecosystem.
- Its force simulation is CPU-based and bounded; it is not a substitute for Cosmograph’s GPU simulation at million-node live-layout scale.
In return, the engine can make graph-specific decisions directly: stable identity, topology-aware updates, node picking, two-dimensional viewport culling, density LOD, 2D/3D rendering, transferable layout batches, and diagnostics that explain what was actually drawn.
When to choose graphraum
Section titled “When to choose graphraum”Choose graphraum when the graph is part of a product rather than the whole product: you need a fast graph canvas, but want to own the application state, layout strategy, semantics, controls, labels, and accessibility experience.
Choose another tool when its primary abstraction already matches the job. A map should usually start with deck.gl or Kepler.gl; a dashboard chart with Plotly; a feature-rich 2D Graphology explorer with Sigma; graph analysis with Cytoscape.js; and a million-node live GPU force simulation with Cosmograph.
Sources and comparison basis
Section titled “Sources and comparison basis”This comparison is based on the projects’ official documentation, accessed in August 2026:
- deck.gl documents its performance model, layer architecture, and custom layer options.
- Kepler.gl describes itself as a geospatial analysis application built on MapLibre GL and deck.gl and documents its geospatial layer types.
- Plotly documents WebGL trace performance and its network-graph construction.
- Sigma documents its WebGL renderer and extensible programs.
- Cytoscape.js documents its graph model, layouts, styling, and performance considerations.
- Cosmograph documents its GPU force-layout architecture.
No cross-library FPS ranking is claimed here because the repository does not yet contain a controlled, like-for-like benchmark of these systems.