Why Nuxt Board
The product problems Nuxt Board solves and the boundaries it keeps explicit.
Nuxt Board gives your application a board model that exists independently of the component tree. That matters when the canvas is part of a product rather than a disposable visualization.
What it owns
The headless engine owns spatial state and behavior: nodes, hierarchy, camera, selection, commands, validation, events, and JSON Canvas persistence. @lupinum/vue-board owns DOM interaction and rendering. Optional packages own connections and history.
This separation gives application code one mutation path. A command can be guarded, validated, recorded in history, and observed without coordinating several Vue stores.
What you keep
Your product owns business rules, backend execution, and domain data. Custom Vue renderers control how records look. Nuxt Board does not turn a planning card into a task service or a workflow node into an execution engine.
Why the limits help
Nuxt Board supports the JSON Canvas node types: text, file, link, and group. Custom renderers change presentation without introducing another node schema. First-party plugins add bounded capabilities instead of an unrestricted extension system.
The cost is less speculative flexibility. The benefit is one document model, predictable persistence, and fewer invalid combinations.
Choose Nuxt Board when those boundaries match the system you want to maintain.
Strong fit
- Users arrange, resize, group, select, or connect structured records.
- Board state must exist outside the Vue component tree.
- Mutations need guards, atomic batches, events, validation, or undo boundaries.
- Custom Vue components should render a stable document schema.
- JSON Canvas is a useful persistence or interchange format.
- Connections, history, and minimaps should remain optional.
Look elsewhere when
- You only need a static graph renderer.
- Freehand drawing and vector illustration are the primary interaction.
- You want a complete collaborative whiteboard product rather than a library.
- Your graph is already modeled around another library's node and edge model.
- You need backend workflow execution; Nuxt Board only owns the editor surface.
Graph-first components such as Vue Flow are a better fit when handles and edges define the product. Drawing libraries such as Konva or Fabric are a better fit when shapes and low-level scene manipulation are the core abstraction. Complete whiteboard SDKs fit products that value a prescribed toolset over a narrow Vue-specific engine, while static renderers such as Mermaid fit non-interactive diagrams.
The deciding question is where canonical state should live. Choose Nuxt Board when you want a headless board document changed through explicit commands.