Puck vs React Page: a modern config API or a built-in layout grid

Two generations of the same idea

React Page was published in November 2019, Puck in June 2023, and the four years between them are visible in every dimension: bundle size, API ergonomics, documentation and dependency freshness.

That does not settle it, because React Page has two capabilities Puck does not, and both are expensive to build.

Where React Page wins

A resizable layout grid. Rows, cells and drag-to-resize. Users can place things side by side and change the split. In Puck, layout is whatever your components implement, and building an equivalent grid is a real project.

Multilingual content. Per-language values with the editor aware of the current language. Puck leaves internationalisation entirely to your application, and retro-fitting it into stored page data is unpleasant.

A more finished interface out of the box — which is also why it is four times the size.

Where Puck wins

A quarter of the bundle. 90.4 kB against 377.2 kB in our measurements, and 852 ms against 1,004 ms to a rendered editor.

A modern, typed API. The config object is small and the types are good; React Page's type ergonomics are noticeably older and its error messages less specific.

No bundler workarounds. React Page needs a react/jsx-runtime.js alias to build against React 19. It is one line, but it is a signal about dependency maintenance.

Better documentation and momentum. Puck's docs track the current version; parts of React Page's lag its major version.

Cleaner data. Puck's stored JSON maps directly to your config; React Page's tree carries grid structure that only React Page understands.

The decision rule

Do you need resizable multi-column layout controlled by the user?

If yes, React Page is worth its weight, because building that on Puck means implementing drag-resize, drop targets and a grid model — comfortably 100 hours and a maintenance commitment.

If no — and for most product-embedded editors the answer is no, because free layout control is exactly what you are trying to prevent — Puck is the better library on every other axis.

The multilingual case is narrower but sharper: if you need per-language content inside the editor rather than in your data layer, React Page has it and Puck does not.

Migration

Both store a JSON tree, but the shapes differ substantially: React Page's carries rows and cells, Puck's carries a flat content array. A transformer is realistic if your React Page content uses a simple single-column structure, and unrealistic once users have resized grids, because Puck has nowhere to put that information.

Component code migrates more easily: a React Page cell plugin's renderer is usually usable as a Puck component's render function with modest changes.

Verdict

Choose Puck unless you can point at the grid or the multilingual requirement. Those are the only two reasons that survive contact with the measurements, and both are legitimate.

If neither library is right because the editor must leave React, the comparison you actually want is GrapesJS vs Puck.

Decision checklist

1. Do users need to resize columns? This is the one capability that justifies React Page's weight.
2. Is per-language content an editor concern or a data-layer concern for us? React Page assumes the first.
3. Are we comfortable with a Material UI editor appearance? It is not replaceable without substantial work.
4. Does our build tolerate a bundler alias? React Page needs one for React 19, and it signals the age of the dependency tree.
5. What is our JavaScript budget on the editor route? 377.2 kB against 90.4 kB is a fourfold difference on the largest asset either library contributes.

The number that matters

13.5× — the spread between the lightest and heaviest libraries in our bundle benchmark, and React Page sits near the top of it while Puck sits in the lighter half. If neither the grid nor the multilingual handling is a requirement, the weight buys you nothing at all.