Puck review: the visual editor for React components

What Puck is, and who it is for

Puck is a visual editor that treats your React components as the unit of editing. You describe each component once — its editable fields, its defaults, how it renders — and Puck generates an editor around that description. Users drag components onto a canvas and fill in fields; you get back a JSON tree of component names and props.

This makes it the natural choice for a specific and increasingly common situation: a React product with a design system, where marketing or customer-success people need to assemble pages from approved components without a deploy. The alternative in that situation is usually a hosted platform, and Puck's proposition is that you can have the editing experience without moving your content to someone else's infrastructure.

It is the wrong choice when the editor has to leave React, when the output must be portable HTML, or when users expect to change typography and spacing freely. Those are the cases GrapesJS exists for, and the GrapesJS vs Puck comparison works through the boundary in detail.

Architecture: config in, JSON out

Puck's architecture is unusually easy to hold in your head, which is a large part of its appeal.

A config object maps component names to definitions. Each definition declares fields (what the editor shows), defaultProps (what a new instance starts with) and render (your actual React component). A data object holds the page: an array of component instances, each with a name and its props, plus a root section.

The editor renders the data through the config. The public page renders the same data through the same config using the Render component. There is no export step, no HTML serialisation, and no second implementation of your components for the editor's benefit — the reason so many GrapesJS-based products end up with drift between canvas and production.

Because the data is just typed JSON, it goes in your database next to everything else, versions with your normal tooling, and is queryable. The trade is that it means nothing outside your app: without the config, the data is a list of names.

Getting started

This is the file from our benchmark, which produced the measurements on this page and the screenshot below.

import { createRoot } from 'react-dom/client';
import { Puck } from '@measured/puck';
import '@measured/puck/puck.css';

const config = {
  components: {
    Heading: {
      fields: { text: { type: 'text' } },
      defaultProps: { text: 'Hello editor' },
      render: ({ text }) => <h1>{text}</h1>,
    },
  },
};

const data = { content: [{ type: 'Heading', props: { id: 'h1', text: 'Hello editor' } }], root: {} };

createRoot(document.getElementById('app')).render(
  <Puck config={config} data={data} onPublish={() => {}} />,
);

Compare that screenshot with the Craft.js one: both are React editors, and the difference in what you get for free is the entire argument between them.

In our benchmark this reached a rendered editor in a median of 852 ms, the second slowest of the six libraries we measured, because it boots React and an iframe preview before the editor exists. That is a one-time cost on an authenticated editor route, not something your visitors experience — see the time to first editor benchmark for the method.

Strengths

The config is the whole API. A React developer who has never seen Puck can add an editable component in minutes, and TypeScript catches field mistakes at compile time rather than at runtime. Very few editor libraries have a surface this small.

No canvas-to-production drift. The editor renders your real components. When you change a component, the editor changes with it, because there is no second copy.

Typed content. Renaming a prop is a compile error rather than a page that quietly loses a section. Storing HTML gives you no such guarantee, and this is the single most underrated advantage of the component-tree model.

Your data stays yours. Puck hands you JSON and steps back. No vendor storage, no CDN dependency, no per-seat pricing, no data-residency conversation.

Genuinely good documentation. The docs are task-shaped, with runnable examples for the paths teams actually take — App Router, custom fields, external data sources.

Limitations

React only, permanently. This is not a gap to be filled later; the canvas renders React. If any part of your roadmap involves offering the editor to customers on other stacks, Puck cannot go there.

No style manager. Users cannot change padding, colour or typography unless you build a field for it. For a design-system use case this is the feature. For a website builder you resell, it is a missing half of the product, and bolting a styling layer on top means designing that system yourself.

A young ecosystem. First published in June 2023. There is little third-party plugin supply, so unusual field types are yours to write. That is cheaper than it sounds because the contract is small, but it is a real difference against a decade-old catalogue.

Slowest-but-one to first paint. 852 ms in our benchmark against 94 ms for Craft.js. Acceptable for an editor route; worth knowing if you intend to embed the editing surface in a page users hit constantly.

Email is out of scope. No table-based output, no client testing. See the email template builder use case for what to use instead.

Pricing

Free, MIT licensed, no paid tier for the core editor and no usage ceiling. The costs are the ones you would incur anyway: building the components you want editable, and the persistence and permissions layer around the JSON. Our build-versus-buy calculator puts numbers on that against commercial SDK pricing — with Puck you can uncheck the UI line, which changes the arithmetic substantially.