Our position on Wordpress' Gutenberg

Gutenberg is a new content editor built for WordPress as of version 5.0 (released December 2018). In a few bullet points, here’s a general overview:

1. At its core, Gutenberg is a replacement for the standard content editor that has been a part of WordPress basically since its inception.
2. Instead of a “word processor” style experience, it attempts to create a drag-and-drop content building experience.
3. It relies on content blocks (but not necessarily in the way we’d like it to, as discussed later in this article).
4. Under the hood, it is fundamentally a JavaScript application that has been injected into the WordPress admin area.

Perhaps most important of all, it is a core update. Despite many pleas from the WordPress community to make Gutenberg an optional change, the development team elected to ignore this feedback and integrate it directly into the core. They did provide a plugin called Classic Editor, which reverts to the standard WYSIWYG editor that we are all familiar with. The current plugin page indicates support for this plugin through at least 2022:

The Implications of Gutenberg

Despite the availability of the Classic Editor plugin, the very presence of the Gutenberg content builder in the core of WordPress’s codebase raises fundamental questions about the platform’s underlying philosophy—much of which runs counter to some of the core concepts of Craft&Crew's development practice, which aim to:

1. Enforce separation between content and its layout, wherever possible.
2. Organize content into smaller, purposefully designed chunks.
3. Minimize unnecessary (or duplicate) development effort.

What follows is an overview of our thoughts on Gutenberg, as it relates to these core concepts.

The Marriage of Content and Layout

As a block-based content builder, much of the formatting that Gutenberg undertakes involves adding HTML directly to the content. This includes basic formatting tags like italics or links, but also extends to more complex elements such as image wrappers and structural blocks with custom classes.

Ultimately, this stands in stark opposition to our ideal philosophy of creating content that exists independently of any presentational considerations. Because Gutenberg processes user input in such a way as to include this structural HTML directly in the content, it forces an inherent relationship with the presentational layer.

The unfortunate result is content that is non-portable, meaning that it will be difficult to change CMS in the future, or potentially even to update the front-end. This marriage of content to layout also limits its usefulness to a single form of display, rather than providing the potential for use across the site, or even across other, additional properties such as external applications.

Beware the Blob

There is a term in the development world for large chunks of raw HTML content. We call it the Blob.

And like the creature from 1950's horror film, it should be avoided lest it become all-consuming.

Dramatic? Guilty as charged. But, building on the previous point, an analysis of the database of a Gutenberg-powered test site revealed that the structural formatting of the content is stored directly in the database in the form of a single, large “blob”. This only further emphasizes the unfortunate marriage between content and layout.

If the content was stored in separate chunks and only assembled programmatically when requested within templates, it would be possible to prevent or otherwise alter this assembly—or else to access chunks of content in other contexts. As it stands, breaking the content apart would require complex processing that would be prone to breaking.

Many current content and IA best-practices advise against using blob-style content at all (again, in favour of smaller, more portable chunks). Unfortunately, Gutenberg's reliance on the blob seems built directly into its core philosophy.

There’s an App for That

The core of Gutenberg’s interface is actually a custom JavaScript application that has been injected into the WordPress admin. At first glance, this may not seem like a significant issue. The primary challenge here is found in the limitations of the core set of blocks.

This will invariably prove limiting, and new, custom blocks will almost certainly be required for virtually any build, resulting in a need for custom development. In the Gutenberg context, custom development means leveraging WordPress’ new JavaScript-powered API, or relying on a plugin for (often partial) support.

Moreover, it also requires creating custom CSS to control the appearance of the blocks within the Gutenberg editor itself—or else provide un-styled content blocks. Neither option is ideal:

1. Writing custom styles simply for the backend involves doubling effort (translated to additional time and money) to style both the admin interface and the frontend interface, but,
2. Failing to include these styles will likely lead to a “broken” or “unpolished” experience for content authors.

A Question of Philosophy and Enterprise

Fundamentally, what we’re left with is a question of philosophy—specifically around the needs of the enterprise-level websites that Craft&Crew is in the business of providing to our clients. This could include marketing sites or complex organizational sites. What Gutenberg seems to make clear is that WordPress is not interested in being an enterprise-level CMS.

Instead, the team driving the core of WordPress’ development seem to be more interested in making it a tool that will compete with block-based site building tools that are available on the market. There is a certain inherent logic in this position. Of the millions and millions of sites powered by WordPress, it is likely safe to assume that the majority fall into the categories of personal websites, blogs and/or the small business sites that are targeted by SquareSpace or Wix.

A tool like Gutenberg could certainly be embraced by this particular demographic, who are likely to have less of an interest in portable, chunked data, and more of an interest in simple DIY website solutions. As such, it seems as though WordPress is prepared to sacrifice the developmental flexibility of their system in order to cater to the (perceived?) desires of bloggers and small business—at the detriment of enterprise level sites.

In our view, it marks a clear philosophical shift—a shift which leaves us questioning the suitability of WordPress as a web platform for our clients.

There is a way forward (for now).

Despite all of the above, this article is not meant to imply that Craft&Crew is abandoning WordPress. We've done some great work with the platform, and will continue to support it for our clients.

Instead, this article is meant to highlight that the platform’s current philosophy and development path appear to stand in opposition to our own core development concepts and (more importantly) the best interests of our clients.

As of the time of writing (July 2019), WordPress does continue to support the Classic Editor plugin, so that remains a viable option for helping to maintain the experience of all current builds.

Additionally, Gutenberg seems to be tied directly to the editor functionality within WordPress. If this functionality is disabled for a particular post type, the WordPress editing interface reverts to the traditional format. By using filters to remove the editor functionality (or by not registering it at all for custom post types), we can implement our own modular systems to provide field-driven interfaces that will allow us to build chunked and portable metadata.

However, given the apparent philosophical direction of WordPress development, we have no guarantee that the above approach will continue to remain viable moving forward.

It will also be interesting to watch the state of WordPress, and whether or not the community’s continued reaction to Gutenberg has any effect on the developmental philosophy.