The ACF vs Gutenberg blocks debate has divided the WordPress community for years. Some argue Gutenberg is the future and ACF is legacy. Others stick with ACF and consider Gutenberg immature for serious production work. The truth, as usual, is somewhere in the middle — and it depends on the project context.
In this article I share my technical position, based on real projects from recent years. On the overwhelming majority of my projects, I still use ACF. But not out of nostalgia — for concrete reasons I’ll explain below.
The ACF vs Gutenberg debate, without ideology
Let me put this debate in practical terms. ACF (Advanced Custom Fields) is a plugin that lets you create custom fields for CPTs, pages, and taxonomies, with a carefully designed UX for editors. Gutenberg is the native WordPress editor, which uses a block-based system and includes FSE (Full Site Editing).
They’re not exactly the same thing. ACF is primarily for structuring content (repeatable fields, relationships, galleries, specific data). Gutenberg is primarily for composing visual layout. They overlap in the management of dynamic content on pages with flexible layouts.
When ACF wins (and why I still use it on most projects)
1. Structured and repeatable content
For CPTs with well-defined data (projects, products, team members, events), ACF is incomparably superior. Fields are explicit, validated, and the UX for editors is clear. In Gutenberg, this would have to be implemented as custom blocks, which is unnecessary work for structured data.
2. Relationships between content
Relationship and Post Object fields in ACF allow you to easily build complex relationships between content types (a project belongs to a client, has multiple team members, is related to other projects). In Gutenberg, this logic is much harder to model cleanly.
3. UX for non-technical clients
This is the decisive argument. A client who opens the backend to change the price of a service, number of employees, or the date of an event, wants a single clear field. They don’t want to navigate through blocks — they want to click on a “Price” field and type the value.
Gutenberg, as much as it has improved, still offers a confusing experience for non-technical users on structured content. ACF is, by comparison, brutally simpler.
4. Performance and control
With ACF, the developer writes whatever HTML they want in the template, with full control over structure and performance. With Gutenberg, HTML is generated by the block system, and fine control is harder to achieve.
5. Maturity and ecosystem
ACF has existed for over a decade, has a mature ecosystem, solid documentation, and a sustainable business model (now owned by WP Engine). Gutenberg blocks continue to have breaking changes between versions, scattered documentation, and the third-party block ecosystem is inconsistent.
When Gutenberg makes sense
I’m not dogmatic. There are scenarios where Gutenberg is the right choice.
Editorial content pages with variable layouts
Long-form blog articles, experimental landing pages, campaign pages, where the editor needs to visually compose a sequence of different sections in each piece. For this, the Gutenberg editor with a well-curated set of custom blocks is excellent.
Small projects with an autonomous client
If the client will manage the site alone, has some digital literacy, and needs flexibility to create new pages without a developer, Gutenberg with an FSE-ready theme can make sense.
Reusable blocks across multiple contexts
If the same content unit (testimonial, CTA, feature card) needs to appear in dozens of different places across the site, a reusable Gutenberg block is more elegant than repeating ACF fields on multiple pages.
The hybrid scenario I use on most projects
In practice, my projects are rarely 100% ACF or 100% Gutenberg. The architecture I use is:
- CPTs with structured data: ACF (projects, products, team, events)
- Fixed institutional pages (homepage, about, contact): ACF Flexible Content or a rigid template with ACF
- Blog posts: Gutenberg, with a limited set of custom blocks (pullquote, citation, captioned image, CTA)
- Landing pages: Gutenberg with specific custom blocks
This approach gives the client the right UX for each type of content: clear fields for structured data, visual flexibility for editorial content.
What Automattic doesn’t tell you
The official narrative is that Gutenberg and FSE are the inevitable future of WordPress. That’s partly true. But there are realities not in the narrative:
- Gutenberg has frequent breaking changes, which increases long-term maintenance cost
- FSE (Full Site Editing) still has serious limitations for corporate sites with complex requirements
- Many experienced developers continue using ACF because real productivity is higher
- The learning curve to create custom Gutenberg blocks is significantly steeper than creating ACF field groups
- Compatibility with older themes and migrations is more complex with Gutenberg
What about ACF Blocks?
A middle solution I use increasingly is ACF Blocks. It lets you create Gutenberg blocks using ACF’s syntax and UX. You get Gutenberg’s composition flexibility with ACF’s implementation simplicity.
It’s not perfect — performance may be slightly lower than native React blocks, and there are limitations in some advanced use cases. But for most scenarios where I need a custom block, it’s the most productive option.
Conclusion: it’s not Gutenberg vs ACF, it’s project context
The right question isn’t “which is better”. It’s “what does this specific project need, and who will manage the content”. The answer varies from project to project.
If you’re considering rebuilding your site and aren’t sure which approach to choose, let’s talk. I can help you map the requirements and propose the most suitable architecture for your case.
