Gutenberg: why I see WordPress differently now

When Gutenberg arrived, I was sceptical. Actually, that is putting it politely: my first reaction was that WordPress had taken a turn for the worse.

I came from traditional WordPress development. Themes, plugins, PHP templates and custom solutions for specific requirements. I knew how to work with those. Suddenly, there was this new block system, with different concepts, different tools and an interface that initially slowed me down.

My first thought was roughly: why make something more complicated when it already works?

I see it differently now. The block theme system, in particular, changed my mind. For me, the real question is how to design a website, keep developing it and make it manageable in everyday use.

My scepticism had a reasonable starting point

The block editor became part of Core with WordPress 5.0 in December 2018. It was a major change to familiar ways of working. The original WordPress 5.0 release announcement makes the scale of that change clear.

Initially, I mostly saw the effort involved. Understanding new abstractions, questioning my workflow and working out how much control I would retain over design and output. When you already develop themes and plugins, another visual layer does not automatically feel helpful.

I wanted to build websites properly. Manageable markup, understandable styles and reliable components. I worried that WordPress was moving away from that and putting more interface between me and the result.

Looking back, I confused the early implementation with the longer-term concept. A rough introduction shaped my judgement of the entire direction.

Block themes made the bigger picture visible

The important difference, for me, is how far the block model reaches. Individual content blocks inside a post are only one part of it. With a block theme, templates and recurring areas of a website can also be described using blocks.

WordPress 5.9 introduced central Full Site Editing features in January 2022, alongside Twenty Twenty-Two, the first default block theme. Headers, footers, navigation and page templates became part of a shared editing environment. That was when the direction started to make sense to me. WordPress 5.9 “Josephine”

Full Site Editing covers several related features. The Site Editor is the interface where many of them come together. Gutenberg is the development project behind it; the plugin of the same name also tests features that are not yet part of a released WordPress version.

That distinction matters. An interesting Gutenberg announcement does not mean the feature is available on every current WordPress installation.

A theme can provide a clear design framework

Much of my change in perspective comes down to a fairly unassuming file: theme.json.

It can define colours, typography, spacing and global styles, among other things. Those settings inform both the design and the tools available in the editor. The Global Settings and Styles documentation explains this connection between the theme and its interface.

That fits my idea of good theme development: establish a consistent framework within which people can edit content sensibly.

An editor should be able to change a paragraph or replace an image without accidentally rebuilding the entire layout. At the same time, I want to apply new design decisions centrally wherever possible. If every section has its own special rules, maintenance becomes tedious very quickly.

Block themes provide a useful shared foundation for this. How well it works still depends on how carefully the theme is built and how much freedom the editor allows.

Patterns are particularly convincing

People maintaining a website rarely think in individual blocks. Usually, they are thinking about a complete section: a service, a team member, a notice or a contact area.

Patterns represent those combinations. WordPress 6.3 brought content, templates and patterns closer together in the Site Editor. Synced patterns and style revisions made the work easier to follow. WordPress 6.3 “Lionel”

Overrides for synced patterns, introduced in WordPress 6.6, made this especially interesting. Certain content can differ between instances while the shared design remains intact. At launch, this applied to supported content in headings, paragraphs, buttons and images. WordPress 6.6 “Dorsey”

A simple example: several service pages share the same contact section. Its heading and button label can match the subject of each page, while its structure and design stay consistent.

These are the kinds of requirements that make the approach useful to me. They come up constantly when building and maintaining websites.

The Block Bindings API, available since WordPress 6.5, fits into the same picture. Supported block attributes can connect to data sources, such as appropriately registered post metadata. That means a dynamic piece of text does not always require an entirely custom block. The limitations still depend on the supported attributes and data sources. Introducing the Block Bindings API

The Interactivity API makes development more interesting

Its official name is the Interactivity API. It has been part of Core since WordPress 6.5 and provides a shared approach to building interactive behaviour in the front end of blocks.

State, actions and their connection to markup follow a common model. Several blocks can work together: a state change in one place can trigger a response elsewhere. The API is intended for the front end; it does not replace the block editor APIs. Interactivity API in WordPress 6.5

The shared foundation is what appeals to me most. A filter, an expandable panel or a dynamic results list needs understandable state and clean transitions. I would like to maintain as little project-specific glue code as possible to achieve that.

Later changes show that the more difficult details are being addressed too:

• WordPress 6.9: Client-side navigation can load additional stylesheets and compatible script modules. This matters when the next view contains different interactive blocks. Module compatibility must be declared accordingly. Navigation improvements in 6.9
• WordPress 7.0: watch() can respond to changes in reactive values independently of a DOM element's lifecycle. The router's state.url is also initialised on the server. Interactivity API changes in 7.0

This does not automatically turn a WordPress site into a flawless web application. Loading states, errors, keyboard access and performance remain development work. But there is a clearer foundation on which to do that work.

Recent releases address concrete design problems

WordPress 7.1, released on 19 August 2026, brings further responsive settings to the Site Editor. These include adjustments for different screen sizes and custom mobile and tablet breakpoints for block themes through theme.json. There are also design options for states such as hover, focus and active. WordPress 7.1 “Mary Lou”

These details matter to me. An interface can look good in an initial design and still fall apart on smaller screens or when someone uses a keyboard. The more of these requirements the shared system can represent sensibly, the less each theme has to organise separately.

The WordPress 7.2 roadmap, published in September, continues this work. Plans include additional responsive styling options and a supported way to observe client-side navigation through the Interactivity API. These are development goals, not features already shipped. The roadmap also explicitly states that real-time collaborative editing is not planned for 7.2. Roadmap to WordPress 7.2

Distinguishing between available, experimental and planned features is part of taking a fair view of the development.

There is still work for developers

I now consider block themes a very good option. Even so, I would not rebuild a working project solely because it still uses a classic theme.

Changes also need clear rules. Templates modified in the Site Editor are stored in the database and can override the theme's template files. Anyone working across the editor and code needs to account for this in version control and deployment. The Theme Handbook on templates explains this behaviour.

Then there are the familiar tasks: sensible content models, suitable extensions, accessible components and an interface that other people enjoy using. A block theme does not make those decisions for you.

What has changed is my starting question. I used to focus on how to stay out of Gutenberg's way. Now, I first look at which parts of a requirement the existing block system can handle cleanly.

I changed my mind

WordPress still plays a different role for me than React or Next.js in a custom application. But for websites with plenty of editorial content, I find the development around block themes increasingly convincing.

The ecosystem has developed well in this respect. Design, reusable sections, dynamic content and interactive behaviour increasingly share common technical foundations.

I can still understand my original scepticism. I just do not want it to determine my judgement forever.

Gutenberg has matured. And I have become much more open to what we can build with it.

---

As of 29 September 2026. Technical details are based on the official release notes, dev notes and handbooks linked above. Statements about WordPress 7.2 refer to its roadmap.