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.
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 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.
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.
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.
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.
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….
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.
You can match the SSG to the tastes and workflows of your development team or client. And work in ways that suit you.
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.
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 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.
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.