There's a good open-source page builder for React. It's called Puck, and it's genuinely well-built: you register your own React components, users drag them onto a canvas, and you get back JSON that you render in your app. This way, there is no proprietary lock-in, no hosted service you have to pay for.
But if you work in Vue, you don't have that. The maintainers have been clear they're not porting Puck to Vue, and nothing in the Vue ecosystem fills the same gap at the same quality. Your options are a proprietary SaaS builder or rolling your own from scratch.
I spent the last few years working on a production site editor, so "roll your own" didn't scare me as much as it probably should have. I started building one and it's called Gissen. It's MIT-licensed, and this post is an honest snapshot of the current state of the architecture, including what is still missing.
The shape of it: headless, config-driven
The core idea is the same one Puck got right: you don't theme the editor, but you bring your own Vue components, register them with a typed config, and the editor just arranges them.
Here's the actual config from the example app:
import { defineGissenConfig } from 'gissen'
import Hero from './components/Hero.vue'
import FeatureCard from './components/FeatureCard.vue'
import Container from './components/Container.vue'
export default defineGissenConfig({
components: {
Hero: {
fields: {
title: { type: 'text', label: 'Title' },
subtitle: { type: 'textarea', label: 'Subtitle' },
cta: {
type: 'select',
label: 'CTA',
options: [
{ label: 'Get started free', value: 'get-started' },
{ label: 'Learn more', value: 'learn-more' },
] as const,
},
},
defaultProps: {
title: 'Build pages visually',
subtitle: 'Drag and drop your own Vue components. No lock-in.',
cta: 'get-started',
},
render: Hero,
},
// ...TextBlock, FeatureCard, Container
},
})
render points at a plain Vue SFC. Nothing in Hero.vue knows that it's inside the editor — it's the same component you'd ship to production.
Mounting the editor is one component:
<script setup lang="ts">
import { GissenEditor, type GissenData } from 'gissen'
import { ref } from 'vue'
import config from './gissen.config'
const data = ref<GissenData>({ root: { props: {} }, content: [] })
</script>
<template>
<GissenEditor v-model:data="data" :config="config" />
</template>
The output is data — plain JSON. Every node is { type, props }, and containers nest children and that's the whole document model.
Types are inferred from the field definitions
The fields block is the source of truth for the component's prop types.
InferFieldType is a conditional type that maps each field kind to a TypeScript type: text/textarea to string, number to number, boolean to boolean, slot to a list of child nodes. The select option is interesting — it pulls the literal union straight out of the options:
// select options: [{ value: 'get-started' }, { value: 'learn-more' }] as const
// inferred type: 'get-started' | 'learn-more'
That's why the as const on the options array matters: drop it and TypeScript widens the values to string, and you lose the union.
From there, a mapped type builds the full props object, defaultProps is checked against Partial<InferredProps>, and render has to be a component accepting those props plus an id. So if you add a field to the config and forget to handle it in defaultProps, or wire up a component whose props don't match, it's a compile error.
Rendering without an iframe
A lot of visual editors render the canvas inside an iframe to isolate styles, but Gissen doesn't. Components mount directly into the same DOM:
h(config.render, props, slotMap)
Scoped styles survive for free, because there's no trick involved — these are real Vue components mounted normally. Vue's scoped CSS works through data-v-* attributes, and it doesn't care whether the component is rendered in the editor or in production. It means no CSS-in-JS, no shadow DOM, no style injection. Your component looks identical on the canvas and in the real app, which is the entire point of the "headless" approach.
The only editor-specific addition is a single <div class="gissen-node"> wrapper around each instance, for selection and drag handling. It exists only in the editor; it won't be in the production render.
One thing worth flagging: the canvas uses a render function (h()) rather than a template on purpose. Slot names are derived from the config at runtime — a slot field named children becomes <slot name="children" />. Dynamic, config-derived slot names are unreliable in Vue's template syntax, so the render-function approach is a deliberate choice.
The part that was actually hard: drag-and-drop
The drag-and-drop is built on vue-draggable-plus, which wraps SortableJS. But "use a library" hides how much glue sits between a DOM-mutating sort library and a reactive Vue store. A few things that cost me real time:
Index translation. SortableJS returns newIndex as the final position (starting from 0) after a drag. For insertion, the store needs the slot index. When dragging forward, these values don't match, since removing the dragged element initially shifts everything to the left:
const storeIndex = newIndex > oldIndex ? newIndex + 1 : newIndex
Off by one in one direction only.
Reverting the DOM before mutating state. SortableJS physically moves DOM nodes before your callback is triggered. If you then modify the store and let Vue patch, Vue is diffing against a DOM that's already been rearranged behind its back, resulting in visual glitches. So the handler first puts the DOM back where it started (removeChild + insertBefore at the old index), then mutates the store, so Vue patches from a clean baseline. On onAdd, the cloned node SortableJS injects from the sidebar gets removed immediately too: the store is the source of truth, and the DOM is not.
Cycle prevention. Containers can be nested, which means you can try to drop a container into itself or into one of its own descendants. SortableJS's put validator rejects that via an isAncestorOf(component, targetParentId) check. This check distinguishes "nested drag-and-drop" from "document corruption."
None of this shows up in a demo video. It's the kind of work that's invisible when it's done right.
Agent-native by design (not yet by implementation)
Here's the bet I'm making. The document is plain JSON, and the config is a typed grammar describing which components exist and what props they take. That's exactly the shape an LLM agent needs to build or edit a page programmatically — same JSON a human produces by dragging, same config constraining it.
The plan is to create an MCP server that will directly provide access to this for agents. I'd like to clarify the status: this server is currently under development. The package exists, the CLI prints "not yet implemented," and there are zero tools wired up. So Gissen is designed to be agent-native; it is not yet agent-native in practice. I'd rather say that plainly than imply something ships that doesn't.
Where it actually is
Pre-alpha. Don't put it in production. Honestly:
Working: the editor canvas, drag from a component palette, reorder, nest into containers, select and delete, the typed config, and JSON output via v-model:data.
Not yet: editing prop values (the properties panel currently shows the selected component's type and a "coming soon" note — no editable fields), the MCP server, and a production render helper. You can get the JSON out today, but there's no shipped GissenRender to turn it back into Vue outside the editor — for now you'd render it yourself.
The public API today is small and honest: GissenEditor, defineGissenConfig, a few data utilities, config/data validation, and the types.
npm install gissen
Repo: https://github.com/gissen-dev/gissen
I'm building it in the open and the early architecture decisions are the most useful time to get feedback, so if you've built something like this in Vue I'd like to hear how you handled it. And any feedback is welcome.