# Visual editor options for Vue applications

*Source: https://www.editorstack.cc/use-cases/vue-visual-editor-options — last updated 2026-09-17. Licensed CC BY 4.0 with attribution to EditorStack.*

## Summary

- The most-recommended visual editor libraries — Puck, Craft.js, Plate, React Page — are all React-only at an architectural level, so none is available to a Vue application.
- For Vue, the realistic options are framework-agnostic engines (GrapesJS at 294.6 kB gzip, Editor.js at 64.3 kB) or commercial SDKs with first-party Vue support.
- The framework-agnostic route means the editor renders HTML in its own canvas rather than rendering your Vue components, which is the trade you are accepting.

## The uncomfortable starting point

Most articles about visual editor libraries are really about React libraries. [Puck](/libraries/puck),
[Craft.js](/libraries/craftjs), [Plate](/libraries/plate) and [React Page](/libraries/react-page) are
all React-only, and not by packaging — their entire model is React components as editable units.

For a Vue application, that removes four of the eight libraries in our time-to-editor benchmark.

## What remains

**[GrapesJS](/libraries/grapesjs)** — framework-agnostic by design, and the most common answer for Vue
teams. It owns an iframe canvas, communicates through events, and produces HTML and CSS. Mount it in
`onMounted`, destroy it in `onBeforeUnmount`, and keep the editor instance out of Vue's reactivity
system — wrapping it in `ref` or `reactive` makes Vue proxy the whole object graph and produces
confusing failures. Use a plain variable or `shallowRef`.

**[Editor.js](/libraries/editorjs)** — also framework-agnostic, for document authoring rather than
page building. At 64.3 kB gzip it is the cheapest editor here to integrate, and Vue is simply hosting
it.

**Commercial SDKs** — [Builder.io](/libraries/builder-io) has first-party Vue support, which is
unusual among the component-registration platforms and worth knowing if a hosted platform is
acceptable. [Storyblok](/libraries/storyblok) has first-party Vue SDKs on the CMS side.

**[Directus](/libraries/directus)** — its own admin app is Vue-based, which is relevant if you intend
to extend the CMS interface itself.

## The trade you are accepting

With React, Puck's proposition is that the editor renders your production components, so there is no
translation layer. Vue teams do not get that.

With a framework-agnostic engine, the canvas renders HTML. You can define custom component types
whose markup matches your Vue components, but you now maintain two representations and must keep them
in step. That is the real cost of the Vue path, and it is worth naming before the project starts
rather than discovering it in month three.

The compensation is portability: HTML output works in an email, a static export or a customer's own
hosting, and the editor survives a framework migration.

## Integration notes specific to Vue

- Initialise once in `onMounted` against a `ref`'d container element, never a document-wide selector.
- Destroy the editor in `onBeforeUnmount`; without it, a client-side navigation away and back leaves
  two editors stacked in one container.
- Keep the editor instance in a plain variable or `shallowRef`, not in reactive state.
- Give the container an explicit height. A container with no height produces a zero-height canvas,
  which is the most common "nothing renders" report.
- Styles and fonts the canvas content needs must be injected through the editor's canvas
  configuration, because the canvas is an iframe and your application's CSS does not cross into it.

## What we would do

For page building in a Vue product: GrapesJS, with the 294.6 kB loaded on a dedicated editor route and
the twin-representation cost accepted deliberately.

For document authoring: Editor.js, which is framework-agnostic in a way that costs you nothing.

For a marketing site rather than a product feature: a CMS with Vue SDKs, and the
[headless CMS visual editing](/use-cases/headless-cms-visual-editing) page covers that decision.

The [framework-agnostic category page](/categories/framework-agnostic-editors) lists everything in the
dataset that clears the no-framework-lock-in bar, computed from the data rather than curated.


## Frequently asked questions

### Is there a Vue equivalent of Puck?

Not with equivalent maturity. Puck's model depends on rendering React components in its canvas, and the Vue ecosystem has no widely adopted counterpart, which is why Vue teams generally choose a framework-agnostic engine instead.

### Does GrapesJS work with Vue?

Yes. It is framework-agnostic: you mount it against a container element in a component's mounted hook and destroy it before unmount. Community wrappers exist, and the integration is the same shape as in any framework.

### Can I use my Vue components inside the editor canvas?

Not natively with GrapesJS — it renders HTML in an iframe. You can define custom component types that render markup matching your components, but the canvas is not running Vue.

### What about Editor.js in Vue?

It works well for document authoring: Editor.js owns its own DOM, so Vue is hosting it rather than rendering it. For page building it is the wrong tool regardless of framework.