I Have a Blog!

Welcome to my blog! I have no idea what I'm going to put here, but probably some collection of recipes, stories, tutorials, or other notes. Maybe one day I'll add tags so people can filter out the garbage they don't care about

How does this blog work?

You may have noticed that I code my own website. This website exists as a combination of self expression and a convenient launchpad to test new technologies and patterns.

I'm currently powering this blog through the Wix headless CMS feature. "What is that?" I hear no one asking. Well I'm going to talk about it anyway. Like when I want to talk about Football with my family, or drumming with my girlfriend, or technology with pretty much anybody. I'm used to talking into the void.

What is a CMS?

CMS stands for content management system. Websites are traditionally developed with a CMS system when they have ✨dynamic content✨. This includes blogs, stores, marketing websites, etc. A CMS provides many functions, but one of the most import functions is to separate "content" from "code". Usually developers create layouts, components, application logic, etc, as code. Then another team will construct content including text, component layouts, populating images, etc, as content.

Then after both these teams do their jobs everything comes together beautifully. Just as everyone imagined it.

Well ok it's not always straightforward, but a CMS does accomplish a pretty important feature. A user who is not a developer can change some content on a website pretty much instantly. Whether that's just updating a spelling mistake or adding a whole new page.

So where exactly is the line between "code" and "content"? Surely that's an extremely important thing to have well defined and there's standards that everyone follows.

It's in your

Traditional CMS Problems

Not only can code be content, but just as often content can also be code (it's usually a bit more difficult to go that direction since the pesky developers like to put in safeguards). So if we can draw the line anywhere maybe we don't actually "need" a full CMS.

Sure the CMS lets you move things around from time to time, but if developers are handling page layouts, and components, and app code how much is the CMS really contributing to the visual experience? In some cases not much.

What's the price though? Well aside from just the content for the website, your CMS is also handling the code. This means developers are writing code that will specifically run on a that particular CMS, which takes away their ability to make certain decisions about the code they write. If you use WordPress you are locked into their PHP implementation, AEM uses a Java, Wix uses their own flavour of JavaScript with Velo.

These systems are not overly portable and more often than not lead to vendor lock in🤮

This can also lead to awkward conversations where the design or content teams would like to implement something a particular way, and the developers have to try to explain that the CMS doesn't really prioritize support for that feature. If they were in more direct control of the application server they could better prioritize the features they know their teams will want for their specific use cases.

What is a Headless CMS

So what if there was a way we could completely separate content from code? Maybe we've got one system where all the content is, and we've got a separate system where all the code is, and they talk somehow, like through APIs and stuff. Then the developers could create a website just how they want to, using the code they're most comfortable with, and content editors can work in a separate system focused entirely on content.

Congratulations you have just described a headless CMS! 🎉

Sure we could have been doing it all along but now it's a buzzword, and oh boy is everybody doing it now. Those guys I mentioned before, WordPress, AEM, Wix, they are all pivoting their traditional CMS systems to include headless support. It's a pretty fair bet that if you've heard of another CMS they are also rapidly investigating headless support.

How you're website engages with a headless CMS is kind of up to the developers. It could just insert text on webpages, define full pages and some logical switches, or if you're a psychopath you could define you're entire site layout, all content, and provide JavaScript code to run all as part of headless CMS API responses. It's also worth noting that since a headless CMS just provides APIs to access content you aren't limited to just websites. Mobile apps for example could also pull their content from a headless CMS.

This is Amazing! I see no Flaws!

Don't worry I'm here to shatter the illusion! Headless CMS systems definitely have flaws and you'll have to weigh them out carefully before deciding on headless vs traditional CMS.

2 > 1

This one is real basic. You now have 2 systems to maintain instead of one and that means increased cost and increased developer workload. Just because a headless CMS focuses on content doesn't mean that developers won't be involved in how that content is defined. They'll have to consume it after all as part of their web server code so they'll need to write additional logic to retrieve the content, correctly display it, and error handling if the CMS fails.

You have also now doubled your odds that your website will be down or is in a degraded state.

No Preview

In a traditional CMS you can hit the "Preview" button to see how your website will probably look after you publish those content changes you just made. Headless CMS systems often do not, and can not, provide a preview mode. By nature they are detached from your actual website and they can't even guess how it will really look after publishing.

Some frameworks are attempting to tackle this problem, but realistically your best bet is to run a separate dev version of your website that consumes content you mark as "draft" or "preproduction". This again put additional dev strain onto the system as they now have to add code that handles environment specific logic for content fetching.

Requires More Technical Skills

Traditional CMS systems are simple enough that regular people can do enough to create a whole website by themselves. That's really impressive considering most regular people's technical skills tend to cap out somewhere between creating a word document and a power point presentation. That's not shade, my own sister created a pretty good web site for her business all by herself. She's a therapist that primarily interacted with a computer to play Sims and do school work.

There is a near 0% chance a regular person is implementing a headless CMS system. For a standard website consisting of some regular content posts, some polls, some forms to submit, a traditional CMS is a very good solution. Headless CMS systems make more sense when you're a big enough business to have developers on payroll, you're delivering a multiplatform application, or you have a specific use case in mind.

I'm what you call a "turbo nerd" so requiring technical skills just adds to the fun😎