Skip to content

Michael LaRoy - Home

From WordPress to Statamic: Why Full Control is Better For the Front End


I recently wrote about the visual page-builder approach driving developers like me away from WordPress, and towards systems like Statamic. In that post, I discuss the drawbacks of the Block Editor, and why the traditional fields-based content entry paradigm in Statamic is a better experience.

Here, I’d like to discuss the benefits of transitioning to Statamic for the front-end of websites.

Better Semantic HTML, More Control

I realize that semantic HTML isn’t the exclusive domain of Statamic, and neither is WordPress incapable of outputting semantic HTML. However, one of my chief criticisms of page-builders (including the Block Editor), is the potential loss of ultimate control over the HTML output on the page..

In WordPress, one can largely get away with building full sites using core or third-party blocks these days. Many of these blocks are well-constructed, and are fully capable of proper HTML output at the end of the day. However, this comes with the trade off of giving up that control.

However, the likelihood that a custom WordPress site is fully dependent on these third-party systems is probably minimal. This is because, if we can’t control the markup, we are more or less reduced to the controls provided by the Block itself, or by overriding any CSS that comes with it; this is not an ideal situation.

The logical solution to this is to create custom blocks, with or without ACF. Such blocks are complex to build, particularly if you are going the fully-custom route using JavaScript with React. Generally, this only makes sense for high-ticket projects with generous budgets. Even the ACF approach, while more managable, comes with a layer of complexity that can be an impediment to a successful project.

In any case, having full control over the markup via custom blocks is the only way to be guaranteed that the blocks will contain the HTML we truly want, with the HTML and semantics we want. Many may find the effort not worthwhile, leading to potential setbacks in their projects.

Better Performance, Better Accessibility

In addition to more control over our HTML semantics, we can have achieve better performance with direct access to the markup. If we want to add loading="lazy" to our image tags, we can do it directly in the templates, without having to write custom functions or filters to change what the core framework provides.

On top of this, we can be more specific with our srcset attributes and <picture> tags to achieve more fine-grained control over image output.

The same goes for adding text or attributes designed for screen readers. Do more complex block plugins ensure that their interactive elements include the necessary aria attributes to indicate open/closed states on elements like accordions? Can we add screen-reader-only text where appropriate, without resorting to inline-styles each time?

Making Changes is Easier Elsewhere

Naturally, in order to create custom blocks at all, a developer needs to be involved. This is a realistic expectation for any project beyond the simplest use cases.

If resorting to full control over our HTML output by creating custom blocks is necessary, it’s more practical to simplify the process and explore alternative options.

Take Statamic, for example: creating partials, components, and leveraging its Fieldsets and Blueprints systems is cleaner from a code perspective, keeping the cognitive load to a minimum. Plus, using its Antlers templating system makes all of this a breeze.

We can use Fieldsets to create a page-builder system that feels similar to the ACF Flexible Content field. We can also create “sets” for injecting custom components into the “content” area in a way that could be compared to the WP block system. But, our configuration doesn’t have to factor in “allowed” blocks (if we wanted to leverage InnerBlocks). Our code will be cleaner and leaner, we won’t need to “register” our blocks, or create separate styles for the editor and for the front-end.

Embracing Full Control for a Better Front-End Experience

Transitioning from WordPress to Statamic offers developers the opportunity to regain full control over the front-end experience of their websites. With Statamic, we can easily implement our desired semantic HTML and utilize its streamlined templating systems to ensure better performance, accessibility, and ease of maintenance.

At the same time, we benefit from an excellent user experience with the CMS. Statamic’s flexibility and control surpass the limitations of WordPress’s block-based system, making it the superior choice for anyone seeking full command over their front-end experiences.

Dwight: "Give me control"

5 Accessibility Fixes You Can Make Today

Learn about the most common reasons that websites fail accessibility standards, and what you can do about it.