Can WordPress avoid the pitfalls of the no-code revolution?

Elma Studio's Ellen Bauer challenged us to consider if WordPress can "push the boundaries" of no-code and "build for the future."

laptop with gears and newsletter in the background

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:

6.1 Release card highlighting fluid typography, the styles engine, the twenty twenty-three theme, layout controls, header & footer patterns, list and quote blocks, and more design tools.
Screenshot of the 6.1 release highlights

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’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.

WordPress itself has been different because of how easy it is to change every aspect of it through actions and filters. WordPress was the one part of the stack you didn’t have to worry about, because there was always a way to get it to do what you want. While I’m just now starting to see the potential of this new JavaScript-powered WordPress, much of it exists outside of the typical WordPress developer’s control and much of that extensibility feels lost.

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

The truth is that coding still is a superpower. Right now, if you want to build the next tech revolution, you’re going to want to write some code. In fact, I would bet that what makes Ellen’s themes so wonderful is that she has a pretty deep understanding of CSS concepts like “border-radius” and “box-shadows”. And her Aino Blocks plugin relies on some pretty heavy JavaScript knowledge. You don’t create something as useful as Aino Blocks without crossing the boundary from “using tools” to “building your own tools”. That means writing code.

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.

Author Profile Image

Brian is the Technology Director at Understrap and Howard Development & Consulting. Located in Southern California, Brian is a former college instructor and full-stack developer who brings his unique academic perspective to Understrap Academy. Brian is a graduate of California State Polytechnic University Pomona and California State University Fullerton. His work has included projects for Harvard University, The World Bank, and the Colorado Department of Public Health and Environment.

Subscribe & Share

If you liked this article, join the conversation on Twitter and subscribe to our free weekly newsletter for more 🙂

MasterWP contains no affiliate links. We’re entirely funded by the sponsors highlighted on each article. In addition to MasterWP, we own EveryAlt, WP Wallet, Understrap and Howard Development & Consulting.

Latest Posts