This Changes Everything: Gutenberg is Good Now
At WordCamp US, it became clear that the Gutenberg editor is a tangible improvement to WordPress—and, more importantly, is really going to happen.
We’ve just returned from this year’s WordCamp US. In addition to the wonderful opportunity to catch up with the community, we also got to be there for one piece of colossal news: Gutenberg is actually good now.
In two tech demos (by Morten Rand-Hendriksen, and then by Matt Mullenweg at the State of the Word), Gutenberg live-demoed as a feature-rich content editor that has made astonishing progress since I last looked closely at it several months ago.
At that time, along with much of the community, I was very skeptical about what Gutenberg was going to be, and whether it would be a meaningful improvement over doing nothing. At WordCamp US, it became very clear that Gutenberg is a Real Thing that is a tangible improvement to WordPress—and, more importantly, is really going to happen.
This article takes a look at what Gutenberg is, what it aims to be, and its vast implications for WordPress as a software ecosystem.
How Gutenberg is Right Now
As of early December 2017, Gutenberg is okay.
As of early December 2017, Gutenberg is okay. It’s probably better overall than the current TinyMCE editor, but it’s also got numerous rough edges and missing features that will need to be smoothed out before launch—which, according to Matt, is currently targeted for April 2018.
No Columns, Yet
Gutenberg may eventually be many things, but right now it competes most directly with WordPress’s plugin- and theme-based layout builders. To me, the simplest definition of “layout builder” is: Columns. The default layout for any document—the one you don’t need a builder for—is “everything stacks vertically.” A layout builder earns its name by providing columns, which allow you to build layouts other than the default.
Gutenberg doesn’t have columns yet, but it will soon. As of early December 2017, it debuted a “Text Columns” block, partly to verify that columns in general will work. Soon—once nested columns are implemented—true Gutenberg layouts will be a possibility.
Because I’m so interested in this topic, I had a chance to talk to Matías Ventura, who demoed Gutenberg at the State of the Word. He explained how Gutenberg column layouts will work: they’ll use the CSS Grid layout paradigm to avoid the nested markup that other CSS grid systems (like the Bootstrap Grid) require. Really cool.
The actual authoring—text editing—experience is awkward at present. Here are just a few ways I’ve experienced that in using Gutenberg to write this article:
- Creating header elements–<h2>s, <h3>s, and so on—takes forever. It’s a select within a dropdown, all mouse-based. I found myself dreading it.
- Relatedly, you can highlight a “header” text block, paste it elsewhere, and the text pastes in as regular text, not header text. So creating a new <h2> or <h3> never gets easier: it’s always the same three or four clicks.
- Also relatedly: “Duplicate Block” should be a thing. Let’s say I’ve got an <h2> block called “What I Love About Home Alone 2” and I also want a second <h2> block called “What I Dislike About Home Alone 2“: if I could duplicate the first block and change “Love” to “Dislike,” creating the second block would take about a second. At present, it takes maybe five times that long.
- Okay, last one on headings: <h2>s and <h3>s are so similarly sized that they’re hard to tell apart at a glance.
- As you write, if you move your mouse, Gutenberg’s options come up. These options for the current paragraph often partially obscure the content of the previous paragraph.
- Italicized and bolded passages of text stay awkwardly and distractingly highlighted in blue for some reason.
- A certain kind of Ctrl+Z undo can destroy an ordered list, rendering its list items into paragraphs.
- You can’t reorder text blocks by clicking and dragging them where you want. The mouse-based solution for this is a very primitive clickable “Up Arrow/Down Arrow” position switcher.
- Things seem to take more clicks than they used to. Where “Update” used to be an inviting single-click save, it’s now an annoying two-step flow. Clicking “Update” drops down a menu that asks you “All ready to go?” Which is like a taxi driver dropping you off at a nightclub and then asking, through the window, “Headed out for the night?” The menu then presents options for changing post visibility, changing post publish date, or reverting to a draft. I’ve done each of those things maybe ten times in five years of making my living in WordPress, so not the most useful menu there. In the bottom right corner (and last in tabindex), the menu also has a second button titled “Update”—I guess as in “actually do it this time.”
- Lots of other little improvements over TinyMCE seem possible but aren’t implemented. I wish Gutenberg had Microsoft Word’s
Ctrl+'+ifor í, for example. Writing “Matías” in Gutenberg is just as unreasonably bad—search Google for í! or boot up Word! then copy-paste a single letter!—as it used to be in TinyMCE.
- A huge pet peeve dating back to the old Front-End Editor feature project: Gutenberg outputs all kinds of
characters into its markup. These are gross and they break things.
That’s a big list, but based on the progress they’ve made in the past three months, I’m confident the Gutenberg team can address it and all the other cleanup issues they’re facing ahead of launch.
Blocks are Cool
“Blocks” act like live-updating widgets that you can drag freely around your content area.
One of the coolest things about both tech demos was that the “Blocks” concept on which Gutenberg is based came to feel less like a generic noun from Matt’s imagination (hi Widgets!), and more like something actual and cool.
In terms of the user experience, “Blocks” act a lot like live-updating widgets that you can drag freely around your content area. (The eventual plan seems to be to extend Blocks to sidebars, headers, footers, and everywhere else, but one thing at a time.) They have special features, one being that you can save them into Block Templates: Block combinations, such as “image, text, image, blockquote” that you can reproduce endlessly across your site.
Blocks are not new to anyone who’s used a page builder; they’re often called “Modules” in that context. But having them in WordPress core—and seeing that this is now the best way to add everything from a blockquote to a video embed—feels really good. I’m also really excited about the plan to combine widgets, shortcodes, and custom HTML (known, in Gutenberg’s documentation, by the gratuitous phrase “Mystery Meat”) into the unified, live-updating interface that Blocks provide.
Even more than that, I’m excited that Blocks can be the design element that finally unifies and defragments WordPress theme and plugin development. More on that in the next section.
80% Done, Just 75% Left to Go
One thing that feels important to acknowledge, as an element of context, is the set of absolutely enormous challenges that the Gutenberg project has successfully navigated to get to this point. Those include a pretty-much-universally-disliked beta release (the plugin still has a cool 2.5 stars in the repo), sharp and ongoing controversy over everything from the proper placement of meta boxes to the essential nature of WodPress itself, a game of software licensing chicken that bent the wills of the—of the Facebook legal team? Is this real life?
Matt said he believed, and hoped, that the hardest parts of the Gutenberg project were behind him. Looking at the challenges the project has already faced and overcome on the way to becoming the almost-good editor it is today, that’s getting harder to doubt. That sense of “this is happening” is as important as any individual feature that Gutenberg has today.
Gutenberg’s Effect on Plugins and Themes: Change is Coming
WordPress is asking two major things of theme and plugin developers, and they are both very big asks:
- Do free work to get compatible with Gutenberg.
- Be replaced by Gutenberg.
So there’s going to be a lot of disruption in the plugin and theme space. Nevertheless, I think this is a development that the WordPress community has badly needed. I’ll explain why.
Gutenberg and Existing Plugins
Thousands of plugins will have to change to align with Gutenberg, with big benefits for the ones that do.
Plugins from WooCommerce to Yoast—to say nothing of the thousands of smaller plugins that register widgets or shortcodes or metaboxes—will have to change in not-yet-fully-specified ways to bring their UIs into alignment with Gutenberg Blocks. The benefits of having done this will be awesome: for example, WooCommerce has mocked up how a “Recent Products” Block might look under Gutenberg, and it’s a vastly better user experience than the ugly shortcode we have at present.
So there’s a lot to be excited about here. But the transition will be messy and time-consuming, especially for smaller developers and free plugins.
Obviously, there are legacy systems for plugins that register widgets or shortcodes. For example, there’s already a Shortcode Block that let’s you paste shortcodes in just as you would in the current editor, and I’ve confirmed that it renders a Contact Form 7 form just fine on the front end.
There’s also been a very long and contentious debate about how and where Gutenberg will place metaboxes: the options panels that plugins often register. (The Yoast panel, or WooCommerce’s product settings panel, which currently live below the TinyMCE editor, are both examples of very complex collections of metaboxes.) I don’t know how this got worked out, and I won’t pretend I do; but my understanding is that there’s Something Planned. Certainly I know that Gutenberg has promised not to break (“legacy”) metabox support.
Plugins shouldn’t break when Gutenberg ships, but if you want to keep your plugin up-to-date you will have to adopt its conventions.
So most plugins shouldn’t break the moment Gutenberg ships. The issue is more that shortcodes won’t preview properly while other things will, that fewer and fewer people will be used to embedding content in the old ways, that metaboxes will be stuck somewhere off to the side, that the alternatives that are Gutenberg-compatible will be more attractive and user-friendly, and so on. In other words, if you want to keep your plugin “up-to-date”—in a general sense that will vary plugin-to-plugin—then you’ll have to work through Gutenberg.
Direct Competitors: Page Builders
Gutenberg is looking very scary for existing WordPress commercial page builders.
Gutenberg is looking very scary for one class of plugins: commercial page builders. As Matt himself mentioned in the State of the Word, the 20+ commercial page builders in WordPress exist because there’s a massive need that the core software isn’t meeting. Gutenberg will go a long way (although not all the way; see below) toward meeting it, and it’s hard to imagine Gutenblocks ever being compatible with Beaver Builder Modules or Visual Composer Horrors or whatever they call them.
There’s a philosophical question here: if WordPress doesn’t have something important, so a lot of people build it, so WordPress takes notice and puts all those people out of business, is that a good thing? It seems a bit like a mama crocodile eating her babies—certainly that’s how I’d feel right about now if I’d worked hard on a page builder. Matt’s answer was simply that previous WordPress features haven’t put commercial plugins out of business, but I’m not so sure in this case.
That’s a good segue to where the real craziness is going to be: themes!
Gutenberg and Existing Themes
The theme marketplace is about to get really crazy.
Matt compared Gutenberg to the Customizer: something to standardize the bad roll-your-own alternatives (theme options panels) that were proliferating in the absence of a strong choice from core.
But Gutenberg is different. To a large extent, a WordPress theme, as currently designed, is the bad roll-your-own alternatives to the custom layouts you build with Gutenblocks. Gutenberg takes themes and absolutely eats their lunch.
Why would you want a theme’s “Hero Image” widget, if you can have a “Cover Image” Block that embeds anywhere and live-previews?
Why would you want a theme’s “Call-to-Action Button” shortcode, if you can have a “Button” Block that embeds anywhere and live-previews?
Why would you want a theme’s “Our Team” page template, if you can have (or create) a “Team” Block Template that embeds anywhere and live-previews?
There is a massive amount of theme code that is written in ways that Gutenberg makes obsolete.
The point is that there is a massive amount of theme code that is written in ways that Gutenberg makes obsolete. Fixing all your randomly architected theme features to be in line with Gutenberg (that is, to register them as Gutenblocks) means a massive rewrite on every theme you sell.
What About Page Builder Themes?
Over the past few years, many theme developers have realized that hard-coding layouts and layout elements isn’t the best way to do theme design. Instead, the user should be able to take elements that are specific to the theme (like a custom-designed “Team Member” module) and put it wherever she wants on the page.
These theme developers have bundled their themes with commercial page builders—specifically, with the market-leading builder and Shortcode Death Star known as Visual Composer. Rather than register custom layouts (through, for example, widgetized homepages), these developers registered custom Visual Composer Modules, and made their themes essentially thin wrappers for Visual Composer itself.
If anything, these theme developers are worse off than the ones that don’t embed a page builder. They’ve made the right choice in creating all their layout elements in the language of a drag-and-drop page builder—but it’s a page builder with which the page builder in WordPress’s core software will soon openly compete.
These developers will have to decide whether to pull partnership with VC (which may be legally complex in ways I don’t understand) and rearchitect absolutely everything they do into Gutenblocks; or stay the course with a layout solution that, if there is a benevolent force in the universe, will start to shrivel come April.
Gutenberg, Themes, and Plugins: Why This is All a Good Thing
What the WordPress plugin and theme ecosystems need, above all else, is consolidation around a clear set of choices.
If you’re a theme or plugin developer, I sympathize with your position. I would not want to be in either market myself right now, particularly as one of the perennially vulnerable and overwhelmed small players who are often doing the highest-quality work in the space.
However, as I’ve written a couple times, what the WordPress plugin and theme ecosystems need, above all else, is consolidation around a clear set of choices—specifically, for layout creation. When I last evaluated Gutenberg’s potential to become this set of choices, I was discouraged. Now it seems almost inevitable.
Consolidation means the removal of redundancies, and the plugin and—especially—theme marketplaces are massively redundant. Let’s examine what reducing redundancy in each case looks like.
The Plugin Ecosystem Should See a Gutenblock Gold Rush
Right now, we have 50 WordPress form plugins. (At least; I stopped counting.) None of them look good on your theme. Why is that?
It’s because none of them know anything about the environment they’re being dropped into. They don’t know how wide your content area is, or if they’re full-width or in a column layout—or even if they’re in your content area or a sidebar. They also have no idea what style decisions the theme has made. They can sometimes use clever tricks to inherit some of the theme’s CSS; but they act, fundamentally, without any knowledge of what the theme’s overarching layout, color, and typography choices may be.
As a result, form plugins look a little drab in WordPress—or perhaps safe, like the way you’d introduce yourself to someone whom you may or may not have met, who may or may not speak your language, who may or may not be a child.
Gutenberg is the solution to this issue. It makes strong, specific choices about several very important design elements, such as:
- How the theme identifies its primary color scheme.
- What column layouts look like.
- How a particular Block embed can know what it’s next to and surrounded by.
As these standardized choices propagate across WordPress, there should be a rush to create plugins—form plugins, gallery plugins, author bio plugins, social follow plugins, and so on—that make use of them.
For example, a Gutenblocked social follow plugin would have icons that used the theme’s “accent colors” by default, could smoothly accommodate being placed next to other layout elements, and would live-update as the user added and removed social media links.
The eventual result should also be that the current players who move most quickly and effectively to Gutenblock their elements will become strong first choices that themes build around. A theme might list its Block compatibilities—the Gravity Forms Block, the Easy Social Share Block, the Modern Tribe Events Calendar Block, and so on—which it knows exactly how to style elegantly by default.
Once there’s a single shared language that almost all themes and plugins use to describe their layout and design choices, much stronger integrations become possible and likely.
These theme-plugin integrations are less common now because all form plugins, all event calendar plugins, and so on embed more or less equally well (that is, equally badly) into any WordPress site they’re dropped onto. But once there’s a single shared language that almost all themes and plugins use to describe their layout and design choices, much stronger integrations become possible and likely.
Conversely, the more obscure players, especially the ones that (because of neglect, resource constraints, or whatever) don’t make the transition to Gutenberg, are likely to be strained out over time.
So where we have 50+ about-equally-okay-looking form plugins right now, in three years we may have ten—and one or two “winners” whose Blocks most themes customize themselves to. While the consolidation will be painful in a lot of individual cases, the end result should be much more like a unified software community where things can actually talk to each other, and that’s something very much to look forward to.
Themes Need to Change
There’s no way we need 50 form plugins, but there’s really no way we need 11,000 ThemeForest themes, a huge bulk of which are virtually identical, arbitrarily and badly coded, and overstuffed in the “It Does Everything!! No Coding Required, Time for Your Website to Take Off Into the Sky” manner that the free market has tended to encourage.
In fact, I can state my position a bit more strongly:
Themes Need to Not Really Be a Thing
Once the WordPress community is unified around a layout builder that works in Blocks, themes should do three things:
- Make attractive default choices outside the content area: header, footer, navigation.
- Offer a basic default visual language: widths, colors, typography.
- Offer custom “skins” for Blocks—both Gutenberg’s core blocks and plugin-based Block extensions—that integrate with the theme’s overall visual language.
This is what Squarespace templates do, and the user experience is immensely better for it. A Squarespace template is basically some default colors and fonts, a menu layout, a max-width on the content area—and a default way that Squarespace’s standard blocks, like its contact form, appear when dragged onto the front-end.
That means that everything else that WordPress themes do is overkill. “Home 1” through “Home 8” custom page templates: overkill. A three-column “Our Services” layout registered as a set of Customizer options: overkill, just register a Gutenberg Block Template and let the user decide the number of columns. A custom “Album Player” widget: overkill, there should be a Gutenberg-compatible plugin that registers a Block for that, which the theme then skins. A custom “Pullquote” shortcode: overkill, just skin the Gutenberg one.
When layouts are completely custom, all the heavy lifting is in plugins, and themes themselves are customizable, do we really need that many themes?
In the world that I believe—and hope—is coming, themes will need to sell themselves on design: great initial design choices, great-looking Block integrations, and not a lot of new functionality that isn’t available in Gutenberg or its plugin-based extensions.
And the theme marketplace shouldn’t be that big. Squarespace has maybe 100 templates and gets by fine. In my opinion, 1,000 very good WordPress themes would be plenty. Layouts are completely custom, all the heavy lifting is in plugins, and themes themselves are infinitely customizable in terms of colors and typography. Do we really need more than 1,000 default ways for that to look?
Once Gutenberg is fully adopted, themes shouldn’t do that much. They should no longer be the central purchase you make in setting up a WordPress site.
Whatever the number, the main point is that themes shouldn’t do that much. They should no longer be the central purchase you make in setting up a WordPress site, and the vast proliferation of “All-In-One/Builder/Parallax/etc.” themes on ThemeForest should transition, over the next few years, from “shaky, low-quality, and oversaturated” to “full-retreat.”
Summing up: in the WordPress theme and plugin ecosystems, Gutenberg seems poised to be a bit of a cleansing fire. I don’t like to predict the future in tech matters, so don’t get mad if everything I just wrote turns out to be totally wrong. The big takeaway is that a massive consolidation—but also improvement—of the plugin and (especially) theme marketplaces is something that I believe Gutenberg’s arrival in core will provoke. More to the point, I hope it does.
My Kingdom for a Front-End Editor
The worst thing about Gutenberg is that it’s a back-end editor, not a front-end editor.
The worst thing about Gutenberg is that it’s a back-end editor, and not a front-end editor. In other words, you use Gutenberg in the back end of your site—the WordPress admin—as opposed to on the front end, the website that your visitors see. With Gutenberg, you only see what your content will actually look like once you Update (on the back end) and refresh (in a second tab, on the front end). Thus it has always been with back-end editors.
(Guys, Gutenberg Isn’t a Front-End Editor)
That Gutenberg is a back-end editor is also, bizarrely, the subject of some controversy. In the State of the Word, Matt called the experience of editing in Gutenberg with some theme styles applied “true front-end editing,” which thoroughly breaks the definition not only of “front-end” but also, perversely, of “true.” I had a chance to push back on that terminology in the Q&A, and he clarified that Gutenberg is what it in fact is: a back-end editor that tries, as much as possible, to give people a sense what the front end will look like.
This isn’t some sort of minor technicality. Writing this article, I felt—as usual in WordPress—frustrated and confined to be writing in a dim, gray WordPad-like editor, not writing a webpage.
“Writing a webpage” is what Squarespace and Beaver Builder give you with their front-end editors, or what the old Front-End Editor (note the name!) feature plugin was aiming for. It means that my editing flow is as follows: I add content onto my webpage, I hit “Save,” and my changes stick where I put them for me and my visitors to view.
That, literally, is what-you-see-is-what-you-get: WYSIWYG. Everything else that uses that term—including Gutenberg—is lying, precisely like the people selling those “barefoot shoes.”
My understanding is that the next step, after Gutenberg launches into Core, is to put it into the Customizer. That will be front-end-like: you’ll make changes in one view on the front end, and save them, and see the final product on the same front-end page.
But it won’t be actual front-end editing like Squarespace, Beaver Builder, and even Visual Composer have been doing for years now. And as I’ve written before, it’s pretty obvious that front-end editing is what the market wants: any large paid solution (inside or outside WordPress) either starts out with it or adds it ASAP.
Why Gutenberg Won’t Do Front-End Editing: It’s Too Hard
Gutenberg won’t ship a front-end editor, because writing one into core is too hard.
So why is Gutenberg not going in the direction of a front-end editor? I haven’t confirmed this with anyone else, but I’m fairly sure the answer is simply: It’s too hard!
Obviously, writing a front-end content editor is not that hard; dozens of commercial solutions have done it. But there’s a difference.
If you buy a commercial front-end builder, and it doesn’t work on your site, you can just ask for a refund, move on to the next builder, and everything is fine.
WordPress core is different: there’s no “refund” when WordPress’s default editing experience is broken on your site. That instead becomes a black eye for the software itself, and a support ticket for someone (who is not being paid for her time) to try to help you with.
- On any random, potentially awful hosting;
- With the settings, markup, and styling of any random, potentially awful theme;
- With any combination of random, potentially awful plugins changing and adding to the front end however they want.
I love Beaver Builder, but it doesn’t work everywhere. I’ve had projects where it wouldn’t cooperate with the theme and plugins around it. That was fine: I just tried something else. If the software was in WordPress core—with the implicit promise that it would just work on my WordPress site—then those same issues would have been a fiery Trac ticket, or even a sharply critical tell-all editorial here on WPShout.
Gutenberg has to be a back-end editor, to keep the controlled environment of the editor separate from the chaos that users may see on the front end.
So a front-end editor in core is simply too hard: too much can go wrong. Gutenberg has to be a back-end editor so that it can preserve a separation between the controlled environment of the editor, and the potentially (depending on the theme and plugins) wild-and-wacky markup that users actually see on the front end.
As a sidenote, this also explains the non-adoption of the Front-End Editor plugin, which (if it worked) could have been Gutenberg but better several years ago. What happened was that the brick wall of complexity that I’ve described here became obvious, and the promise of front-end editing in core simply became a known dead end.
Sounds Like a Job for the Free Market
The race is on for a commercial plugin that puts Gutenberg on the front end.
I have no idea how this would need to work technically, but I know it’s possible. The people marketing this plugin wouldn’t be solving a technical challenge no one else could solve; rather they’d be liberating a Gutenberg-based front-end editing experience in two ways:
- It doesn’t have to work everywhere.
- Paid support.
Essentially, this plugin would just be an extension of the existing technical work on Gutenberg that leverages the lower expectations—and the for-profit nature—of commercial plugins relative to WordPress core software. It’s a slam dunk!
So if you’re a WordPress up-and-comer, figure out how to get Gutenberg on the front end. The world is yours for the taking.
I Guess they Called it Gutenberg for a Reason
From what I saw this weekend, the name “Gutenberg,” and Matt’s perhaps slightly self-satisfied defense of that name, now feel justified. The default publishing experience in WordPress is about to be not merely different, but much better. There’s also good reason to believe—and certainly to hope—that Gutenberg will also truly unify the WordPress technical landscape, so that things can actually begin to talk to each other rather than endlessly reinventing the wheel.
What do you believe Gutenberg’s effect will be on WordPress? Please, print up your thoughts below, and publish them for all the world to see. We have the technology.