In my last article, “The Imaginary Block-vs-Classic Battle”, I made an argument for a middle path between the two opposing “block” and “classic” teams in WordPress. Instead of seeing blocks as the future and everything “classic” as the past, I think there’s value in recognizing that many, if not most, WordPress websites exist in the present – often with block editing for content, but classic templating for the theme and any advanced functionality.
It’s part of that ever-present, evergreen question in the WordPress ecosystem: Who is WordPress for?
You’ll see all sorts of variations on this theme if you look around long enough. A recent comparison from Chris Wiegman that’s been stuck in my head is whether WordPress is a “content management system” versus a “layout management system” (one of about a dozen interesting things I heard in this highly-recommended conversation from the team at Torque/WP Engine). While many developers like to think of WordPress as the tool that powered high-profile, content-first websites like TechCrunch and the NYTimes, it’s also clearly transitioning into becoming a design tool. Simply examine the Apple-style feature card for the upcoming 6.1 release. Every feature chosen to be highlighted here has to do with frontend design and layout:
Yet this big question- Who is WordPress for- goes back even further than the block editor.
Do-it-yourself or do-it-with-code
In one example, I was digging in the Post Status private Slack archives and saw an old conversation that happened around the launch of WordPress.com’s original React.js-based WordPress dashboard (you might remember it as Calypso). Many well-known core contributors debated this very question more than six years ago. Most of them made it clear that their experiences contributing to core solidified the fact that “high-end, custom websites” were never going to be the priority of WordPress. WordPress always has- and always will- focus mainly on the DIY crowd. So perhaps it’s the very idea of what it means to DIY on the web that has been shifting.
I’ve always clung to that description of WordPress as “the operating system of the web“. The end of my last post called for a future WordPress that still celebrated the ability to write your own HTML and CSS, rather than only relying on Gutenberg and theme.json to dictate your markup. In fact, the point of the article was that there’s room for both. This is mainly because I believe that WordPress’s best feature is its ability to convert DIYers into coders. The gateway that leads an internet novice into tinkering with HTML and CSS via the path of PHP is so much more accessible than one that expects you to jump from WYSIWYGs to installing NPX packages, setting up a Webpack build process, and creating custom React.js components.
I went on:
The WordPress leadership is making it clear that no-code is the future by ignoring the present – that many of us want to continue using WordPress to build websites that can’t be built in a WYSIWYG, because we want to push the boundaries of what a website looks and feels like.The Imaginary Block-vs-Classic Battle in WordPress
It was this sentence in particular that drew the attention of Ellen Bauer of Elma Studio, the theme shop behind the popular Aino Blocks framework (not to mention numerous eye-catching themes) custom made for Full Site Editing. If you don’t follow Ellen, she’s an expert in design (something I admit to knowing very little about), as well as a genuinely helpful Twitterer who has been very patient with me as I’ve publicly fumbled my way through full site editing in the past.
Here’s her original tweet, which I’ll also block quote in full below.
If some websites CAN’t be build with no-code right now, shouldn’t we push the boundaries there and build towards making it possible to use no-code WordPress for these kind of cases as well?
To me personally, it feels like if this is not our goal right now, we are missing a crucial opportunity to build for the future.Ellen Bauer on Twitter
As I said to her when I first read this tweet – I definitely need to think about this for a minute! Ellen brings up such a valuable point, that it actually took me a while even figure out my own perspective on it. After reflecting for a few weeks, I think I’ve come to understand the difference between our viewpoints, and perhaps some of my own underlying assumptions that may or may not be true.
What actually is no-code?
At the heart of Ellen’s comment is the difference between custom code and “low-code/no-code”. If you haven’t dug into low-code/no-code (I’ll just refer to it as “no-code”), it’s the name given to the computer’s ability to turn any highly specialized task into a commodity service, given enough time. It’s become increasingly popular in business circles as no-code tools enable knowledge workers and small business owners to decrease budgets and increase productivity. Whether it’s setting up a quick e-commerce site with Instagram and Shopify or even using a marketing platform to handle email auto-responses, the benefits of automation and digital systems thinking are trickling out across the broader economy.
Small-to-medium business owners especially are learning that they can circumvent massive vendor contracts or relationships with high-end developers by using these new no-code tools. Building your restaurant’s website AND including an online reservation widget or takeout ordering system? No developer required! Launching a membership site or online course? No developer required.
And yet, I’ve always felt a deep distinction between “using tools” and “building your own tools”. For many developers who leapfrogged over the page builder craze in WordPress, there was just something off about not “owning your stack” or “owning your code.” Enough time spent cleaning up the pagespeed and accessibility messes generated by page builders typically left a bad taste in your mouth. Relying on too many third-party tools was seen as a weakness, a limitation, or even a liability- meanwhile many of us freelancers and agencies relied on the biggest third-party tool out there: WordPress.
Recently WordPress leadership has sought to make the intentional point that the community doesn’t own the future of WordPress. To say that building with WordPress means you “own your own code” isn’t the whole picture. At the end of the day, if you’re developing in WordPress, or developing on any framework for that matter, the idea that you “own” your work under the auspices of the GPL isn’t as meaningful because the sheer amount of code powering a typical website grows exponentially, beyond what a single developer’s brain could even track.
Coding is a superpower
It’s one of the biggest barriers for many developers who try Full Site Editing. I know that I can create anything when I’m writing my own code. When I use the block editor, I’m often confronted by what I can’t create. And yet for others with no developer experience, it’s the opposite. What they see when they use the block editor is all the things they suddenly can create.
This is the result of the growing divide on the internet – no-code is getting more powerful, but the code that powers no-code is getting more complex. WordPress development agencies are having to make the choice of which side they’ll want to join: use no-code page-builders like Gutenberg or search for a new CMS that’s specifically built for total code control.
The future will be high-code and no-code
The internet is changing the very concept of creativity. If you look at the AI-generated digital art scene, you quickly realize how the ability to make unique and interesting graphic art is no longer limited to those with an M.F.A. and years of experience with Adobe Illustrator. Of course- there’s a separate conversation about the ethics of crowdsourcing unlicensed creativity, and the limitations of a machine learning algorithm that can only create from what it’s already seen.
There’s no doubt that this will slowly spread into how websites are made. How far off are we from machine learning that can take a list of product names and images and create an e-commerce site in seconds flat? This is still the biggest weak point in WordPress itself- creating bold visual designs in the block editor are getting easier, but creating a website that needs to actually do something is feeling harder.
I’m a believer in the Everything is a Remix mindset- that all creativity is collaborative and builds on what came before it- but can a computer create something that feels new? Will Gutenberg’s HTML and theme.json ever be able to replicate the complete freedom of writing custom HTML and CSS without requiring the knowledge and experience of both? Or is it more than enough for the millions of WordPress users who will never write a line of code and never know what “kerning” and “line-height” mean? Isn’t there value in providing these tools for them as well?
With the reliance on no-code tools come all the downsides of relying on someone else’s algorithm, from propagating inherent biases to maintaining structural inequalities. You’re always limited by the scope of someone else’s imagination. So I’ll admit that I have a deep skepticism of everything that abstracts us further from the source code. But I’ll also agree that it’s a bias based on my own experiences. I want WordPress to be for others what it was for me, however unrealistic that is. And I’m hopeful that the block editor can succeed in the places where other page-builders have failed- accessibility, for example.
One thing I know for certain – WordPress is a much larger community than I can wrap my head around. It’s bigger than the conversations about “classic” themes and deceptive plugin marketing. It’s bigger than one person’s decision on open data. When we ask Who is WordPress for? the answer has to be EVERYONE– whether you write code or just live beneath its shadow. Ellen has reminded me that there’s an entire world of potential, and let’s hope that WordPress can use it’s responsibility as 40-plus percent of the web wisely.