What it is ‘Headless WordPress’? Is it something your WordPress based website needs? Is it something you should consider for a new project? Here is an explanation, why this is of significance and whether or not it might be important for your site.
In order to understand why ‘Headless WordPress’ we need to understand what problem it is solving, that gets a bit technical and its roots lie back in the beginnings of the internet.
The limits of PHP and HTML
HTML is not dynamic, it was never designed to be. To change the content requires a new html page to load. With simple text based sites of the early internet this was not a huge problem. As sites got graphically more complcated this entailed entering a lot of repeated code in each file. This became difficult to maintain for large graphically complex sites.
Languages like PHP and the use of a database helped with the repetition of code and to separate your content from your html. It reduced the workload and made things easier to maintain. However it still worked within the limits of a page load. For the web borwser to display new content a page load was always needed.
The rise of Javascript
Javascript was originally developed to add some dynamism to a webpage. It allowed the developer to manipulate the document without a page load. You could press a button and something dynamic could be changed within the page without a page reloading. It was the start of a revolution, however it’s early years were dogged by competing standards and slow and buggy render engines. It also only ran on the client side within the browser and that limited its initial implementation.
The rise of server side Javascript is the game changer for Javascript and for an experience without a pageload. With the rise of various server side implementations of Javascript and speedier rendering it became possible to refresh only the elements of a page without the need for a full page load.
Social media
This was especially important for companies where scalability, performance and ease of deployment were priorities like the developing Social Media websites. Social Media and other companies and individuals were facing these issues but on a massive scale. They couldn’t implement solutions that were appropriate for a smaller websites, they were not scaleable or easily maintained at that scale.
They needed something that was purpose built to be scalable, fast and efficient. These companies developed a number of solutions predominantly using javascript as a foundation and many of them chose to release them as Open Source projects for anyone to use.
React.js, Vue.js and Angular.js are amongst a host of javascript based architectures and frameworks that allow a more ‘app like’ experience, with performance, ease of use and scalability as one or more of their design goals.
A better WordPress?
The demand for performant and scalable websites and online apps has risen driven by user expectation and search engines algorithms requirements, WordPress developers have been looking at these javascript based architectures and frameworks and asking themselves ‘how can we combine them with WordPress?’.
Ideally we’d want the mature user friendly WordPress editing environment and database combined with the efficient, dynamic and scalable front end of one of these frameworks/architectures. This wasn’t easily done as WordPress had a very set way of working and accessing the database.
In 2013 a WordPress REST API project was unveiled that exposed the data of a WordPress website via the commonly used REST architecture using a plugin. This changed everything. Now there was an easy way to match these architectures/frmaeworks with the data in a WordPress site while retaining the user interface. In 2015 the REST API became core to WordPress.
This feature allowed web developers to access the data held in a WordPress website which is unopinionated on the environment within which that data is used.
Headless WordPress
These developments resulted in some developers replacing the WordPress theme based front end with a javascript based front end served in a separate more efficient and performant environment. This is now known as ‘Headless WordPress’.
With this approach you can retain the investment in WordPress, the familiar and famed easy to use editing of WordPress and combine it with a performant and scalable ‘app like’ front end.
Typically however implementation was still difficult in those early days, almost everything had to be either built from scratch in the architecture/framework you were using or involved configuring modules to work to work with it. There were still many problems to overcome and many developers created their own solutions independently.
Only sites that had the resources to support such development used it. It was too costly for the average WordPress to develop and maintain.
Since then purpose built solutions, many inspired by the experiences of those pioneers, is now bringing Headless WordPress solutions into greater viability. It is now much easier to develop and deploy Headless WordPress. There are two main solutions that have reached a level of maturity that almost any developer can implement them.
Gatsby.js and Frontity React Framework. Both of these are Open Source projects and are free to use.
Gatsby vs Frontity
Gatsby and Frontity create a dynamic front end for WordPress usually served from a separate serverless or node.js based environment but retaining the WordPress back end, they are both frameworks built in React.js.
Gatsby is more of a generic solution for any website, which also has a WordPress specific solution supplied for WordPress. It has been around for longer than Frontity. The downside is it still takes a fair degree of configuration to setup and to solve all the WordPress specific problems that need to be resolved. It is mature however and is in greater general use.
Frontity is the new kid on the block. It is built from the ground up for use with WordPress. You can be up and running with a basic Frontity front end within minutes, with only a basic understanding of Javascript and without necessarily having in depth React.js knowhow. This is very impressive.
With Frontity most of the core problems with integrating WordPress with a dynamic library/framework have already been solved for you, and there are multiple downloadable modules to extend that. Frontity has been designed and written to be similar to WordPress so some of the concepts used within it are based on the way WordPress works. Someone who has only started to learn React.js will greatly appreciate this, it just makes the job easier.
The other upside for Frontity is ease of deployment, the Frontity team have been cognisant of the complexity of deployment for these kinds of architectures and have made it as simple as possible.
However a downside is it has a smaller user base and therefore a smaller support base.
Good news on that score is Automatic, the makers and maintainers of WordPress.com and the WooCommerce plugin, have invested in Frontity as they see its great potential so this situation is likely to change.
Overall I prefer Frontity. Its more understandable to me, I already have some React.js knowledge but more crucially for me Frontity is aligned more closely with WordPress, my core speciality. The deployment and setup are also easier. This made the choice a no-brainer.
Who should use Headless WordPress?
Your instinct might be ‘everyone surely’ and to a degree I’d concur. In practice a Headless WordPress setup is almost certainly going to be more costly in most circumstances than a regular WordPress to setup and maintain.
There are also some technical difficulties. Not all WordPress plugins are supported in Frontity and Gatsby. If the Plugin does not expose its data or function in the REST API, then it’s not usable at all without some extra effort.
If the data is exposed and there is a module that supports that Plugin in Gatsby or Frontity you are fine.
If there isn’t then you are on your own having to build custom support for that plugin. At the moment there is precious little support for more than a hand full of plugins. Developing a Frontity or Gatsby based front end with you a site with a lot of plugins is going to be expensive.
So it becomes a cost/value analysis.
Who will beneift from the extra costs and development needed to create, run and maintain a Headless WordPress site?
At the moment high traffic sites that gain their equity from serving a large quantity of users and sites that can benefit from the speed increases or working more like an application than a website are the main kinds of WordPress based sites that will benefit the most from Headless WordPress.
Nothing stays static however. Search engines, new standards and user expectations are continuing to drive changes in website design, standards and architecture.
In the long run all website could need to be dynamic and ‘app like’ in their responsiveness because users and search engines expect and demand it. About 40% of the internet is hosted on WordPress. In which case running Headless WordPress with something like Gatsby or Frontity could become the norm rather than the exception.