At our recent Festive Special #WPLDN, Jamie Marsland and I participated in a Speed-Build challenge. If you've never encountered the concept before, it pits two competitors who are challenged to mimic a webpage neither had seen before in 30 minutes using the WordPress block editor.
The event is pitched as a bit of fun for the holiday season. We deliver an event at #WPLDN that brings freelancers and solo business owners together as a festive "works do" for those who may not have teams to connect with at this time of year. Of course, the event is open to all, and we see a fantastic mix of attendees.
It's been a few weeks now since the event, and something has been niggling at me since doing it - the block editor.
This isn't going to be a block editor-bashing post. I like the block concept in many ways, but I'm struggling with how I used it in the Speed Build. I did many things I would never usually do, mainly related to inline styling.
For speed, I used individual block settings to determine the look and layout of blocks. This approach isn't great for scalability or maintainability. Having hundreds of individual blocks on a page with individual styling settings is a nightmare to maintain.
As I built the page, I realised I was using a page builder—a page builder that allowed me to engage in every bad practice that every other page builder will enable users to engage in. I don't hate page builders; I've spent time with Beaver Builder and Elementor over the years, and they have their place. However, I've evolved in my development practices and dislike the ability to add styling and layout settings in multiple places. This practice should be discouraged.
When I style an element, I must be able to manage its visual representation centrally for the reasons I mentioned—scalability and maintainability. The block editor allows me to do the opposite.
I appreciate the fact that the block editor is a tool. And every tool is only as good as the craftsperson using it. But when that tool intentionally offers you ways to implement bad practices, that's an issue.
Matt Mullenweg and the Speed Build
Not long before my first attempt at a Speed Build, Matt Mullenweg, the co-founder of WordPress, took up the challenge to compete in a Speed Build following Jessica Lyschik throwing down the gauntlet at WordCamp Europe 2024.
Matt has long promoted the narrative that the block editor is intended to support a positive writing experience. Matt is far more prolific at writing than I am, and since he posts regularly, I assume he interacts regularly with the block editor.
However, watching his endeavours with the Speed Build, it was apparent that he lacked some nuisance understanding of the editor he's directly led the development of. There were several moments through the build where Matt could not find settings within blocks, only to be guided by Jamie, who was hosting this particular challenge.
The art of writing
Matt's challenges aren't surprising. If you've ever used the block editor, I'm sure you've encountered frustrations. The UI can present numerous challenges, both visually and from an accessibility perspective. The UX can also be cumbersome and not intrusive at times.
If Matt focuses on writing rather than developing with the block editor, we can probably forgive his occasional stumbles as he attempts to build the page. Plus, there's also a bit of pressure doing this challenge live.
I recently decided to write more, so I've been drafting posts and ideas for the last few weeks. While I don't mind using the block editor to write bits of content on a webpage, I find the experience of writing longer-form content in the block editor appalling. Right now, I'm drafting this post in my Standard Notes app in Markdown; it's a writing experience I find clean and unobtrusive.
There's too much that gets in the way. I want to focus on writing, and a simple, clean editor that allows me to use Markdown is the perfect solution.
The conundrum
So, if I don't like the block editor for developing pages, and I also don't like the block editor for writing. What's its purpose?
A page builder? But if that's the case, why is the lead developer of it more interested in writing with it than building with it?
I know thousands of posts tackle this issue. I like some aspects of the block editor and appreciate some of the philosophy and concepts behind it. However, maybe developing a page builder into core WordPress hasn't resulted in a tool I need for my writing, and it contradicts my development philosophy and style.
My solution
My solution is simple: stop using it. I don't mean I'll stop using the block editor altogether. However, I will stop using it to write this blog. Or rather, I have stopped. Over the weekend, I migrated this site from WordPress to Astro and TypeScript. Matt proclaimed we should "learn JavaScript deeply," I'm glad I did and continue to do so. It's opened up ways for me to build that I never had before.
I like the clean writing experience I now have. I have yet to refine the entire workflow, but that's part of the fun. As I said in some time with words, I enjoy developing processes.
When I suggested a live Speed Build to my colleagues and was asked to take the challenge, I never for one moment thought it would make me reflect on a tool I've used daily for the last 16+ years: WordPress.
This certainly isn't the end for me and WordPress, but the relationship is changing.