Rete.js: a TypeScript framework for building node editors and dataflow graphs

What Rete.js actually solves, and for whom

Most graph libraries stop at drawing. They give you nodes, edges and a canvas, and you write the semantics yourself. Rete.js starts from the other end. The README describes it as a framework for creating visual interfaces and workflows, and says it provides out-of-the-box solutions for visualization using various libraries and frameworks, as well as solutions for processing graphs based on dataflow and control flow approaches. That second half is the part that distinguishes it.

The intended user is a developer building a tool where a person assembles a graph and the program then runs it. Think of a small visual scripting surface inside an application, a data pipeline builder, or an internal tool where a domain expert connects processing steps and the result is executed rather than merely displayed. The repository topics list dataflow-programming, flow-based-programming, graph-editor, node-editor and visual-programming, which is a fair summary of the target.

It is not aimed at someone who needs a chart. If the graph is a picture at the end of a computation, the framework's processing layer is dead weight. The value here is in the editor and the execution model being designed together, so that a node's inputs, outputs and sockets are the same objects the runtime walks.

The core and plugin split in the retejs/rete repository

The published package is named rete and its version field reads 2.0.6. Its dependencies are short: @babel/runtime, plus devDependencies on jest-environment-jsdom and rete-cli. That short list is the design. The core package does not bundle a renderer. Rendering arrives through separate plugins, which is why the README talks about visualization using various libraries and frameworks rather than naming one.

The repository layout matches this. At the top level there is src/, test/, rete.config.ts, eslint.config.mjs and a postinstall.js script. The npm scripts are build, postinstall, doc, lint, test and perf, all of which delegate to rete-cli, the toolchain the project publishes alongside the framework. So the build is not a hand-written webpack or Rollup config; it is a config file, rete.config.ts, read by the project's own CLI.

The practical consequence is that "installing Rete.js" is not one decision. You choose the core, then a renderer plugin for your UI framework, then any area, connection or engine plugins you need. The documentation site is where that matrix lives; the README itself only points at the guides and examples.

Installing Rete.js and building a first editor

The README's own starting point is Rete Kit, a scaffolding tool. It lets you select a stack (React.js, Vue.js or Angular, Svelte) and the set of features, and it is invoked with npx, so nothing needs to be installed globally first.

npx rete-kit app

The command prompts for a stack and a feature set, then generates an application. According to the README, the same page links to a complete guide at retejs.org/docs/getting-started for anyone who would rather assemble the pieces by hand.

If you skip the kit, the manual route is to install the core package plus the renderer plugin for your framework, then register the plugin on an editor instance. The README does not spell out that code, so the exact plugin package names and the registration call should be taken from the getting-started guide rather than guessed. What the README does establish is the entry point and the supported stacks.

For working on the framework itself rather than an application, the repository's own scripts are the interface. A contributor would run the test and lint tasks through the project CLI:

npm test
npm run build

Both resolve to rete-cli subcommands defined in package.json. There is also a perf script, which suggests the project tracks performance separately from correctness, though the README does not describe what it measures.

Where Rete.js is the wrong tool

The framework assumes you want an editor, and an editor is a large surface. If your requirement is to render a fixed graph that the user cannot change, you are paying for node creation, socket validation, connection rules and a plugin ecosystem you will not exercise.

The plugin split is the second constraint. Because the core ships no renderer, the quality of your experience depends on the renderer plugin for your stack, and those plugins are separate packages with their own release cadence. A version mismatch between the core at 2.0.6 and a renderer is a real failure mode, and it is the kind of problem that shows up as a type error or a blank canvas rather than a clear message. Check the plugin's published version before you build on it.

The release history is worth reading before you plan an upgrade path. Between v2.0.4 and v2.0.5 there were two releases on the same day, 2024-08-30, and then v2.0.6 arrived on 2025-06-30. That is not a steady train of patches. Plan for the possibility that a fix you need lands on someone else's schedule.

Finally, the README does not document rollback, migration between major versions, or a compatibility table for the plugin ecosystem. Those gaps mean the getting-started guide and the examples are your real specification, and you should read them before committing to the framework rather than after.

Rete.js compared with React Flow, and with Litegraph

The most common comparison in search data is Rete.js against React Flow, and the difference is architectural rather than cosmetic. React Flow is a React component library for rendering node-based UIs. You get the canvas, the nodes, the edges and the interaction handling, and you supply the state and the behaviour. Rete.js is framework-agnostic at the core and supplies a processing layer for graphs, with rendering delegated to plugins. If your application is React and your graph is mostly presentation with a little logic, React Flow asks less of you. If your graph has to be executed, and especially if you might later need the same editor in a non-React stack, Rete.js's separation is the more durable shape.

Litegraph.js is the other name that comes up. It is a self-contained node graph engine with its own canvas rendering, which means fewer moving parts to assemble and less freedom to swap the renderer. Rete.js trades that convenience for the plugin boundary. The trade is only worth it if you actually intend to use the boundary.

Angular users appear in the search data often enough that it is worth stating plainly: Angular is one of the stacks Rete Kit offers, so it is a supported path rather than a community workaround.

Licence, maintenance and upgrade cost

The licence is MIT, both in the README and in the package.json license field. For most teams that means you can use the framework in a commercial product, modify it and redistribute it, provided the copyright notice and permission notice are preserved. This is a summary of the licence identifier, not legal advice; read the LICENSE file in the repository for the actual terms.

The repository is not archived, and the last push was on 2026-09-13, which is recent relative to the 2.0.6 release of 2025-06-30. That combination suggests work continues between releases, but it also means the default branch can move ahead of the published package. If you install from npm you are on 2.0.6; if you want what is on main you are building from source with rete-cli.

The upgrade cost is concentrated in the plugin boundary. Every renderer and feature plugin you add is another version to track against the core. There is no compatibility table in the README, and no documented rollback procedure, so pinning versions in your lockfile is the practical defence. A project that adopts the core plus one renderer has a small surface to maintain. A project that adopts the core plus a renderer plus several feature plugins has several independent release schedules to reconcile, and that is the number to estimate before you start, not after.

Editorial conclusion

Adopt Rete.js when the graph itself is the product: an internal tool where users wire nodes together and the wiring is executed, or a product where the editor is the main surface. Do not adopt it for a static diagram, a flowchart export, or a one-off canvas drawing; a plain SVG or a diagramming library will cost less. Before committing, scaffold a project with npx rete-kit app, confirm that the generated stack matches your framework, and check that the plugin you need for your renderer is still published for the version you install. The core package is version 2.0.6, so pin your plugin versions against that release rather than against the documentation site alone.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. retejs/rete on GitHub