Adding a visual editor to a Next.js application

The one constraint that shapes everything

Every editor here mounts against a live DOM and, in the case of GrapesJS, an iframe canvas. None of them run on the server.

In the App Router that means the editor is always a client component, loaded with a dynamic import:

'use client';
import dynamic from 'next/dynamic';

const Editor = dynamic(() => import('@/components/Editor'), { ssr: false });

This is not a limitation to work around; it is the correct architecture. The editor is an authenticated tool, not public content.

The pattern that works

Editor route (/admin/pages/[id]/edit) — client component, dynamic import, SSR disabled, behind authentication. Bundle size here is a UX consideration for a handful of internal or paying users, not a Core Web Vitals concern.

Public route (/[...slug]) — server component that fetches the stored page data and renders it. For Puck, that means importing Render rather than Puck, which keeps the editor entirely out of the public bundle.

Storage — your database. All the libraries in this dataset hand you data and step back; none of them require a vendor store.

The separation between these two routes is the whole integration. Get it wrong and you ship an editor bundle to every visitor.

Which library fits Next.js best

Puck is the smoothest fit. The editor is a client component, the renderer works in server components, and the documentation targets the App Router directly. Our benchmark measured 90.4 kB gzip for the editor with React external.

GrapesJS works well with the dynamic-import pattern and is the choice when output must be HTML or the editor must also run outside React. It is the heaviest at 294.6 kB gzip, which is fine on an editor route and unacceptable on a public one. The GrapesJS in Next.js guide has a server component that loads the project and a client component that mounts the editor, built and run in CI.

Craft.js fits the same pattern at 29.2 kB, with the editor interface as your project.

Plate and Editor.js fit the same way for document editing rather than page building.

Mistakes that cost a day each

Importing the editor at module scope in a server component. The error is a window is not defined during build, and it is the first thing everyone hits.

Putting the editor and the renderer in one module. Now the public page pulls the editor into its bundle. Split them; check with the bundle analyser rather than assuming.

Forgetting the container needs a real height. An editor in a parent with no height renders a zero-height canvas, and the report is always "nothing appears".

Re-initialising the editor on every render. Initialise once in a mount effect with an empty dependency array, destroy on unmount, and keep option objects out of the dependencies. In development React's StrictMode will mount twice, and without a proper teardown you get two editors stacked in one container.

Mirroring editor state into React state. Read from the editor instance; do not keep a parallel copy of the document in your store.

Publishing and preview

The pattern most teams land on: save draft data on autosave, publish by copying draft to published, and preview by rendering the draft through the same renderer the public route uses with a preview flag. Because the renderer is shared, preview cannot drift from production.

If you need publish-without-deploy for marketing pages specifically, that is what Builder.io and Plasmic sell, and our comparison covers whether that is worth a platform.

What comes after integration

Integration is around 40 hours in our build-versus-buy model. Asset uploads, autosave, versioning, permissions and a block library are the other 480, and none of them are Next.js-specific — they are the same on any stack, which is why the framework question is the easiest part of this project.