In the early days, when The Web was young, content was mostly static HTML pages.
This meant that your website content could not be easily updated or changed and was limited by what your webmaster could create, or dependent on the scheduling of resources.
However, with the rise of social media platforms like MySpace, Facebook and YouTube, web content generation began to move towards a more prosuming culture. Where the content consumers became the producers.
The Dawn of the Interactive Internet
This is the era, when the prosumer truly came of age, users were granted the power to create and share their own content, rather than just consuming what was created by others.
This shift was made possible by new approaches, such as CMS (content management systems) like Joomla, WordPress or Drupal and WYSIWYG (what you see is what you get) editors. These technologies made it easy for users to create and edit their own content, without having to know any HTML or have any programming skills.
As a direct result, the web became a more dynamic and interactive space, where users could share their thoughts, ideas, and experiences with the wider world. This led to a more democratised and participatory web, where everyone has the opportunity to be a content creator.
Key milestones in the web’s evolution since the days of static HTML:
- The shift from text-based to multimedia: Early web pages were mostly HTML or text-based. However, modern web pages can incorporate a variety of multimedia elements, such as images, videos, and audio. This makes web pages more visually appealing and engaging.
- Static to dynamic content: Web pages were static, meaning that they could not be updated or changed. Dynamic web pages, on the other hand, could be populated in real time (or tailored to the end user), without the need to create explicit content. This was made possible by technologies such as PHP, ASP and Java.
- Partial reloading and dynamic injection: The next step of the journey was dynamic fragments or sections web pages. Content blocks that could be updated in real time without the need to reload the entire page. This was made possible predominantly by JavaScript.
- From one-way to interactive: Web pages were mostly one-way, meaning that users could only consume content. Modern web pages became increasingly interactive, allowing users to participate in a variety of ways such as commenting, liking, sharing or generally giving feedback and input.
- From professional to prosumer: Web content was mostly created by professionals. In modern times web content is increasingly created by prosumers, or consumers who also produce content (or content managers and copywriters creating SEO’d content). This is made possible by the development of new technologies that make it easier for anyone to create and publish content.
- From man to machine: The more recent maturation of AI technologies, specifically LLMs, and automation pipelines brings with it a new generation of the web. The full impact of this technology remains to be seen.
The evolution of web content creation has been driven forward by a number of factors. Emerging technologies, connectivity speeds, frequency of use, smartphones, wearables, the rise of social media and the changing needs of end users.
As the web continues to evolve, in line with the way we use it, we can only expect to see even more innovative, engaging and immersive forms of web content.
The Future of WordPress
WordPress is by far the most popular content management system (CMS) in the world, currently taking credit for running 43% of the web, a figure which has been growing consistently year on year.
Since the core WordPress team started working on the Gutenberg project, development has been moving away from traditional PHP based architecture, on the front-end at least, and towards JavaScript based themes and an editor that integrates seamlessly with the WordPress REST API.
Headless-WordPress as an architecture methodology first got my attention back in 2019. At that time the REST API had been around for a few years (released as part of core in version 4.7 in December 2016) but the adoption and implementation as a backend API server was still a new concept.
APIs by nature are designed to support a range of applications, so anything can be built on WordPress, transforming it from a content management system to an application platform.
When I first started learning React and Isomorphic JavaScript I played with a few frameworks that could generate websites from the WordPress API, Gatsby been one of these. That didn’t really sit right, to me this was no better than caching the pages generated with good old PHP. A framework that supports both server side rendering (SSR) and client side rendering (CSR) seemed more appealing.
At that time Frontity was the most promising framework for developing Headless WordPress websites. However, after working with other systems throughout the pandemic I found that Frontity Framework was no longer under active development when returning to my explorations.
In 2021 Fronity was acquired by Automattic (the parent company of WordPress.com, WooCommerce, Jetpack, Tumblr) and the core team are now working on the WordPress Interactivity API, planned to unlock the same type of UX as the Frontity framework whilst also addressing compatibility with the new Full Site Editor experience.
Having acquired the company, WordPress was reported to be reaching a turning point in its history.
Post-acquisition, the ex-Frontity team’s main focus was to improve WordPress and its full site editing developer experience. Even though Frontity was a React framework, they would not be attempting to add a React frontend to WordPress, rather to improve the WordPress website building experience, looking to further develop Gutenberg and the Full Site Editing functionality.
However, the larger goal of WordPress to be more accessible as a platform doesn’t meet all needs so it’s not always the best choice for every project.
The Benefits of Headless WordPress
Whilst Full Site Editing and Gutenberg Blocks are fantastic, giving designers and content managers infinitely more power to customise layout and styling, as both I designer and developer I often find myself thinking “I could do this quicker with CCS/PHP or React” rather than selecting margins, padding, colours fonts etc. via the UI for every bit of content.
For many of my use cases the majority of the design and functionality is done prior to handing over the final product. Some clients never update content, many only want to publish a few blog posts.
Headless WordPress is a CMS architecture that decouples the client side content from the back-end management system, you continue use WordPress to manage your content, but have the freedom use any technology you want to display that content.
If you do want to create websites or applications with a custom front-end, or if you want to publish your content on multiple platforms, then Headless WordPress is the way to go.
The benefits to using WordPress as a Headless CMS are numerous;
It gives developers more flexibility in terms of the front-end presentation, you are free use any framework or library you want to create a truly custom experience for your users.
Headless WordPress can help you greatly improve the performance of your website or app by serving content via the REST API from the WordPress back-end, you remove much of the costly front-end load.
You can also further reduce the number of requests that need to be made to the server by enabling the GraphQL API, which can lead to even faster page load times.
Tried and tested core features. No effort needed to build database functionality for users, permissions etc.
Extensibility. While originally a blogging platform WordPress has matured and can easily be extended in any direction to be a website, a directory, a shop, a booking platform
The headless WordPress approach can make it easier to publish your content on multiple platforms. You can use the WordPress API to deliver your content to any device or platform, including web, mobile apps, wearables, and IoT devices.
Approaches to Headless WordPress Today
From looking at the code Faust.js has absorbed much of the Frontity framework, rebranded it and trademarked it as their own commercial venture. I had a quick play with this but found it already needs updating in places, doesn’t have the same community support Frontity did and it’s style system is Sass based. Whilst there’s nothing wrong with Sass, I currently have more of an interest in using native CCS Vars or CSS-IN-JS when working with React.
Ionic, of course is another popular(ish) open source way to produce hybrid, cross-platform Angular, React or Vue based applications from a single code base. However it’s more of a mobile UI toolkit and much of the rapid development infrastructure and file generation is an extrapolation of the Angular CLI.
The most promising solution I came across was a Next.js starter template for ISR and WordPress. Whilst Next.js is a web framework you can add capacitor to a Next.js project to make it cross-platform, much like Ionic.
In my next post I’ll provide some tips and recommendations on how to get started with WordPress and how to set up WordPress as a Headless CMS.
I’ll also show you how to:
- Choose the right front-end technology
- Set up your own WordPress site and configure the WordPress API
- Run your Headless WordPress client on your local machine
Whether you’re a budding developer, a curious content manager or a person with a project read on to learn more about how headless WordPress can help you create amazing websites 👉
