I’m getting ready to freelance again for the first time in a few years. Most of my experience in that arena comes from back when I lived in NY & ran a one-man tech support LLC for a few years because somehow my full-time job wasn’t enough to do me in. This time, I’m going to use what I’ve been learning since 2019 to provide web services to small businesses & individuals through the web development LLC that I started in 2021.

Two big concerns of mine were having options for clients who want to maintain their own content & having an ecommerce solution for clients who want to do something similar & manage their own catalog. I looked at a lot of options including things like Shopify, SnipCart & a ton of different free & paid services. Ultimately, I decided to try working with headless WordPress.

Why headless WordPress?

I’ve used WordPress for my own personal blogs since 2011. I’ve also used it professionally for clients who already had WordPress sites & wanted me to continue using it on theirs. This includes using WordPress builders like Divi & Elementor. Ultimately, I didn’t like the experience of any of the builders. For my own sites, using the default editor was fine, because I didn’t know how to code when I started blogging & primarily wanted to get content out.

Now that I can code, I want to continue to do so, for the flexibility, customization & control that it offers. There’s a lot of freedom with having the ability to build out anything that you can think of, as opposed to relying on a theme & hoping it has all of the options & the style that you want for a website. And, while WordPress has a reputation for not being secure, I’ve learned that it actually is very secure. The main vectors of attack on WordPress sites are actually from third-party plug-ins, which don’t necessarily all conform to the same security standards.

Headless WordPress lets clients keep using WordPress’ GUI for content management while separating (decoupling) the front-end. So, they can write new posts or pages & I can then build out custom front-ends with tools like JavaScript, React, Next.js, or other technologies & fetch the content via the WordPress REST API & render it however I like. This same approach can even extend to ecommerce setups using plugins like WooCommerce. Clients get the ease of managing products through WordPress & I can create a custom storefront experience for their customers.

Vanilla JavaScript

When I first started experimenting with headless WordPress about a month ago, I wanted to get familiar with the API so I built out a small project using vanilla JavaScript that fetched posts from my coding blog & rendered them. I found that the content of the post bodies was sent as a big HTML string & there were endpoints that could be called for other information, like featured images, tags, categories, slugs, excerpts & more.

By default, the WordPress API returns the last 10 blog posts that were written unless a different number is specified in the API call. I built out a small function that mapped through this response & rendered the post contents. I was horrified to see all of the classes that WordPress attaches to so many elements & that horror was only deepened when I found that the CSS for the returned content isn’t openly available.

I searched & found a library that included a lot of base WordPress styles, but not everything & none at all for WordPress themes. So, ultimately, I used my blog as a visual reference & wrote out my own styles for most of the returned elements using a combination of the element types & the classes provided by WordPress.

This worked for a lot of the content that I wanted to render, but there were some that were very difficult to handle in this way. Image galleries, in particular, confounded me. Ultimately, I didn’t lay them out in the same way that they are in my blog. I’ll have to see if there’s a way to solve this later on. I have some ideas to test that I’ll report on once I’ve given them a go.

Astro

My friend Sam went through the Astro tutorial a few months ago & got really excited about it. He recommended it to me & although I looked at some videos about it, I didn’t carve out time to try it until a few weeks ago. Astro is a server-side web framework for JavaScript. It allows developers to mix & match components written in most of the major JavaScript libraries & frameworks like React, Angular, Vue, Svelte & so on alongside its own Islands architecture & JSX. A strength is that it renders sites as HTML so that delivery is lightning-fast.

After finishing the tutorial, I used Astro to rebuild the headless WordPress site I had previously made with vanilla JavaScript. It was impressive but had some hiccups. For example, I encountered weird encoding issues where apostrophes and special characters were replaced with things like "’". I tried several fixes, and the issue eventually resolved when I switched to prerendering on the server instead of client-side rendering. I’m still not 100% sure why that worked.

I experimented with a lot of things building out this iteration, including pagination, infinite scrolling, prerendering, learning about IntersectionObserver, prefetching, layout components, dynamic routing & so much more. Astro is very powerful & I’m definitely going to revisit it again once my brain has had time to process everything & I’ve looked at some other SSG frameworks for comparison.

11ty

This week, I started exploring 11ty (Eleventy), an older but highly regarded static site generator. I’ve read that it partly inspired Astro’s creation. It’s already being used by developers building headless WordPress sites & the community has documented workflows & tools to make that process smoother.

What attracted me to 11ty was its speed. It’s known for blazing-fast site generation – potentially even faster than Astro. One of the tools built for 11ty can pull in all the content from a WordPress blog, convert it to a supported format (Markdown or HTML, I can’t remember which), fetch all assets, and even rewrite asset paths automatically. I’m planning to try it out as a faster SSG alternative to SSR approaches and see how it stacks up in practice.