visjs/vis-network: canvas-rendered node and edge graphs for the browser

Canvas rendering with a stated ceiling of a few thousand nodes

The README is direct about what this is: a visualisation for displaying networks made of nodes and edges, with custom shapes, styles, colours, sizes and images, rendered on an HTML canvas.

Canvas rather than SVG is the decision that sets the performance envelope, and the README states the envelope: it works smoothly in any modern browser for up to a few thousand nodes and edges, and for more than that you should turn on clustering. Anyone planning a large graph should read that line twice. Clustering hides groups behind single nodes that can be opened on demand, which turns an unusable rendering into a navigable one at the cost of not seeing everything at once.

The library also has physics. Nodes are pushed around by a force simulation unless you disable it, which is why a fresh vis-network graph immediately rearranges itself into something readable rather than a random scatter. The alternative is to pin positions yourself and treat it as a plain renderer, which the API allows and which is the right choice for a diagram with a fixed layout.

Installation is the npm package:

npm install vis-network

The README also shows a standalone build loaded from unpkg, which is the escape hatch for a page with no build step, and points at the `examples/network/` directory for more.

DataSet is the model that makes updates cheap

The README's example constructs two `vis.DataSet` objects, one for nodes and one for edges, and hands them to a `Network` along with a DOM container and an options object. That is the whole API surface in a dozen lines, and the important part is what `DataSet` buys you.

Because the data lives in a `DataSet` rather than in a plain array you re-render from, the visualization can be told about a change instead of being rebuilt. Adding a node when a job finishes, or removing an edge when a service is decommissioned, updates the view without touching the rest of the graph. For a live topology view or a log analyser that streams events, that difference decides whether the library feels usable.

The example also shows the shape of the data model: nodes need an `id` and a `label`, edges need a `from` and a `to` pointing at those ids. Edge options like arrows, colour, width and physics behaviour are per-edge, and node options cover shape, size, colour, border, font and image. The `options` object passed to the constructor is where physics and interaction settings live.

One detail in the sample is not accidental: an edge is drawn from node 3 to itself. Self-loops are supported without ceremony, which is a small signal about how much edge-case handling the library has absorbed over its years.

Dual licensed under Apache-2.0 or MIT

The licensing here is unambiguous and worth stating precisely because vis.js projects have historically varied. The README says vis.js is dual licensed under both the Apache 2.0 License and the MIT License, and may be distributed under either. The root holds `LICENSE-APACHE-2.0` and `LICENSE-MIT` as separate files, `package.json` records `license` as `(Apache-2.0 OR MIT)`, and the copyright lines name Almende B.V. and Contributors for 2010 through 2018 and the vis.js contributors from 2018 to 2021.

GitHub records the repository licence as Apache-2.0 rather than as a dual expression, which is a minor discrepancy in the metadata only. The README and the two licence files agree with the manifest expression, so treat the manifest as the accurate statement and ignore the single-value metadata field.

Those copyright dates also explain something about the project. vis.js started at Almende in the Netherlands, and the ownership handover to a contributor-governed project is visible in the dates. The repository is now funded through Open Collective, with funding configuration in `package.json` and Backers and Sponsors sections in the README.

Functionally, either licence is fine for commercial use with attribution. The choice only matters if your legal team has a standard preference, and MIT is the shorter of the two.

Version 10.1.2 is a types-only patch on a 10.x line

The release history is unusually quiet, which for a visualisation library means the API has settled. v10.1.2 on 2026-08-19 contains a single bug fix, adding `.d.ts` files for CSS so editors stop flagging style imports. v10.1.1 on 2026-08-07 adds support for TypeScript 6 alongside TypeScript 5.

That pair of releases is the entire story of recent maintenance, and it is a useful one. A library that publishes a patch release solely to add missing type declarations for CSS is telling you that its type definitions are treated as part of the product, and that the team notices when a new TypeScript major lands.

Feature work is rarer. v10.1.0 from 2026-05-15 is the most recent feature release in this history, and it adds a custom wind function to the physics simulation with a `nodeId` argument. That is a small change that nonetheless signals the physics engine is treated as a subsystem rather than a black box, since a per-node wind force is the kind of thing you need when a layout has a directional bias.

GitHub reports the last push on 2026-09-20, the default branch is `master` rather than `main`, and the repository is not archived. With 350 open issues, expect the tracker to be busy; the README points contributors at `CONTRIBUTING.md` and the project uses semantic-release, which is why the changelog entries follow conventional commit formatting.

Why the manifest says 0.0.0-no-version

Open `package.json` and the version field reads `0.0.0-no-version`. That is not a mistake and it is not a sign of an abandoned package. Releases are cut by semantic-release, which rewrites the version at publish time, so the committed manifest deliberately holds a placeholder.

The practical consequence: do not read the version from the repository. Read it from the npm dist-tag, which the README links as an npm version badge. Anything that reads the manifest directly, including naive vendoring scripts and some lockfile analyses, will get a meaningless value.

The rest of the manifest is more informative about how mature the packaging is. The package is ESM by declaration, with `main` pointing at a CommonJS UMD build, `module` at an ESM build, `browser` at a minified UMD build, and `types` at a declarations directory. The `exports` map is granular, with separate entry points for the peer build and for the standalone build, including specific paths for `standalone/esm/vis-network.js` and `standalone/esm/vis-network.min.js`, which exist for consumers pinning a specific file.

The `files` array confirms what actually ships: `HISTORY.md`, the licences, `declarations`, `dist`, `esnext`, `peer`, `standalone` and `styles`. Styles ship as part of the package, which matters for the physics-based layouts where default appearance comes from CSS.

The test setup tells you how this is maintained

The repository root is a good deal larger than a library this size needs to be, and the reason is testing. There is a `test/` directory with Mocha configuration in `.mocharc.json`, coverage settings in `.nycrc.json`, a full `cypress/` directory with `cypress.config.ts` for browser tests, and a `__snapshots__/` directory, which is how you snapshot-test a canvas rendering at all.

There is also TypeScript configuration split across five files: `tsconfig.json`, `tsconfig.code.json`, `tsconfig.declarations.json`, `tsconfig.types.json` and `tsconfig.lint.json`. Splitting the build, the declaration emit and the lint pass into separate configs is what lets a library type-check itself and still ship clean declarations.

Linting has moved on from the old guard names. There is `oxlint.config.ts` and `oxfmt.config.ts` rather than a single ESLint setup, alongside `.mdlrc` for markdown, `.csslintrc` for CSS, and a `.husky/` directory for commit hooks. `.releaserc.yml` configures the release automation, and `renovate.json` handles dependency updates. The repository also has `docs/`, a `docs-kr/` Korean documentation directory, `common-docs-files/` shared across vis.js projects, `generate-examples-index.json` for the examples site, and `lib/`, `misc/` and `types/` for source.

The README's own build and test instructions are minimal: `npm install`, then `npm run build` or `npm run test`, with rollup config in `rollup.config.js` and `rollup.build.js`. Everything beyond that lives in `CONTRIBUTING.md` and in the documentation site rather than in the README.

Editorial conclusion

vis-network earns its place when you have a graph, a canvas element and a week, which covers a large share of internal tooling: dependency maps, service topologies, link analysis, org charts. Its real strength is the `DataSet` model, since adding a node is a method call and the view updates itself, and physics means you can skip writing layout code entirely. The limits are equally clear. The README states a few thousand nodes and edges for smooth interaction and points at clustering beyond that, so this is not a graph viewer for tens of thousands of vertices, and the layout will never look exactly how you want without fighting the simulation. Licence is the easy part: dual Apache-2.0 or MIT with both licence files in the root, which you can verify in `package.json` as `(Apache-2.0 OR MIT)`. Note that the version field reads `0.0.0-no-version` because releases are cut by semantic-release, so the real version lives in the npm dist-tag, not in the manifest. Install with `npm install vis-network`, or drop in `standalone/umd/vis-network.min.js` from unpkg if you have no build step.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. visjs/vis-network on GitHub