How do Sigma.js and graphology work together?
Updated
Sigma.js and graphology are two separate JavaScript libraries designed to be used together: graphology handles the graph data model and algorithms, while Sigma.js handles rendering and interaction in the browser. You need both because Sigma.js does not store or compute graph data itself — it draws whatever graphology gives it. If you only install Sigma.js, you have a renderer with nothing to render; if you only use graphology, you have graph data and algorithms but no WebGL visualization.
The division of labor
The Sigma.js site states the relationship directly: graphology is "a multipurpose graph manipulation library" and Sigma.js "works in symbiosis" with it.
| Concern | Handled by |
|---|---|
| Graph data model (nodes, edges, attributes) | graphology |
| Algorithms (layout, metrics, community detection) | graphology |
| Rendering the graph in the browser | Sigma.js |
| User interaction (hover, click, drag, search) | Sigma.js |
The site summarizes this as: graphology handles graph data model & algorithms, Sigma.js handles graph rendering & interactions.
A practical consequence: Sigma.js implements no graph algorithms of its own. As the FAQ puts it, "None in sigma.js, but graphology has a lot, from ForceAtlas2 layout to various metrics or even community detection."
Why the split matters in practice
Because the two libraries are decoupled, you can prepare and transform data with graphology without touching rendering code, then hand the finished graph object to Sigma.js. This is also why the answer to "how do I get drawable data from a CSV?" is a two-step process: process the data with graphology, then render it with Sigma.js.
The same pattern applies to other sources. If you export a GEXF file from Gephi, graphology holds the nodes, edges, colors, sizes, and positions, and Sigma.js draws them on a web page.
Getting both into a project
The quickstart on the site gives the install command for an existing project:
npm install graphology sigma
From there, the typical flow is:
- Build the graph in graphology — create a
Graphinstance, add nodes and edges, and attach attributes such as color, size, and position. - Run any layout or metrics in graphology — for example ForceAtlas2, if your nodes do not already have coordinates.
- Pass the graph to Sigma.js — Sigma.js reads the graphology instance and renders it, then handles interactions on top.
If you are starting from nothing, the site points to a CodeSandbox rather than a from-scratch setup, which is the faster way to see the two libraries wired together.
Choosing this stack over alternatives
The main reason to accept the two-library split is scale. Sigma.js renders using WebGL, which "allows drawing larger graphs faster than with Canvas or SVG based solutions." The trade-off, stated on the site, is that this "makes custom rendering way harder to develop."
So the choice depends on your graph size and how much you need to customize rendering:
- Large graphs (thousands of nodes and edges), standard rendering needs — Sigma.js plus graphology is the intended fit.
- Small graphs (a few hundred nodes and edges) or heavily customized rendering — the site says d3.js "is indeed a best fit for you."
Using it inside a framework
For React applications, the site recommends @react-sigma as "certainly" the best approach; the demo on the Sigma.js homepage is built with it, and its source is available to inspect. The page also begins to address Angular usage, so framework-specific wrappers exist beyond plain JavaScript.
What to check before committing
- Confirm your data can be expressed as a graphology graph — CSV, GEXF, and similar sources all go through graphology first.
- Decide whether you need a layout algorithm; if your nodes already have positions, you can skip that step.
- Estimate your node and edge counts. If you are in the low hundreds and need unusual rendering, evaluate d3.js before adopting this stack.