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.

Visual editor options for Vue applications

The React ecosystem has Puck, Craft.js and Plate; Vue has none of them. Here is what actually works in a Vue application, and why the answer is usually a framework-agnostic engine.

Updated 2026-09-17

TL;DR

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, Craft.js, Plate and 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 — 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 — 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 has first-party Vue support, which is unusual among the component-registration platforms and worth knowing if a hosted platform is acceptable. Storyblok has first-party Vue SDKs on the CMS side.

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 page covers that decision.

The framework-agnostic category page 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.

Written by the EditorStack Research Team. How we test and what we refuse to publish is on the methodology page.