SCF blocks vs React blocks: choosing a Gutenberg approach

When a project needs custom Gutenberg blocks, there are two common routes. You can build SCF blocks with Secure Custom Fields (or ACF) and render them in PHP, or you can build native blocks in React with @wordpress/scripts. Both are valid. The right choice depends on what the block does.

When SCF blocks are the better fit

SCF blocks use a normal block.json with an extra acf key that points to a PHP render template. Fields appear in the editor sidebar and the preview updates as you type.

"acf": {
	"blockVersion": 3,
	"mode": "preview",
	"renderTemplate": "render.php"
}

I reach for this approach when:

• The content is structured data: headings, links, images, repeaters
• The block queries posts or reads site settings, so it must render on the server anyway
• The team is stronger in PHP than in React
• I want to avoid a build step on a small project

When native React blocks earn their place

React blocks make sense when editors need to type directly on the canvas, when the block has rich interaction in the editor, or when it relies on core components like RichText and InnerBlocks to nest other blocks.

They cost more: a build pipeline, more JavaScript to maintain, and deprecations to handle when the saved markup changes.

A simple rule

If the block is mostly a form that produces markup, use SCF. If the block is mostly an editing experience, use React. Many projects end up with both, and that is fine as long as each block uses the simpler tool that does the job.

Keep field groups in version control

Whichever route you take with SCF, save field groups as local JSON in the theme. Your fields then travel with the code through Git, instead of living only in one database. And whichever way a block renders, escape every field on output: here is the short version of escaping in WordPress themes.