This post was contributed by Emily Miller. A native Hoosier, Emily now lives in San Francisco, CA, and is a content specialist at hosting platform Pantheon. She enjoys exploring the great outdoors with her dog and researching the latest trends in open source.
WordPress developers are getting serious about developing flexible, powerful websites of all sizes. One trend, started as a way to break free of the constraints of traditional WordPress theming, is using a decoupled architecture to customize the frontend.
There are certainly pros and cons to this method, and this post aims to examine the various reasons why some frontend developers are implementing a headless WordPress.
What Is Decoupled WordPress?
Decoupled WordPress is the separation of the backend from the frontend. WordPress is traditionally monolithic, giving you the dashboard, plugins and themes all-in-one. Many developers have been playing around with decoupled builds lately with the primary motivation of creating a better user experience.
In these cases, decoupling allows WordPress to do what it does best, content organization and editing while avoiding a lot of the complex custom code that goes into developing for a set CMS.
Why Are Developers Adopting It for the Frontend?
Translating modern design into a tightly coupled CMS can be tricky, so separating the UX layer of a site allows developers to leverage the tools they want, making the frontend truly agile and the end-user experience more friendly.
For the right use case it’s a win-win situation. Use the best tools for frontend development, while making the WordPress authoring experience even better to empower everyone! Quite a few developers have mentioned that decoupled projects renew their love for a chosen CMS, and that the flexibility makes it fun to work with again.
Another benefit of a decoupled architecture is the upgrade process. A headless build simplifies future updates by not requiring a CMS upgrade, ultimately saving a great deal of time and money come redesign. Frontend developers can now work at their own pace, independent of the CMS’s timeline, and focus on the best language for the task at hand.
A good case study of a decoupled WordPress build is Pixo Tech’s project with the University of Illinois. They chose the best frontend tools for the job, understanding that frontend developers and CMS developers are not necessarily one in the same. For the nitty-gritty of the project, check out this webinar.
What’s the Catch?
As mentioned above, although a decoupled architecture may sound like that captivating and challenging project we’ve all been waiting for, it still has its pitfalls and is probably not the route for every project.
Decoupling WordPress is a more customized, complex build that could mean more time and money up front, although cost-effective in the long run. It also means losing the content previews, easy string translations and UI oriented plugins and themes we’re used to in a coupled architecture.
Additionally, decoupled WordPress is still a young concept, and best practices are still emerging. There’s no set way to do it, and you certainly won’t find a how-to tailored to your specific needs.
How Would You Approach a Decoupled Build?
The WP REST API is a great way to facilitate a decoupled build—you can download it and then decide how much of your site you want to separate. Integrated into core and available to all WordPress users, the plugin provides an easy-to-use REST API, available via HTTP.
This gives developers a great deal of flexibility for creating applications that use a WordPress backend and brings WordPress one step closer to being a complete application framework.
Decoupled CMS is still a new concept, and as a community it is important to share our methods and what we learn as we continue to experiment with such projects, ultimately standardizing on best practices for the future.The possibilities for decoupled are endless, and it’s up to the open-source community to lead the charge and document what we learn.
Decoupled WordPress is a great use of the REST API, particularly when it comes to using a JS framework. The REST APi really does give you the ability to take data from WordPress, put it into a bucket, and then do whatever it is you want with that data (thanks @mor10 for that analogy).
The best part of this, is once people realize that you can decouple your web application (or website) from WordPress almost completely, they will start to think about what else can be decoupled (maybe there is a better template engine, or better route engine, etc. )