Why I Use a Headless CMS

You've probably heard of headless CMSs, if not, the short version is that it's a popular new method of building things online (like a website) that separate the content from the presentation.


History

When Wordpress was in its heyday, I was building Wordpress sites along with pretty much every other web designer. It was clunky and awkward, but that was the best tool available. Then other PHP-based CMSs started to show up and I used some of them for a while, but nothing ever really felt elegant. To make things worse, if I wanted to move from Wordpress to any other service, pulling the data was more trouble than it was worth, it was easier to just redo it in the new framework.

Setting up a computer with Wordpress was a hassle, there was no graceful way to sync your local database with a remote database, the framework itself was a bit of a chonk, and the themes (and ideology behind themes in general) made me vomit.

I know that there are now workarounds for a lot of my pain points. And even back then there were some tips and tricks, but it was (and probably still is) a mess.

Then I got a client who wanted me to build the UX on an app using Ruby on Rails*. I started using a very powerful tool that allowed me to write code in Haml (and later Slim) and views and templates were not only infinitely more powerful than Wordpress, but so much simpler. There were no databases to sync; setup was comparatively easy compared to Wordpress; and I could see every bit of the app locally on my machine. When I saved my view, my local site would live refresh. If I wanted to view some admin page or the checkout, it functioned like a real site.

Best of all: everything was stored in git, which made co-working a dream. Keep in mind, this was the early days of git back when some people still used stuff like SVN and most people didn't use any code repos at all. Every time I pushed to the dev branch in git, that branch would automatically push to a password-protected staging site that my client could view. Likewise, the master pushed to the live site.

When I moved on to the next website and tried to use Wordpress again, I just couldn't. It was so clunky and instead of being focused on designing the best thing I could design, I was focused on working with a sub-standard tool set.

I had a business decision to make: I could learn Wordpress better and become a pseudo PHP developer and start building themes (which is where the money was), or I could stop using CMSs altogether and focus on apps and static sites that I managed on retainer. I chose the latter.

I don't mind doing the UX for apps, and Rails is fun, but websites were where my heart was. So when clients had changes, I'd post them (usually within 24 hours). This worked out really well actually. It allowed me to build in a static-compiler that was quite similar to Rails (Middleman), clients didn't have to worry about managing a CMS (always a trouble spot), and the website was designed around the content, not a template. This works better than you'd expect. But it also had limits.

Dawn of the Headless CMS

So, when Contentful caught my eye, it changed everything. This was a decent looking (to be fair, not awesome) service that my clients could figure out and would allow them to upload/update some of their content, and I could still use the tools I wanted to use that allowed me to focus on building the best site possible.

So I learned how to integrate Contentful into Middleman. Mostly I use it for blogs and things that are very template-driven (such as staff photos or bios).

Why I Use it Today

Static Site compilers are in their heyday. And although I never learned to love Wordpress, I'm on this train 100%. I love the idea and the results. Static sites simplify the web, which is what we all need. Because they're so popular, new ones come out every day. And so I might design a site in Middleman in 2018 and then redesign it in Gridsome in 2021. Because a lot of the copy is in Contentful, I can redesign sites a lot faster.

I still believe that content should shape a page and I'm not a huge fan of small sites being 100% template driven. But now Contentful is an integral part of my tool kit.


The Future of CMSs

Everyone is getting on this train (even Wordpress I think).

I stay with Contentful because I feel like it's still the best offering. However, I don't get their pricing. My clients all fit on the free tier and always will, none of them can afford $500/month for a CMS.

Larger companies that I work with (Amazon) might use Contentful casually, but if they ever got serious (which I think would be a godsend for Amazon), they'd just buy the company. So I'm not quite sure how Contentful stays in business, but for now, that's who I use. If Contentful folds, they have ways to export 100% of your content and pull it into other services.

Contentful can be super powerful, and if Amazon started using them, it could do amazing things. Like a lot of companies, Amazon's iOS/Android apps are just wrappers on the website (mostly). The problem here is that iOS is very powerful and fast, and a skinned website can only do so much. They could use Contentful to share the same content between their iOS app and their website, their end-users could edit the content directly and they could set up admin-approval for new content. That same content could be integrated into the Internet of Things (IOT) (like smart fridges) and print catalogs. Amazon is the use-case where Contentful would really shine. But it's not how I use it (or why).


* DHH (the guy behind Rails) is opinionated and he (and Rails) polarize a lot of people. Personally, I'm a huge DHH fan and think he is spot on 90% of the time. However, I've been using JavaScript SPAs more as the components in Vue.js are so powerful and page transitions still feel like magic. For me, on the front end, the two are very similar.