How to Replace Your Rapidly Aging Monolithic CMS

Background

When a user tries to access a web page, their browser requests the server that hosts it. Either the server answers the page immediately, precisely as it is stored, or generates it by executing code on demand. Although the Web is an entanglement of static files, server-side programming languages appeared very early and are now widely used.

More than 80% of servers that use server-side language are running PHP. And hosting providers offering servers without dynamic language support are almost non-existent. Yet, the dynamic generation of HTTP responses presents significant disadvantages in terms of web performance.

A dynamic webpage is often built around a web server that loads an execution language that analyzes the HTTP request, often requests a database, and third-party services populate a logical model that reveals itself through an aggregate of templates to generate the HTML response. Quite logically so, the response time is longer.

A paradigm shift

If you want to deliver your static pages, you must have compiled them upfront. This fact, as trivial as it may seem, changes everything. Indeed, compilation turns out to be the main advantage of static: shift the production environment's complexity to the integration process. If a web server serves your pages without being generated first, you do not need a server-side language to be executed.

As a consequence, many attack vectors disappear. You can't steal confidential data by injecting malicious code if you have neither a database nor a server-side execution language. The static trend allows you to transform the way a site is published ultimately.

Monolithic CMS have major compatibility issues, especially with the release of PHP8

Monolithic CMS platforms have prided themselves on being backward compatible with major releases of the most used server-side language, namely PHP.

With PHP 8 newly released, this will become extremely challenging, if not wholly impossible. PHP 8 is going to contain many breaking changes. Those mainly have to do with warnings becoming errors and many strict type-related errors introduced. A rather high portion of these changes can only be detected on runtime.

Fixing these compatibility issues is a significant task. It would help if you used different strategies, ranging from static analysis to automated testing. The proper testing tools are required. For projects like WordPress, which need to support a range of PHP versions, many extra complexities are introduced in juggling different versions of the analysis tools.

This becomes increasingly hard, partly due to the syntactic and runtime differences between PHP 5.x and 8.x being so incredibly big. This is not to argue whether supporting PHP versions that far back is a good idea or not; the conclusion is, it becomes increasingly hard to do so.

We've also looked at the problem of coverage and WordPress's PHP dependencies. High test coverage is necessary to detect compatibility reliably. It is even more critical with PHP 8, where there are many more compatibility issues than usual, and a lot of them can only be detected on runtime.

In that sense, it's hard to say what WordPress's core compatibility with PHP 8 truly is since test coverage is low and virtually absent for dependencies. WordPress is never run as a stand-alone product but always accompanied by a theme and some plugins.

WordPress's extensibility has been a large factor in its success and poses it hard to overcome extra challenges in terms of compatibility. WordPress isn't the only legacy codebase out there and not the only project aiming to support a wide range of PHP versions.

The answer is the Jamstack and headless CMS

We have seen the content management space undergo the initial phases of a significant shift in recent years. Many brands are pondering a move away from their traditional CMS platform to a headless CMS. In addition to this growing interest in going headless, we are also seeing a new trend emerging in web development with the rising popularity of JAMstack, a new kind of technology stack which is different from LAMP, MEAN, and .NET.

What is needed to adopt the Jamstack?

Find a Suitable Static Site Generator

Years ago, we saw a move away from creating large numbers of individual files by hand to a system where repeated code sections are included and repeated more easily. Web servers would perform that task on demand whenever a request for a resource was received.

They'd faithfully combine templates and content, apply loops and logic, and return a page view whenever one was requested. And we'd have to ensure that they had enough horsepower to keep up with demand, fearing the times that our site became popular!

Static site generators (SSG) do much the same thing. They apply data and content to templates and generate a view of a page that can be served to a site's visitors.

The most significant difference between a static site generator and a traditional web application stack is that instead of waiting until a page is requested, a static site generator does this in advance so that the view is ready to serve ahead of time. And it does so for every possible view of a site at build time.

This has several practical effects, but most important is that it shifts this work away from "request time" (when users ask for the view) to "build time," which is unrelated to when users ask for the view of a page. This "decoupled" architecture breaks the relationship between the number of visits to a site and the overhead of generating those visits' views.

How to find the best static site generator

When looking for the best static site generator for you and your next project, there are several key considerations. Let's look at 3 of the most important ones.

1. What are you building?

At the heart of choosing the right tool is considering the job you need to do with it. Ensuring the site generator's output delivers the best possible experience for your site's users is essential to consider.

Are you building….

• A site whose primary function is to deliver content? If so, a tool in which priorities are generating pages and URLs while giving you straightforward control over exactly what is output might be your best choice. Tools like Jekyll, Hugo, Nuxt, and Eleventy do this very well indeed.
• A site with a more complex application-like function? Some sites are less about "viewing" and more about "doing". And while most SSGs can be used as the basis for a web application, others come with more advanced, client-side features ready-to-go. GatsbyJS, NextJS, and SapperJS might provide some useful capabilities.
• A large site with many thousands of pages? Static site generators are achieving faster and faster build speeds. But that can still take a little time. If you have very many pages to generate, you'll need to consider this. Some tools have incredibly impressive generation times. Gatsby is particularly remarkable, as is Eleventy.

2. How are you building?

Following what you are building, perhaps the next most important consideration is how you hope to develop. Ensuring an effective and efficient development experience can have a significant influence on success.

What languages and frameworks suit your development team? There are SSGs build using anything from Ada to Vue. (I'm sorry, I couldn't find any based on languages beginning with the letters W-Z. If you know of one, perhaps you'd add it to StaticGen and let me know!)

If your team specializes in .net, they can still work with static generators and benefit from the advantages described above without moving from their familiar development ecosystem. They don't need to learn a whole new language.

Then again, if they prefer JavaScript, many SSGs might suit them. Some variants employ different JavaScript frameworks such as React, Vue, Angular, or perhaps vanilla, framework-less JavaScript.

You can match the SSG to the tastes and workflows of your development team or client. And work in ways that suit you.

3. How complex are your templating needs?

The type of variety and complexity in the site you are creating could influence the templating tools you'll want at your disposal.

Most SSGs give some code re-use concept with things like partials, including macros. But you might want to go deeper.

Frameworks such as Vue and React afford used component models that logically capture visual style, content, behavior, and functionality. So if your project is more of an application than a site (a "doing" site than a "viewing" site), then perhaps choosing an SSG based on one of those frameworks would be advantageous.

Does your team or client already have particular skills and preferences for an existing templating language? Continuing to support that capability might be to your advantage.

Whatever tool you choose, remember that the needs of the users of the site are paramount. Find a development workflow and toolset that enables you to be productive and generate the sites that best serve your users' needs.

Look for a Headless CMS

For your CMS to be JAMstack-ready, it has to be compatible with JavaScript. A headless CMS decouples the backend, which stores all the content, databases and files, from the front-end. Typically, a headless CMS uses APIs, through which content can be pushed and pulled between various platforms and devices.

Additionally, a headless CMS is front-end framework agnostic, making it compatible with Javascript frameworks like Angular.js and React. APIs give other applications easy access to your content, including landing pages, microsites, or native iOS and Android applications.

For this reason, having a JAMstack-ready CMS that is framework agnostic will allow your developers to utilize their preferred JavaScript framework. Besides, a framework-agnostic CMS also will enable developers to use well-known static site generators (SSG) like Gatsby and Next.js to generate a structure of static HTML files.

Sharpen Your JavaScript and API Skills

For brands looking to move over, the JAMstack brands need to ensure their web development team is well-versed in JavaScript and are also familiar with APIs. With JAMstack, remember that we're talking about front-end-centric development here. If you're new to web development in general, you'll want to make sure to sharpen your JavaScript skills. Learning as much as you can about APIs will allow you to push your projects to the next level.

Business Case for Nextjs and Strapi Headless CMS as replacements for your aging CMS.

Why Next.js?

• Based on React and relatively easy to learn
• That's it. If you've written any React at all, you will find yourself at home with Next.js. It offers you advanced tools and robust API support, but it doesn't force you to use them.
• Built-in CSS support.
• Writing CSS in component-driven frameworks comes with a sacrosanct need for the "cascade." It's why you have CSS-in-JS tools, but Next.js comes out of the box with its offering — styled-jsx, and also supports a bevy of styling methodologies.
• Automatic TypeScript support.
• If you like to code in TypeScript, you have automatic support for TypeScript configuration and compilation with Next.js.
• Multiple data fetching techniques.
• It supports SSG and/or SSR. You can choose to use one or the other or both.
• File-system routing.
• To navigate between one page to another is supported through the file-system of your app. You do not need any unique library to handle routing.
• Image optimization: The Automatic Image Optimization allows for resizing, optimizing, and serving images in modern formats like WebP. This avoids shipping large images to devices with a smaller viewport.
• Analytics: Analytics provides your Real Experience Score through data from actual visitors. Adopt a performance-focused workflow and leave manual and synthetic tests behind.
• Internationalization: built-in support for internationalized (i18n) routing. You can provide a list of locales, the default locale, domain-specific locales, and Next.js will automatically handle the routing.

What makes Strapi different from a CMS such as WordPress

With more than 700K downloads, 20K stars, and 300 individuals contributors, Strapi is the most flexible open-source Headless Content Management System (CMS). It gives developers the freedom to use their favorite tools and frameworks while helping editors to manage their content and distribute anywhere efficiently.

Traditional or Decoupled CMS?

Traditional CMS, such as WordPress or Drupal, are monolithic systems that include the backend UI, plugins, front-end templates, CSS, a web server, and a database. They tend to be slower, heavier, and require a lot of custom development to become responsive to various display devices. In recent years, traditional CMSs have evolved to overcome these challenges and are often calling themselves Headless, although most of them are Decoupled.

According to Dean Barker, the author of the Web Content Management Book, the difference between Decoupled and Headless is the following:

A decoupled CMS is proactive — it prepares content for presentation and pushes it into a delivery environment. A headless CMS is reactive — it manages content, then just sits and waits for some process to ask for it.

As a headless CMS, Strapi provides backend functionalities for websites and apps built with the JAMstack (JavaScript, APIs, and prerendered Markup, served without web servers). Strapi supports most databases, both REST and graphQL API, and is designed to work with the most popular front-end frameworks, including Gatsby, Nuxt, Next.js, or another static site generator. Our main objective is to become the most flexible and extensible headless CMS on the market.

Jamstack and Headless CMS – opportunities and risks

The most significant risk is to get lost in the plethora of Headless CMS, generators, and service platforms. Those risks are greatly diminished when using WebriQ GLUE; a set of top of the line Jamstack tools, glued together for you, supported and serviced throughout the lifetime of your website and web application. Once you have fully grasped the specific risks and put in place appropriate workflows, JAMStack websites nonetheless present a tremendous opportunity for aging CMS systems and aging workflows.