Gutenberg in 2026: Has It Finally Caught Up to Elementor?

Yes, mostly. After eight years of public scepticism and three years of agency teams quietly shipping block-theme sites, Gutenberg in 2026 is a credible default for production WordPress work. For roughly eighty percent of marketing sites, content-driven publishers, and headless front ends, a custom block theme now produces cleaner output, lighter pages, and a faster editor experience than Elementor or Bricks. The gap that existed in 2022 has closed for layout, typography, global styles, and pattern reuse.

The remaining twenty percent is where this honest comparison earns its keep. Two specific problems still push us back to a builder or to ACF Blocks: dynamic data binding beyond a narrow set of core sources, and per-item variation inside the Query Loop block. Both have workarounds. Neither has a clean editor UI yet. If your project lives inside those gaps, a builder is still the right tool. If it does not, Gutenberg wins on every axis that matters for long-term agency maintenance.

What Gutenberg actually ships in 2026

A short ledger of the last four point releases is more useful than another retrospective. WordPress 6.4 brought the Twenty Twenty-Four block theme, lightbox on images, and font-family controls on individual blocks. WordPress 6.5 introduced the Font Library, the Block Bindings API, custom field revisions, and the Interactivity API for client-side state without jQuery. WordPress 6.6 added grid layout, section styles via block style variations, and a unified publish flow that treats template edits and post edits as one transaction. WordPress 6.7 turned on Zoom Out by default, shipped Twenty Twenty-Five, and added editor UI for previewing block bindings.

The cumulative effect is a Site Editor that no longer feels like a beta. theme.json is now the single source of truth for spacing scales, fluid typography, color tokens, content and wide widths, and per-block CSS. Block patterns have replaced the awkward reusable blocks of the early days, and synced patterns give you the equivalent of an Elementor Global Widget without the database dependency. Block Hooks let a plugin or theme inject blocks adjacent to anchor blocks without editing templates by hand, which solves the old problem of how to add a newsletter prompt under every post without a thousand template part edits.

For an agency, the practical read is that theme.json plus a patterns folder plus three or four custom blocks is now enough to deliver most marketing site briefs. The build is git-trackable, the output is plain HTML comments around plain markup, and the client can edit copy without breaking layout. That last sentence used to be the entire pitch for Elementor.

Where Gutenberg now beats a builder

Output weight is the easiest win to demonstrate. A stock Twenty Twenty-Five home page transfers about eighty kilobytes total. A stock Hello Elementor home with the Elementor Pro starter kit transfers around six hundred. The block theme ships no jQuery, no builder runtime, and one compiled stylesheet derived from theme.json. Core Web Vitals come in green without WP Rocket, without Perfmatters, and without the asset-cleanup plugins that have become mandatory companions to Elementor builds.

Design-system fidelity is the second win. theme.json gives you tokens that propagate through every block, every pattern, and every template. Change the brand primary in one place and the buttons, links, focus rings, and pattern accents follow. Elementor's Global Styles tries to do this on top of CSS classes, but it cannot reach into third-party widgets, and the cascade behavior surprises clients regularly. With theme.json you get the cascade for free because it is just CSS variables compiled at the right scope.

Headless and multilingual workflows also tilt toward Gutenberg. WPGraphQL plus a block parser gives you a clean component map for a Next.js or Astro front end. Polylang and WPML now treat patterns and template parts as first-class translation units. Exporting an Elementor site to a headless front end remains a porting project; exporting a block theme is a mapping exercise.

The dev workflow is the least-discussed win. Block themes are folders. theme.json is one file. Patterns are PHP files in /patterns. Templates are HTML files in /templates. You can review a pull request and understand what changed. Elementor templates live as serialized JSON inside the database, which makes code review impossible and makes environment promotion a database migration every time.

Gap one: dynamic data without ACF

The Block Bindings API shipped in WordPress 6.5 and was the headline feature for anyone who had been hand-rolling shortcodes for custom field output. It binds a block attribute to a data source. Out of the box you get core/post-meta, core/pattern-overrides, core/post-title, core/post-excerpt, and core/post-author-name. The bindable attributes are restricted to paragraph content, image url and alt and title, button url and text, and heading content.

That sentence describes the gap. If you want to bind a Cover block's background image to a custom field, you cannot. If you want to bind a Group block's background, you cannot. If your client has a flexible content field with five layout options per row, you cannot express that in a binding. ACF with ACF Blocks remains the path of least resistance for any project where the editing model is repeater-driven or where the design needs custom-field-driven backgrounds, gradients, or layout switches.

You can register your own source with register_block_bindings_source. The shape is straightforward:

register_block_bindings_source( 'witscode/case-study', [
  'label' => 'Case Study Field',
  'get_value_callback' => function( $args, $block ) {
    return get_post_meta( $block->context['postId'], $args['key'], true );
  },
  'uses_context' => [ 'postId' ],
]);

The block markup that consumes it looks like this:

<!-- wp:paragraph {"metadata":{"bindings":{"content":{"source":"witscode/case-study","args":{"key":"client_outcome"}}}}} -->
<p></p>
<!-- /wp:paragraph -->

This works. We use it. But there is no editor UI for selecting a custom source on a non-core attribute, which means an editor cannot wire up a binding without a developer writing a small React panel for the block inspector. For a content team that needs to drop a new field reference into a template, that is a friction point a builder does not have. ACF's "Edit Field Group" UI plus its block bindings layer give the editor a dropdown. Core does not, yet.

The honest framing for a 2026 build: if your editing model is one custom post type with five flat fields, native bindings work and you can skip ACF. If your editing model has repeaters, flexible content, options pages, or background-image fields on container blocks, install ACF or accept that you are writing custom block bindings sources and inspector controls.

Gap two: query loop variation and filtering

The Query Loop block renders a post template. The post template applies to every item in the loop. There is no native way to say "the first item should be a large featured layout, the next four should be a grid, and the sixth onward should be a compact list." This is the bread and butter of any blog index, case study archive, or resource library, and it is the single most common thing we still build outside core.

The workarounds exist. You can register a block variation that supplies a custom render callback. You can stack two Query Loops with offset and per_page set so the first pulls one post and the second pulls the rest. You can filter render_block to inject a class on the first iteration and style with CSS. Each works. Each adds maintenance overhead and none of them appear in the editor as a "first item layout" toggle.

add_filter( 'render_block_core/post-template', function( $block_content, $block ) {
  static $index = 0;
  $index++;
  if ( $index === 1 ) {
    $block_content = str_replace( 'wp-block-post', 'wp-block-post is-featured', $block_content );
  }
  return $block_content;
}, 10, 2 );

Filtering and faceting are the second half of this gap. There is no native filter UI, no native sort dropdown, no native load-more. The Interactivity API gives you the primitives to build all three, and that is genuinely useful, but it is a build job. FacetWP and Search and Filter Pro remain the practical answer for any catalog page that needs filters across taxonomies. Elementor Pro's Loop Grid plus its filter widgets still ship something usable in twenty minutes that would take a day in core.

Pagination styling improved in 6.7 and the Query Loop now respects more block-level styles, but the per-item-variation problem is structural, not cosmetic. Until core ships a "template variation by index or condition" UI, this gap stays.

The honest scorecard

Layout primitives reached parity in 2024. Group, Row, Stack, Grid, and Cover give you everything Elementor's Section, Column, and Container give you, with cleaner markup. Typography and spacing tokens favor Gutenberg because theme.json compiles once and applies everywhere; Elementor's Global Styles is a UI layer over CSS classes and the cascade is less predictable. Responsive controls still favor Elementor for fine-grained per-breakpoint padding and margin; Gutenberg only fluid-scales top and bottom spacing without a plugin like GenerateBlocks or Greenshift.

Animations and motion favor Elementor in the editor. The Interactivity API can do more, but it requires code. Forms are a wash because both ecosystems require a plugin for anything serious. Display conditions and popups favor Elementor Pro decisively; core has no native display-conditions UI and no popup builder. Templating and dynamic data favor ACF or Meta Box on either side, with the gap-one caveats above.

For agency editor experience after a half-day of training, Gutenberg's Command Palette, distraction-free mode, and Style Book make day-to-day content edits faster than Elementor's right-rail panel. For unsupervised client editing of pixel-precise marketing pages, Elementor still wins because the controls are more forgiving and the visual feedback is more immediate.

When we still reach for a builder

Three project shapes still get a builder recommendation from us. Heavy popup and conditional-display work, where the client wants twenty entry-popups with UTM-based targeting and exit intent, is faster in Elementor Pro than in core plus a popup plugin plus custom code. Catalog pages with deep filtering across multiple taxonomies, custom fields, and price ranges are faster in Elementor Pro Loop Grid plus FacetWP than in custom Query Loops. Sites where the brief explicitly requires a non-developer to redesign pages from scratch monthly are still better served by a builder, because Gutenberg's editor assumes a designer set the patterns and the editor stays inside them.

Everything else, in 2026, is a block theme.

How WitsCode builds block-theme sites now

Our default stack for a new WordPress build in 2026 is a custom block theme rooted in a project-specific theme.json, ten to twenty hand-authored patterns covering hero, feature, testimonial, pricing, CTA, and footer variants, two or three custom blocks for things core does not handle (typically a logo wall, an animated stat block, and a filtered post grid built on the Interactivity API), and ACF only when the editing model genuinely needs repeaters or flexible content. We commit theme.json, patterns, and templates to git. We promote between environments with code, not database exports.

The cost picture is the part clients care about. A block-theme build trades roughly thirty percent more design-system setup time for zero builder license fees, faster page loads without optimization plugins, and a maintenance profile that does not include "wait for the builder to be compatible with the next WordPress release." Over a three-year site lifecycle the math is not close.

If your current site is on Elementor, Bricks, or Divi and you are feeling the weight, a custom block theme is the upgrade path that most of the industry is now quietly taking. If you want a team that has shipped this stack for the last three years and will not pretend the two gaps above do not exist, that is the work we do at WitsCode.