Last year I switched this domain from running a traditional WordPress site to running a headless WordPress site. I built the site with Next.js, Tailwind CSS, and the WordPress REST API. I had it set up to pull data from three different WordPress sites, allowing me to keep an art journal, post my art, and keep my writing all in one place. It was a beautiful site. It was fast. It was a mistake.

Headless Sites Look Shiny

A headless site had a lot of glimmer on the outside. I didn’t need to worry about things outside of my control slowing down my site. It was going to be super easy to have staging and local development. Since it was built completely in JavaScript, I could focus all my development on one language and would no longer see an error since I used + to concatenate a string.

I had already been using the REST API for a better Homepage. It was built with React and was pulling together posts from other places I was writing, grabbing my latest artwork. Converting to next.js was made easier by this as I could reuse some of the react components I already had.

Another benefit, but one that turned out to be a cost, is that I was in complete control over everything on the site. I didn’t have any unnecessary CSS. Every piece of code was one that I explicitly had chosen to be there. This isn’t the benefit you might think it is though.

And all of those things were true, but none of it was anywhere near enough to counter the cons.

The Cons of Headless WordPress

I didn’t think about how much I relied on previewing my content until I no longer could do it. It became a lot hard to just press publish. I could have build post previewing into my site, but then I would have been reinventing the wheel.

Similar to the lack of post previewing, I also no longer got new features for free. Each new block that came in WordPress core was one I needed to build support for in my site if I wanted to use it. 90% of the time, this didn’t matter. I used headings, paragraphs and images but if I wanted to use something else, I would have needed to build in support for it.

Neither of those compares to the biggest con which is that publishing becomes harder. I could write on the go, but I couldn’t publish since publishing required a build step. This was somewhat of a choice as I could have had the site dynamically pulling from the API, but then I lose one of the biggest benefits of a next.js which is server-side rendering. Publishing took longer and if I noticed a typo (since I couldn’t preview and I tend to have them) this meant re-running the build. Slow publishing is the antithesis of WordPress.

Overall, the biggest cons of Headless WordPress for me were:

• No Post Previews
• WordPress Features Weren’t Free
• Slower Publishing and no on the go publishing

Next Steps for my site

I’m now using Full Site Editing and the in-progress Twenty Twenty Two theme. Giving this a test drive is helping form some thoughts on FSE and is helping me open some issues

I am a developer at heart, even though my day-to-day-work is more management than code. I’ve also long tried to overengineer my personal site and going headless was absolutely that. Previously when overengineering, it didn’t impact me as a user, but now headless WordPress was the step to far. I like to try new technologies. I like to build things. But building this site as a headless WordPress site was a mistake.