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

*Source: https://www.editorstack.cc/compare/puck-vs-react-page — last updated 2026-09-17. Licensed CC BY 4.0 with attribution to EditorStack.*

## Summary

- Puck measured 90.4 kB gzip against React Page's 377.2 kB — one of the largest gaps between two directly comparable libraries in this dataset.
- React Page includes a resizable row-and-cell grid and per-language content handling, neither of which Puck has, and both of which are substantial to build.
- React Page also needs a bundler alias to build against React 19, because its react-dnd dependency imports a path React 19 no longer exports.

## At a glance

| Product | Type | Licence | Frameworks | Bundle (min+gzip) | Price from | Self-hosted | White label | Score |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [Puck](https://www.editorstack.cc/libraries/puck) | library | MIT | React | 90.4 kB gzip | Free (open source) | Yes | Yes | 8 |
| [React Page](https://www.editorstack.cc/libraries/react-page) | library | MIT | React | 377.2 kB gzip | Free (open source) | Yes | Yes | 6.4 |

## 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](/research/bundle-size-benchmark-2026), 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](/compare/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](/research/bundle-size-benchmark-2026), 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.


## Frequently asked questions

### Should I choose React Page over Puck?

Only for the two features Puck lacks: a resizable layout grid, and built-in multilingual content. If you need neither, Puck is lighter, faster and has a better developer experience.

### Why is React Page so much larger?

It bundles a Material UI-based editor interface. We measured 377.2 kB gzip against Puck's 90.4 kB with React external in both cases.

### Does React Page work with React 19?

It runs, but bundling requires aliasing react/jsx-runtime.js because of its react-dnd dependency. We recorded that workaround in our benchmark rather than omitting the library.