The web tends to be a trendy place, and no, I’m not talking about cat memes. I mean that, although we’re professionals, I find that the web really feels remarkably as though we’ve never left high school in our incessant need to “hang with the cool kids.” Trendy technologies come and go (I’m looking at you, JavaScript community), generally leaving a lot of friction for early adopters in their wake. Recently, I’ve seen this happening with content management systems rushing to implement visual layout builders, moving away from the traditional collection of fields on the backend through which a user edits and creates content in favor of a flexible, drag-and-drop interface in which what you see is, at least in theory, truly what you get. The rationale behind this is that it’s what everyone wants, and so there is a perceived pressure to fill this need lest market share be lost to Squarespace and it’s ilk.
Except, I think, that this perception is incorrect.
What Do Users Want?
In this thought process, customers want Squarespace or Wix. They want an easy way to either create and manage their website without engaging a designer or developer, or (in the case of more sophisticated and enterprise users) they want greater flexibility in their layouts for things like one-off landing pages. This thought process is driven by the success of these two platforms. And, certainly, there is a group of users for whom these are viable options. Some turn out better than others (most sites that I see built with Wix look like a train wreck…Squarespace at least manages to maintain some aesthetic appeal, but does so be enforcing homogeny), but for a group of users who do not require nor care about any unique aesthetic, are content with generic options and require no customization, then these options would make financial sense. This is, I would argue, the lowest common denominator of users.
There has always been an interesting balancing act when developing within content management systems in attempting to determine how much control is too much control to give to the client. Ultimately, the site is the client’s, and the keys to the kingdom should be theirs. In order to maintain the design that they hired someone to build, however, a certain degree of flexibility must be removed from the user, especially the user who is not technically savvy, in order to protect them from themselves. Otherwise you end up with purple and red fonts on pages and other things that make unicorns weep.
Anecdotally, I think that this is a leap in logic. Just over the past week, I’ve had discussions with two or three users who lament this trend, who want to use dedicated fields on the backend the way they always have, because they know it works, they know what to expect, and they actually feel as though it gives them more control. Layout builders are for amateurs, they think. They want to do this the right way.
Enter Gutenberg
In case you’ve been on a different planet for a while, I’m certain you’ve heard about the controversy surrounding the new editor for WordPress, code-named Gutenberg, that will ship with WordPress 4.5 as the core editor. Gutenberg replaces the editing experience familiar to WordPress users for years with the concept of blocks that can be added and re-ordered on the fly, with styles in the editor matching the way the content will render on the front end. Users who have experimented with Gutenberg, or are using the beta plugin in their sites already, have extreme reactions from what I’ve seen: they love it, or they hate it. WordPress is all-in on this becoming the core editing experience, and this is a huge gamble for the core team. The thing that WordPress has done better than anyone else since forever is giving the end user an editing experience that is elegant. Moving Gutenberg blocks around is anything but elegant. I’ve found it to be a clumsy, inefficient and outright painful process in testing.
This is even more frustrating a change for developers, as Gutenberg is being architected in React. I’ve already voiced my opinion on this as a choice for a core JavaScript framework, but I’ll re-iterate that React is a poorly-built, extremely opinionated and over-tooled monstrosity that is the worst possible choice for WordPress core. Yet, because Automattic is into it, this seems to be the fate of the WordPress community at large. Given the short, “flavor of the month” shelf-life of JavaScript frameworks, many developers find it a hard sell to want to invest the significant time and resources to learn a framework that will no longer be fashionable in a year. I’m profoundly disappointed to see Automattic drinking Facebook’s Kool-Aid here.
WordPress Isn’t Alone, Though
While Gutenberg has been stealing headlines, Drupal quietly shipped a layout builder in core with 8.5 about a week ago. Prior to this, there was a popular module known as Panels in the Drupal community that offered a very similar experience to Gutenberg, and this is what has essentially been replaced by the core builder now. This is, in many ways, a smaller leap for Drupal, as the concept of blocks has been in Drupal core since forever (or at least since the first time I worked in Drupal, which was D6), and, while they’ve gone in and out of popularity within the community, the data architecture already exists and is almost infinitely customizable without additional JavaScript tooling. All Drupal needed was a layer of functionality to provide the interface for moving these blocks around.
Layout is a Matter of Preference
The huge difference in how Gutenberg and Drupal’s layout builder are being introduced is ultimately an issue of choice for the end user. WordPress isn’t giving users a choice in the new editing experience. The messaging is essentially “here’s Gutenberg, and you’re welcome.” Drupal, being more abstract by nature, is preserving the choice. If you don’t want to use it, simply don’t enable the module. If you prefer to use dedicated field groups that you control tightly in the theme layer, user Paragraphs instead…an approach that I’ve used for a long time in custom WordPress themes using Advanced Custom Fields.
Interestingly, this is scheduled to a be topic of conversation at DrupalCon Nashville in a couple of weeks. I’m looking forward to attending these.
Breaking APIs?
Another interesting point is that, as the web becomes more API-driven and sites and applications become more frequently progressively de-coupled, I can’t see how these layout builders can’t introduce nearly insurmountable obstacles to headless sites driven by these content management systems. This is a curious step backwards to giving developers cleaner separation in the front-end and back-end stacks, something that was desperately needed.
Shiny New Things
Ultimately, I don’t think that Gutenberg is a bad idea. I think that it should be build differently under the hood, but I’ve also felt the same about WooCommerce for some time and that hasn’t been a deal-breaker for working in it. Gutenberg can certainly move WordPress forward, and give a lot of users and developers more flexibility in the content that they can produce. I just think that a choice should be preserved. While you can fall back to the classic editor initially, the core team has been fairly clear that this only buys you a year at most before the second phase of Gutenberg ships, which promises to take over the template hierarchy as we know it. We can only imagine what that means at this point.
I think that WordPress should learn from Drupal’s philosophy here and maintain the choice. The current editing experience, while painted by the Gutenberg team to be somehow antiquated, is one of things that many WordPress users, especially bloggers, love. I think there’s a huge risk of WordPress hemorrhaging market share here, or worse, fracturing the community. It’s not difficult to imagine a future in which WordPress forks and we end up with a classic and Gutenberg version. The complexity that this would introduce to the ecosystem would be counter-productive for everyone, and would be a tragic turn for what is arguably the most popular content management system in use today that could be have been prevented by simply preserving choice.
Time will tell how this change will effect both WordPress and Drupal. I think that pressing forward with the assumption that this is what all users want is a strategy that is not going to serve WordPress well. I can’t imagine this change not ending with damage to WordPress. I hope that the damage will be minimal.
One Thought