I hated Gutenberg in 2018. Most devs did. In 2026 I quietly admit it won.
That sentence took me a long time to be able to write. I was deep in the classic editor world when the block editor landed, I had a stable of client sites running ACF flexible content like clockwork, and the new thing felt like a tax on everything that already worked. I was not subtle about it either. I had opinions, I shared them, and the people I worked with mostly agreed.
Eight years later the block editor is the thing I reach for first, and the classic editor is the exception I install for very specific clients. So this is the honest version of how I got from there to here, and what I think Gutenberg actually proved.
2018 to 2020: the chaotic years
The first stretch was rough. The editor was buggy in ways that affected real client work. Block rendering shifted between versions, custom blocks broke on minor updates, the React build pipeline forced on plugin authors was foreign to most WordPress devs, and the performance on long posts was bad enough to be a meeting topic. I remember a client with a five thousand word landing page that took most of a second to register a keystroke. That is the kind of thing that wins arguments.
On top of that, the editor felt like it was solving a problem most agency teams did not have. We already had a content workflow. ACF and a few well designed meta boxes did the job, our editors knew where everything lived, and the output was predictable. Gutenberg replaced a predictable system with one that moved every six weeks.
The fair criticism of that era is that the editor shipped before it was ready, and the WordPress core team asked the community to absorb the cost of finishing it. That cost was real. Sites broke, plugins got rewritten, and a lot of senior WordPress engineers spent two years pretending the whole thing was optional.
2021 to 2023: full site editing arrives, and the grumbling stays
Then full site editing landed and the scope doubled. Block themes were now the default story. The template editor showed up, theme.json appeared, and the entire idea of a PHP based theme started looking like the old way.
This is the period I started paying attention again, mostly because I had to. Clients were buying themes that were block themes by default, and saying no to that was getting harder. The tooling was still uneven, the documentation lagged the code, and the classic editor crowd was loud about not wanting any of it.
What changed for me in this stretch was theme.json. It was the first piece of Gutenberg where I sat down, read it properly, and thought yes, this is the right shape. A single declarative file describing colors, typography, spacing, and the editor surface those values exposed to writers. I had been building that exact thing by hand in every project for years, except mine was scattered across functions.php, a stylesheet, an ACF options page, and a README nobody read.
2024 to 2025: the editor grows up
The interactivity API matured in this window, and that was the second thing that flipped me. Before then, putting a real interactive element inside a post meant either a clunky shortcode that booted its own React island, or shipping a custom block with its own bundle, its own state, and its own way of fighting the editor. The interactivity API gave blocks a sanctioned way to be interactive without each one inventing its own world.
Design tokens started landing in theme.json properly. The block library settled. Patterns started being treated as first class. The performance work on the editor itself paid off, and the keystroke latency problem I used to complain about quietly disappeared.
By the end of 2025 I was writing block themes by default on new projects, and the few classic sites I still maintained started to feel like the legacy column on a tech radar.
2026: where we actually are
Blocks are the way. That is the short version. Patterns scale better than templates ever did, because a pattern is content shaped, not theme shaped, and an editor can drop it into any post without help from a developer. JS light themes are common now, where the front end ships almost nothing but the styles the blocks need and the interactivity API handles the rest. The classic editor still exists, and on legacy sites it still earns its place, but on a new build in 2026 it is rare.
Three patterns that paid off
If I had to defend Gutenberg with three concrete wins, these are the ones.
One, theme.json gave designers a real settings surface. Before theme.json, every agency had its own ad hoc system for letting designers control color palettes, spacing scales, and typography without touching CSS. Mine was always one ACF options page away from chaos. theme.json made it standard. A designer can hand me a JSON file, or open the site editor and tweak it themselves, and the editor surface updates to match. That is the first time WordPress has had a sanctioned design system layer, and it is genuinely good.
Two, block patterns let agencies ship starter content without fighting the editor. The old way of giving a client a head start was a demo import, which was a thousand WP All Import gotchas waiting to happen. Patterns flipped that. I can hand a client a pattern library inside the editor, they can drop in a hero, a feature grid, a testimonial section, edit the copy, and they are done. No imports, no orphaned media, no theme lock in, because patterns are just blocks.
Three, the interactivity API made micro-frontends inside posts actually decent. If I want a filterable product grid, an interactive map, or a live calculator embedded in a page, I can ship it as a block with sensible state, sensible events, and a sensible escape hatch into custom code when I need it. I do not have to bolt a separate framework onto the page just to get one interactive island working.
The honest take
WordPress's bet on blocks took seven years to fully pay off, and the cost was hard. A lot of agencies lost time, a lot of plugins lost relevance, and a lot of senior people in the ecosystem spent years upset. None of that is free. The core team asked a community of millions to swallow a generational change in the editing model, and the people who had to absorb that change were mostly not the ones who made the decision.
But it shipped, and the editor is now ahead of most CMSes' content editors. I work with a few other systems regularly, and when I open their editors after a day in Gutenberg I notice what is missing. The block model, theme.json, patterns, the interactivity API. That stack as a whole is better than the alternatives I see, and the gap is widening, not closing.
So here is the lesson I take from it. Bet on the long game. Gutenberg is what it looks like when you do.