Deciding Between Headless and Traditional Content Management Systems

When managing dynamic content is a project requirement, your team has a choice between traditional content management systems (CMS) or “headless” CMS solutions:

• Traditional CMS platforms (Drupal, WordPress, etc.) are characterized by out-of-the-box WYSIWYG editors and visual themes that can be adopted for many common applications.
• A CMS is “headless” if it only delivers content data directly (no user interface is included). In a headless CMS, content data is delivered via a web API using software development kits (SDKs) that are integrated into a custom application.

In this post, I’ll cover some key considerations when making the decision between traditional and headless options.

Advantages of a Traditional CMS

Before digging into reasons to choose a headless CMS, let’s briefly review some of the main features a traditional CMS offers.

1. With a traditional CMS, there’s a lower technical barrier to entry. If your team lacks developers, it’s not a good idea to choose a headless CMS. Traditional CMS options (like WordPress) offer easy-to-use WYSIWYG editors and tutorials explaining how to use the system to implement common site functionality like blogs, eCommerce sites, etc.
2. Using a CMS with an off-the-shelf theme can reduce the time to market.
3. If the content is the experience (as it is with a blog like this one), going the traditional route makes a lot of sense. Atomic Spin uses WordPress.
4. You can find many themes for common use cases on sites like WooCommerce and ThemeForest. A theme’s visual design can be tweaked to match brand guidelines for a desired look and feel.

Advantages of a Headless CMS

The key difference between headless and traditional CMS options is that headless CMS only provides data–no user interface or visual themes. A headless CMS allows a team to define content using a provided web-based user interface, then expose it through a RESTful web API, usually with SDKs.

So, what are some of the advantages of choosing a headless CMS?

Cross-Platform Support

Headless CMS solutions deliver data that can be used by almost any client. Unlike traditional CMS platforms, there’s no view layer. We used Contentful on a recent project. Its SDK currently supports eight languages.

Language flexibility allows the team to make the best technology choices for their domain and application. This feature is especially critical when developing a product that has native mobile and web clients.

Decoupling the Data Model from the View

At Atomic, we work on complex custom projects whose user interface requirements usually cannot be met by a traditional CMS. With a headless CMS, the data model is decoupled from the view layer. If having a custom UI is of utmost important to product success, you’ll need fine-grained control over the view, so a headless CMS is a good choice.

Platform Independence

Using a headless CMS can make it easier to switch CMS platforms. In fact, it is possible to abstract away all CMS interaction from the client side by routing content traffic through an intermediate server. With this approach, changing a CMS provider only requires updating the server-side CMS implementation code, not all the clients that consume it.

While it is possible to transition between traditional CMS services, the process is often very painful.

Developers First

Since choosing a headless solution requires a high degree of technical know-how, headless services are very developer-friendly. We’ve had a great experience with Contentful’s documentation, webhooks, and import/export support.

Avoid the Traditional Plugin Apocalypse

Choosing a custom CMS empowers the team to use client-side packages or develop custom UI elements. Large sites using traditional CMS grow organically over time, and they invariably pick up many different plugins.

Patching and updating those plugins is not always possible, and it can expose the site to security vulnerabilities (just look at this list of vulnerable WordPress plugins). You’ll still have to put in some effort cleaning up technical debt and following good code practices, but the team is in the driver’s seat.

Conclusion

Of the above considerations, the most important are:

1. Product requirements
2. Technical ability of the team
3. Platform support needs

The decision to go headless (or not) is important. I hope these thoughts will help your team match the appropriate type of CMS to each project.