Are Visual Page Builders the Future of Managing Content?
I’ve been developing websites in the WordPress ecosystem for a good long time now, since around the time version 3 was making way for version 4. WordPress has evolved quite a bit in the years since (now on 6.x as of this writing), with some changes both expected and unexpected.
The biggest surprise for me, however, was to find myself excited about an entirely different platform. How did this happen? But first—let’s talk about those WordPress changes.
No ACF in core?
One of the most-used plugins, at least by developers like me, is Advanced Custom Fields. It has been the go-to plugin that enables a content-rich experience for developers and content editors alike. I fully expected a version of this plugin to end up in WP core eventually, or perhaps be acquired by Automattic and managed in the same way that Woo Commerce became part of the “family” as it were.
Recently, ACF was acquired by a significant player in the WordPress community—WP Engine. I regard this a good development, as it seems they plan to maintain it and allow it to evolve in its own direction. However, having a version of ACF in core never did materialize, and I doubt now that it ever will, which seems to me to be a missed opportunity.
Hello Block Editor
In the mean time, the Block Editor (aka Gutenberg, in its genesis) became the focus of the core WordPress team, enabling a rich UI editing experience, not totally unlike popular visual page builders.
The result was a deviation from the traditional PHP-centric template system that WP devs have been accustomed to, in favour of a React-based UI that generated HTML to be saved to the database. At least, this is the simplistic explanation.
Progress in this direction seems likely to continue, as the push for Full Site Editing (FSE) via blocks appears to be the future of WordPress theme development. Like the visual page-builder plugins of yesteryear, component-rich themes are emerging now, providing the opportunity to fully configure everything about a site without any custom code.
As I described elsewhere, ACF Pro has some features that enable it to stand somewhat in the middle of this new paradigm and the old; it provides a mechanism to create these new Blocks without React, and sticks with the familar APIs that are beloved by long-time theme developers like me. Somewhat ironically, as a front-end focused developer throughout my career, I have (so far) preferred this setup to diving into JavaScript in order to craft the editing experience alongside the front-end of the sites that I build.
A return to separation of concerns
One of the benefits of a robust CMS is staying out of the way of the content editor. I’ve had a number of clients over the years whose sites, built with page-builders, become unwieldy beasts. They become obligated to babysit the thing, and are required to have input into virtually anything and everything on the page in order to achieve the desired result on the front-end.
If done well (which is indeed a challenge), it is possible to achieve a reasonable user experience for the content editor, and provide them some measure of control. Without any slight against FSE theme authors (Frost looks amazing, by the way), it seems to me that the risk here is similar to what came as a result of the bloated page-builder plugins we’ve been subjected to.
After experimenting with this paradigm for a few years now (perhaps not enough, as of yet?), it seems that the old way might have been the better way. Isn’t it better to keep the content as the focus of the content editor? For any rich or complex front-end, can we not leave that to theme developers and abstract away complicated UI controls for these content editors? Isn’t the old ACF Flexible Content way better?
I’m not sure I know the answer here definitively, but I think it’s possible to create better user experiences, and developer experiences, while saving time (and money) by moving to a different, more familiar and intuitive, CMS experience. Furthermore, this will result in less code, fewer errors, and an overall cleaner implementation for everyone involved. There is at least one CMS platform out there that seems to share this vision in a way that I admire, and that is Statamic.
Back to basics with Statamic
Over the last year, I’ve been lurking at the edges of the Laravel community, especially after having the opportunity to attend Laracon last year (2023) in Nashville. A significant player in that community is Statamic, which is a fantastic CMS that sits on top of Laravel, which is a fully-featured web framework in PHP.
The CMS itself requires a developer (as most custom WP themes still do), but it is quite intuitive, such that even a novice content editor can navigate their way around with success. Configuring it is straightforward, as it comes with all the content fields you might expect with ACF Pro (a paid product), but out of the box.
Template development is also intuitive and well-documented, and ends up being a real joy to work with, particularly after enduring the complexities of modern WP theme development. The cherry on top is that no database is even required. Of course, if that’s your preferred solution, you can use one if you wish without much difficulty.
While Statamic has a more traditional model with fields for content (compared to the page-builder model), its ease in assembling templates and blueprints for content makes it anything but traditional. Indeed, the overall experience is one of simplicity, which gives it its power.
As I’ve been learning the Statamic world, I feel much more productive than I do with WordPress, despite my decade-plus experience building with it. If it can be helped, this will be my preferred platform for building going forward. Most recently, I re-built my wife’s site using Statamic, much to her delight, and to mine.
So, are visual page-builders the future? Perhaps so, and it looks to be for WordPress — but not for me.
Anticipate more content here on this topic in the future as I grow in my knowledge and experience with Statamic and Laravel 😎