In the second post in our Evaluating Your Tech Stack series (see the first post here on online video platforms), we’re taking a hard look at content management systems (CMS).
Choosing a content management system is kind of a big deal. It’s a choice that has a lasting legacy for any company, and migrating from an existing system to a new one is complicated at best. Given the multitude of options available, it’s interesting to me that most people default to “something like Wordpress”, which usually means actually Wordpress. And while Wordpress has its place, it’s hardly a one size fits all solution.
The core problem with making this very important choice is just that: there isn’t a one size fits all CMS. Sorry. That’s not what this article will tell you, but I can narrow it down to a few categories that will help you decide.
A Bit of Lingo Before We Continue
We talk about “headless CMS” options below, and if you’re unfamiliar with that phrase, it means that your CMS serves up data via APIs so that people can build custom experiences with it. Many content management systems are also website builders as well, but that’s proven to be a substandard experience, both for the creator and the end user of the site. As browser technology evolves, so should your website/product, and when you’re anchored to a Wordpress theme, you’re missing out on much more interactive ways to engage with your customers. A headless CMS solves that problem. More on these later.
Content vs. Data
Before you can make a decision, you have to first think about what you’re using this CMS for. Is it for blog posts only? Is it to keep a list of products for an e-commerce site? If you need to relate your data together in rich and interesting ways, that rules out a lot of choices.
For example, you might have a cooking site with a lot of recipes. If you write a recipe post in a typical WYSIWYG style content editor (just picture any blogging platform you may have used), you don’t have data: you have content. There’s no good/easy way to do interesting things with content like that. Here’s a screenshot of some data coming back from Drupal being used as a headless CMS:
Here you can see that the “body -> processed” text is a bunch of markup with classes already attached (bad practice). How would you get the title of the product from there? How about the product image? It’s doable, but that kind of coding is akin to trying to pick a bunch of needles out of a haystack.
The second value here, “field_product_description” was a headless CMS content type that’s simply a text field: no markup allowed. It’s an isolated field of data we can now use on a page wherever we want to place it, and styled however we want.
If you wanted to be able to create filtering and sorting options so you could only find recipes that include a slow cooker, chicken and low-calorie, that’s suddenly a very difficult problem to solve when you only have content. But if you have data, you can relate it, and you can access it. However, this usually comes at a cost of the content editing experience, which I’ll cover more later under the headless CMS options. But this is a nice segue to the most important question...
Who Will Use Your CMS?
Most of the time, the answer to this question is “many people from different audiences.” You might have a marketing team using the system, or perhaps it’s strictly for back-of-office stuff and it’s mostly developers using it. This question exacerbates the “one size fits all” problem I keep mentioning, because as you can see, most teams need a solution that’s “one size fits most.” I’ll explain the ideal audience for the options below, and hopefully it will help you land on the right fit.
Now, for my picks...
Low Code/No Code
Squarespace, Wix, Unstack, Webflow, Bubble
Generally speaking, there’s a lot of movement in this category. Not every company has a team of developers around to take on frequent updates and changes. This section of this article will probably be very outdated in a couple of years.
There are some standouts you may have heard of already, such as Squarespace and Wix. In my experience, Wix is the better option. Squarespace has been around for a long time, but they’ve been pushing into the crowded e-commerce space lately. If you need an e-commerce solution, Shopify should be your first look, but that’s a different article. Wix has a fantastic engineering team and they are always coming up with interesting new features.
But if you think you’ll have a website that will grow far beyond a typical “5-pager”, then you need something better suited to that world. Unstack, Webflow and Bubble should be on your radar.
Unstack is relatively new to the market, but has some very cool tools around lead generation. If you’re using your site to convert sales, please get a demo from these folks. This tiny little screenshot on this page does not do justice to the power of this feature that comes out of the box with this relatively cheap platform. I’m personally excited to watch them evolve in the years to come.
Unstack’s philosophy is centered around the style guide. You can define the core elements in a literal style guide editor. What’s extra thoughtful is the “custom script” feature you get in their higher tiered pricing. This allows you to add literally any javascript you want to the page, which can basically let you achieve anything if you have a javascript developer around.
Webflow focuses more on the design side: creating “symbols” (aka components) that can be reused in any page layout. Bubble is more complex, so if you need something like Webflow but want a lot more control, check out their product, but be prepared for a steeper learning curve. Each of these services deserves a thorough test. If you don’t have a team of developers around to help implement changes, this category is for you. There are other options beyond this trio, and if you find a great alternative please let us know 🤓
The Elephants In The Room
Wordpress, Drupal
Let’s face it: Wordpress is everywhere. A common statistic floating around is that Wordpress powers approximately 35% of the internet. Drupal, by comparison, powers approximately 2% of the internet, which is still a respectable number. Both of these solutions gained popularity by being free and open source, which is great… until something breaks or goes wrong and you have no one to call. These two solutions, like any open source solution, mean that you need at least one developer around to help out.
Both Drupal and Wordpress are grouped together here because they are a content-focused CMS first and foremost. Wordpress 5’s new Gutenberg editor is a major upgrade, and is a state of the art WYSIWYG editor. They try very hard to be a solution that can work for anyone via third party plugins. This can add some handy features, but it also adds bloat and performance problems. Couple that with needing to upgrade the underlying platform alongside your plugins and it can become a complicated mess. It’s gotten better over the years, and services like Pantheon (git-based approach much like Heroku) make it more manageable. But at some point, you’ll have a behemoth on your hands so tangled you’ll probably have to abandon it.
If you have a technical team dedicated to upgrading and maintaining your CMS, then these are actually compelling options. You can customize them to your heart’s content but keep in mind that you’ll have a very custom implementation of an off-the-shelf product.
You can make Wordpress and Drupal headless CMSes as well. Wordpress supports a JSON REST API, and packages like WPGraphQL are evolving daily. I’ve used both as a headless CMS, and the features you get from Drupal make that the clear winner if you’re fixated on using one of these two platforms. If you want to set that up with Drupal, this video is a huge timesaver.
Headless CMSes
Strapi, Contentful, Sanity, Takeshape
I wanted to save the best stuff for last. You can tell this is a relatively new breed of CMS just by the URLs: they almost always end with a .io with the exception of Contentful. As mentioned above, a headless CMS is what you probably want/need if you’re looking for something more structured than just a big blob of HTML from a content editor. All these platforms share a core concept: content types. From basic elements, you create richer content types that make sense for your use case. This is best shown with an example:
Here, a product page is built from other elements provided by Strapi, as well as content types created by us (such as CtaContentStacked and Card components). When it comes time to use those content types (in this example, creating a “Product Page”), the editing experience reflects the structure you’ve created.
It brings a low-code/no-code vibe to something that is normally very developer-centric. The exact structure can be created right in the browser so that you can relate and link data together in whatever ways needed.
All of these options support REST and GraphQL APIs so you can fetch data however you’d like. This is essentially the “A” portion of the “JAM Stack”, which stands for Javascript, APIs and Markup, and it fits that role quite nicely.
It’s worth mentioning again that these tools don’t handle the website builder/layout problem. You’ll still need developers to build something that will actually fetch and use that data, and that’s the Javascript and Markup side of the acronym.
Strapi is the only one in this list that’s a bit different from the other. Strapi is an open source project, so you won’t get any support aside from the community. But, it’s free, straightforward to setup and use, and it’s built with React and customizable. We’ve seen a lot of customers perk up at Strapi, and it’s easy to see why. However, you will need people at least familiar with Git. You can only create new content types locally, and that’s by design: they make model changes to the database, and when you do that locally, you version control those changes. So don’t expect to hand this off to non-technical folks who need the ability to create new content types. They’ve been preparing for their 3.0 release for a long time now and it shows: the documentation is very good. You won’t get cool features like staging APIs, image resizing on the fly, or a support person to call like the rest of the options, but Strapi has its place as we’ve seen.
Contentful is the leader in this space at the moment. Their user interface is very good, they have support people you can pick up the phone and call, and their service is incredibly fast. Data fetches come back so fast that sometimes I have to check my eyes. However, their pricing is weird and all over the place. They do per user/month pricing like many services nowadays, but they also have pricing tiers based on the number of content types you plan to use. And since this is at the very core of what makes a headless CMS, this is a restriction you should pay attention to. Since you make basic building blocks and use that to create bigger data structures, you go through your content types allotment quickly. Their highest tier before you get into the enterprise level gives you only 48 content types. Okay… I’ve warned you. I feel better.
Sanity.io is another big player, but taking a very developer-first approach. Their Sanity Studio is open source and built on React, which is much like Strapi’s approach. To be honest, I haven’t had a chance to properly sink my teeth into Sanity, but some colleagues have, and they love it. They’re always pushing out new features too. You see Sanity get mentioned a lot in conjunction with GatsbyJS, and that’s because developers love both of those things.
Takeshape is newer to the market, but they’re taking an interesting approach. They’re going after integrations. They call it their “mesh” feature. Shopify is one of the companies they integrate with, so we’ll use that for an example. Takeshape is also a CMS just like the others here, built on content types. So maybe you track warehouse inventory with Takeshape, and you need to know how many orders for a t-shirt came in during the last 8 hours. Well… thanks to that mesh feature, fetching all that data with one API request is possible. Instead of having to set up all those integrations at the code level, it can be done at the CMS-level, which makes complete and total sense. The CMS is almost always the “single source of truth” when it comes to data, and Takeshape is making it easier to link to the other systems you’ll inevitably rely on as well.
This category is so huge that I’m definitely doing a disservice to many companies doing great work. I simply just can’t explore them all. I encourage you to check out different services to see what unique features they might be able to offer you.
Honorable Mentions
KeystoneJS, Slicemachine
These are cool solutions, but would probably terrify most enterprise customers. KeystoneJS is a code-first model where you build your content-types in code, and create the admin UI for your CMS the way you want to. A lot of people rave about it, and I get it: it’s compelling if you can sling code.
Slicemachine is super cool, and definitely on the right path for the future. It was just announced and is in beta right now (built on Vue/Nuxt). The core of this project is “What if the library of front end components was the thing you edit in the CMS?” As their tagline says, “Devs make the parts, users make the websites.” This is a really interesting solution if you want to have a website builder-like tool but want to be able to customize it. Not for the faint of heart, as it’s in beta and built on evolving technologies. But as perhaps the world’s biggest Nuxt fan, I’m personally excited to see how this project evolves.
Finally… We’re Done
That was a lot, dear reader, I know. If you’ve made it here, just know I’m somewhere slow clapping for you. The world of content management systems is huge and complex. I hope the slice of that world we walked through today will help you make a more informed decision. That decision will have a lasting impact for your company, so choose wisely!
