Editor.js vs Puck: writing documents or composing pages

Two different verbs

Editor.js is for writing. The user types, and structure emerges from what they type — a heading, a list, an image with a caption. The output is a document.

Puck is for arranging. The user picks components you built and places them, filling in the props you exposed. The output is a page.

A help centre article is the first. A pricing page is the second. Most products eventually need both, and the honest architecture is two editors rather than one stretched.

Where Editor.js wins

Writing feels like writing. A contenteditable surface where text flows. In Puck, text is a prop in a form field, and writers notice immediately.

Framework-agnostic. Mounts anywhere; Puck requires React.

Content portable across surfaces. Typed JSON blocks render on the web, in an app or in an email from one stored representation. Puck's data means something only inside your React app.

Cheaper to integrate: five lines against sixteen, and 70 ms against 852 ms to a rendered editor.

Users cannot break the layout, because there is none.

Where Puck wins

Layout and composition. Users arrange sections, choose variants and fill in props. Editor.js has no concept of any of this.

Your components render in the canvas. What the editor shows is what production renders, and interactive components — pricing tables, booking widgets, product carousels — work in both.

Typed content against your config. Renaming a prop is a compile error rather than a silently broken page.

Structure you control. You decide what can exist on a page; Editor.js's structure is whatever tools you installed, in whatever order the user typed them.

Using both

The common architecture is Editor.js (or Plate) for the article body, and Puck for the page around it — with a "rich text" Puck component whose prop is a block document.

That composition works well and is much less exotic than it sounds. The alternative — a single library serving both — produces either a page builder people write badly in, or a text editor people lay out badly with.

Migration

Editor.js to Puck: each block type becomes a component with props. Mechanical for standard blocks, and it loses the flowing-text editing experience.

Puck to Editor.js: only sensible for content that was already a stack of text and images. Anything with layout has nowhere to go.

Verdict

Ask what the user is doing when they open the editor. If they are going to type a lot, Editor.js. If they are going to arrange things, Puck. If both, build both — and use the boundary between them as a product decision rather than a technical compromise.

If the arranging has to happen outside React, GrapesJS vs Editor.js is the comparison that applies instead.

Decision checklist

1. What is the user doing in the first thirty seconds — typing or dragging? That answers it.
2. Do we need both an article editor and a page builder? Many products do, and building both is more honest than stretching one.
3. Is our stack React? Puck requires it; Editor.js does not care.
4. Should users be able to change layout? Editor.js says no by construction.
5. Where does the content render? Editor.js blocks need a renderer per surface; Puck data renders through your React components only.

The number that matters

One renderer per output surface — the recurring cost of Editor.js's JSON model that nobody mentions when comparing installation snippets. If your content appears on a website, in an app and in an email, that is three renderers to write and keep in step with your tool versions.