Skip to main content

Pros and Cons of Using CMS

Introduction​

In project work / customer projects carried out with NeuroomNet, there are regularly questions about why a CMS or even a Headless CMS is needed and what the advantages of using one are. Therefore in the following sub-chapters:

  • Pros and cons of using CMS in general and
  • Specifically also the advantages of using Headless CMS over non-Headless CMS are presented.

These listed pros and cons are of a general nature and exceptions confirm the rule as the saying goes1.

Pros and Cons of Using CMS in General​

Advantages​

  • Content can be easily changed / maintained / extended (i.e. generally no software developers or programming knowledge, code knowledge required)
  • Content can be changed with low risk (in contrast to changing content by modifying programming code)
  • Content can generally be changed quickly
  • Content can generally be changed with less effort
  • Generally no complex deployments required for content changes (if any at all)
  • Content changes can generally be enabled through specific technical permissions
  • Early use of CMS in the project course can be advantageous for the project course (time, effort, quality) because content changes are easier and can be carried out by people other than the code developers

Disadvantages​

  • Programming code may be somewhat more complex to develop because content is not hardcoded in the programming code but must come from a CMS2

Pros and Cons of Using Headless CMS vs Non-Headless CMS​

In the following two sections, advantages and disadvantages of using Headless CMS compared to non-Headless CMS (i.e. usually specialised CMS) are listed. The focus here is also on rather smaller applications (at most several person-years of development time) rather than large-scale projects (the larger and longer-running a project is, the more worthwhile using a Headless CMS can be).

In addition to the listed pros and cons, which are the most important general ones according to the author's judgement, see especially the following links for more information on comparing Headless CMS with non-Headless CMS:

Advantages​

  • Headless CMS are generally better suited for omni-channel content distribution, i.e. potentially totally different clients use the content (and possibly use / display it in totally different ways), because the data set consists of raw data and not e.g. already assembled websites
  • Easier data maintenance when changing central raw data
    • If e.g. a proper name needs to be changed, this is generally done in a Headless CMS in one or only relatively few places; whereas in a non-Headless CMS the proper name must generally be changed in significantly more places with correspondingly increased effort and error potential
  • Partly significant advantages in the project course (time, effort, quality) when content and software are developed in parallel by different groups of people (e.g. designers and software developers)
  • Significantly more flexibility than with non-Headless CMS: In non-Headless CMS a lot is usually predefined (possibly via a kind of modular concept) and it is difficult or impossible to deviate from it

Disadvantages​

  • Significantly increased development efforts for the clients of the CMS (if there is a well-fitting non-Headless CMS)

    • Effectively every client must be developed individually, while client development with a non-Headless CMS is generally significantly less complex due to a kind of template-based development
    • So if a specialised, non-Headless CMS sufficiently fulfils the requirements of all clients (i.e. all essential requirements are met; especially if there is only exactly one type of client, i.e. no omni-channel scenario exists), then these are generally significantly faster to develop with the non-Headless CMS
      • Example: If you want an online shop on the internet, it is generally significantly cheaper to use an E-Commerce CMS than to use a Headless CMS and program the shop website yourself
      • Example: If you want to display the same website on multiple exhibits and this works with WordPress etc., then this is generally significantly cheaper to develop than developing the website in HTML and retrieving content from the CMS via API

  • Managing the data in the Headless CMS is possibly somewhat more complex than with non-Headless CMS

    • Examples
      • With non-Headless CMS (if there is a suitable one), data can often be maintained via WYSIWYG forms (you may even click together a whole website). With Headless CMS you generally need to know which data you need to change (i.e. you need to know, for example, I need to change the image in the data record "overview-application.frontpage.titlepicture" and only then see the change in the corresponding client).
      • Specialised non-Headless CMS often have good usability specifically for the application; changing prices in an E-Commerce CMS will for example generally be much easier with automatic calculations etc. than in a Headless CMS

Conclusion​

In principle, the use of CMS is worthwhile when it is foreseeable that there will be, especially regular or more frequent, content changes after launch / basic completion of a software.

Headless CMS or Non-Headless CMS?​

Effectively, if there is a well-fitting non-Headless CMS for your own scenario / project / requirements (i.e. all essential requirements are met; especially usually when there is exactly one type of client, i.e. no omni-channel scenario exists), then a non-Headless CMS is significantly more cost-effective and therefore recommended. These are then usually specialised CMS for your own scenario / project / requirements.

Otherwise, a Headless CMS is generally recommended (or possibly also hybrid variants).

Footnotes​

  1. For example, many WCMS, possibly with plugins, can now also store raw data and make it available to clients via API, as Headless CMS do. Likewise, in Headless CMS you can also store complete (but rather static) websites as raw data and clients can display these 1:1. ↩

  2. With a suitable, specialised, non-Headless CMS, however, the programming code can also be significantly simpler or no longer necessary at all. ↩