Puck vs. Gutenberg
Concepts for WordPress Developers covers Puck at the same level of detail as everything else in that comparison: one row in a table. This page goes deeper on just that one comparison, since Gutenberg is the part of WordPress closest in spirit to Puck: both are React-based, block/component-oriented visual editors, which makes the differences more instructive than the similarities.
Grounded against wordpress.org/gutenberg (the live interactive demo) plus what’s already confirmed elsewhere in this documentation about Puck, not guessed at from memory of either tool.
Both are genuinely block/component editors: that’s the real similarity
This is worth stating plainly before the differences: Gutenberg and Puck are the same category of tool, unlike the rest of the WordPress-to-P1 comparison. Both render a canvas of discrete, typed units (blocks/components) that a non-technical editor arranges visually, each with its own settings panel, each ultimately backed by a JS object describing its shape. If you’ve built a custom Gutenberg block before, building a Puck component (see Components: Puck’s answer to blocks) will feel structurally familiar in a way that, say, building a Drupal Paragraph type never would.
Where they diverge
| Gutenberg | Puck | |
|---|---|---|
| Block/component definition | block.json manifest + JS edit/save (or PHP dynamic render callback) | One plain JS/TS object: label, fields, defaultProps, render |
| Registration | register_block_type(), discovered via the manifest | Importing the object into puck.config.tsx’s components map (the import is the registration) |
| Rendering runtime | Can be PHP (dynamic blocks) or pre-saved HTML (static blocks) | Always React, always rendered live: no “save HTML to the database” step |
| Reusable content | Patterns (block arrangements, insertable/editable copies) and Synced Patterns (formerly “reusable blocks”; one instance, edit anywhere it’s used, updates everywhere) | Nothing native; see Content Relationships for the closest buildable equivalent, which is meaningfully less capable than a synced pattern |
| Site-wide chrome | Full Site Editing (FSE): theme.json, template parts, a native header/footer/navigation editing experience | None; see Managing the Header & Footer |
| Content type / template model | Custom Post Types + block templates (register_block_template) | Templates: metadata scriptable, layout editor-only, no code-first equivalent to a block template |
| Collaborative editing | Not native to core Gutenberg: real-time multi-user editing isn’t part of the base editor | CRDT-based real-time collaboration is native; see Publishing |
| Permissions on canvas | Block locking (move/remove/edit restrictions per block instance, set by whoever placed it) | Permissions & Roles’ ContentRole system, plus pinned-component locking from the Template itself |
| Extension ecosystem | A mature plugin/block directory: thousands of third-party blocks | None; see Concepts for WordPress Developers → Things WordPress gives you for free |
| Media picking | WordPress’s Media Library, native to the editor, one integrated system | Media Library, real, but confirmed to need the right field type/component; see the note on this project’s own Image vs. Media Figure trap |
The two biggest surprises, in either direction
Puck is ahead: real-time collaborative editing. Multiple editors working the same document simultaneously, CRDT-synced, is not something Gutenberg does natively: WordPress has no equivalent to Google-Docs-style co-editing built into core. This is a genuine Puck advantage worth knowing about if you’re used to assuming WordPress’s editor is more mature across the board; on this specific axis, it isn’t.
Gutenberg is ahead: reusable content and site-wide editing. Synced Patterns (one block instance, edit once, updates everywhere it’s placed) and Full Site Editing (native header/footer/template-part editing) are both real, shipped WordPress core features with no P1 equivalent; see Content Relationships and Managing the Header & Footer for what building the closest approximation of each would actually take on P1. If your team is coming from a Gutenberg-heavy build process, these two gaps are the ones most likely to surprise you first.
Habits to unlearn, Gutenberg-specifically
- No
block.json. A Puck component’s “manifest” is just the object itself: there’s no separate metadata file to keep in sync with the render logic. - No Patterns or Synced Patterns. Every instance of a Puck component is independent; there’s no “insert this pre-built arrangement” library, and no “edit once, updates everywhere” mechanism. See Content Relationships for the closest buildable workaround.
- No Full Site Editing. There’s no
theme.json, no template-part editing UI, no native concept of site-wide chrome at all; see Managing the Header & Footer. - No block variations or block styles. Gutenberg lets one block definition offer
multiple visual “styles” an editor picks from. A Puck component that needs this
today is either multiple separate components, or a
selectfield the component’s ownrenderbranches on; there’s no first-class “style variant” concept in the field-type system itself.