Skip to content
Nodus

Backends & Targets

Nodus is built on portable foundations: a pure-Rust compute core and a renderer on top of wgpu, the same GPU abstraction that powers WebGPU in browsers and native graphics APIs on the desktop. This page is precise about what runs where — separating what ships in the package today from what the architecture is capable of.

For the renderer-selection logic on the web, see The Rendering Pipeline. For the crate layout, see Architecture.

Two portable layers

Nodus has two layers, and both are written to be backend-agnostic:

  • Compute (nodus-core) — the graph model, geometry, spatial indexing, layouts and the hypergraph stack. It has no web dependencies, so it compiles unchanged to WebAssembly and to native targets.
  • Rendering (nodus-render) — built on wgpu, which targets WebGPU on the web and native GPU APIs off it. The renderer takes its drawing surface from a host, so the same renderer can draw to a browser canvas or, in principle, a native window.

Backends Nodus can draw with

BackendWhere it runsStatus in Nodus
WebGPUBrowsers exposing navigator.gpuShipped — the preferred web renderer
WebGL2Browsers without WebGPUShipped — wgpu’s WebGL2 backend
Canvas 2DAny browserShipped — automatic CPU fallback
SVGAny browserShipped — vector export
MetalmacOS / iOS (native)Capability — wgpu native backend, used for headless rendering in tests
VulkanLinux / Windows / Android (native)Capability — as above
DX12Windows (native)Capability — as above

On the web, all four web paths are part of the published @kortexya/nodus package. The native GPU backends come from wgpu and are wired for non-wasm builds — today they are exercised for offscreen / headless rendering (for example, the renderer’s own test suite renders to an offscreen texture on a developer machine via Metal, Vulkan or DX12).

”Anything that runs WebGPU”

Yes — because the renderer is a wgpu renderer, it speaks the same API that backs WebGPU everywhere wgpu is supported:

  • In the browser, that’s WebGPU directly (with WebGL2 and Canvas 2D as fallbacks).
  • Natively, wgpu maps to the platform’s modern graphics API — Metal on Apple platforms, Vulkan on Linux/Android, DX12 on Windows — so the rendering code is not tied to the browser.

The compute core is equally portable: the exact same Rust that runs in WebAssembly compiles to a native library.

What ships today

To be unambiguous about the current release:

  • The distributed product is the web package — @kortexya/nodus on npm, a WebAssembly build that renders through WebGPU / WebGL2 / Canvas 2D and exports SVG. This is what Installation sets up.
  • Native GPU rendering is real but used internally — the renderer’s native wgpu backends drive headless/offscreen rendering (e.g. in tests). They prove the renderer is genuinely portable, not web-locked.
  • There is no packaged desktop or server application yet — no native windowed binary, no Electron/Tauri bundle, no server-side render service is shipped. The renderer is designed to accept a native window surface from a host (the surface is supplied by the host — a browser canvas today), but a windowed native host is not part of the current distribution.

In short: the engine is architected to run anywhere wgpu runs, and the compute core anywhere Rust runs — while the product you install today is the browser engine. If you need a native target, the portability is built in; it just isn’t a packaged deliverable in this release.

Why this matters for you

  • Building a web app? You already have everything — WebGPU when available, graceful fallback when not. Nothing to configure.
  • Thinking about native or embedded rendering? The compute core and the renderer are portable by construction; a native host would supply a window surface to the existing renderer rather than require a rewrite.
  • Need deterministic, headless output? The same engine renders offscreen, which is how visual tests are produced.

Next