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

Backend	Where it runs	Status in Nodus
WebGPU	Browsers exposing navigator.gpu	Shipped — the preferred web renderer
WebGL2	Browsers without WebGPU	Shipped — wgpu’s WebGL2 backend
Canvas 2D	Any browser	Shipped — automatic CPU fallback
SVG	Any browser	Shipped — vector export
Metal	macOS / iOS (native)	Capability — wgpu native backend, used for headless rendering in tests
Vulkan	Linux / Windows / Android (native)	Capability — as above
DX12	Windows (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.

Compute shaders are WebGPU-only

GPU compute steps (culling, GPU-side force) require compute shaders, which WebGL2 does not have. On WebGL2 those steps fall back to CPU paths. Native backends (Metal/Vulkan/DX12) and WebGPU support compute.

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

• The Rendering Pipeline — how a web renderer is chosen and falls back.
• Architecture — the crates and the WASM boundary.
• The WebAssembly Backend — activating the compiled compute paths.