Cancel

Jeff Chandler

A Look at Why Some Frontend Developers are Decoupling WordPress

Decoupled WordPress Featured Image
photo credit: Coupler: Immigration Museum – (license)

Emily_Miller1This 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.

Decoupling allows you to experiment with different JavaScript frameworks, such as Angular, to build a truly custom experience for users. That’s not to say everyone should go headless, but rather that decoupling is an option if your project has a set of requirements that call for a more flexible build.

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.

What Now?

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.

Category:
Tags: , ,
26

26 responses to “A Look at Why Some Frontend Developers are Decoupling WordPress”

  1. 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. )

  2. An important consideration is what benefit this brings to people other than the developers making it. In cases where the WP REST API and decoupling WordPress brings a real benefit for the client then that’s great. Go with it. But too often the developers I’ve seen and talked to want to bring in AngularJS or another JS framework, decouple WordPress, and over-engineer a solution that results in the front end experience for users having no improvement yet introduces more complexity behind the scenes. The developer gets a nice piece for their portfolio, and likely gets to charge a premium for the project, while the client gets…to pay more and require more specialized developers in the future to give their users an experience no better than their competition who went a more traditional route.

    Don’t get me wrong. I’m not against the WP REST API or anything along those lines. It’s a powerful tool, but use the right tool for the right job. I’m tired of seeing people using the newest, shiniest tool on every job whether it brings a benefit or not, just so they can brag about it, while other people invent newer, shinier tools to accomplish the same thing so they get to brag instead. But that’s the state of front end development right now. Advancement, yes, but with lots of reinventing the wheel and selling clients a bill of goods.

    • David – Great points. I agree that a decoupled build isn’t right for every project. If there’s not a compelling reason to decouple, you’re likely making the project more challenging and expensive than it needs to be. However, I think as frontend trends evolve, more and more site requirements will call for a decoupled build, and I hope that as a community we can share what we learn to make the whole process a bit more approachable :)

        • Yup – we are Ruby and JavaScript on the front-end and we use WordPress on the backend. We have an entirely different product that we use for our longform builder, which is one of the advantages of decoupling. We can develop and use new tools for content creation without having to give up our legacy CMS system editorial is comfortable using.

      • Oay Emily, I’ll practicing in patience :)
        But I fear, at the moment everybody is yelling “WordPress REST API” though nobody knows where the real benefits are.

  4. There are other ways to decouple as well. Ive experimented with having a node.js front and managing content with WordPress. Not made anything production worthy etc but it was fun setup.

  5. It’s going to be interesting to see how WP transitions from its DNA as a every man / woman tool, to a position in the market that requires a much more robust set – depth & breadth – of skills.

    That said, as these higher end of devs – new to WP with potentially higher dev expectations – flirt with WP, will WP be up to meeting those expectations? The technology is manageable. That’s not really the friction. However, this fork of The WordPress way? Perhaps not so much so.

    Some have suggested WP might be on the cusp of having its Microsoft moment.

    We’ll see. Exciting times ahead for sure. Great article. Thanks.

  7. A lot of this is over my head, but I have to say that losing “preview” would be a bit of a blow, since the visual editor very rarely reflects the output on the front end accurately.

  8. For more details of the “Why” decoupled question, check out our blog post ‘Why We’re Decoupling Drupal’:
    http://www.pixotech.com/decoupling-drupal/

    For more of the “How” to decouple topics, watch for updated how-to’s on the Outpost site:
    http://www.getoutpost.org/

    Outpost is an open source framework for decoupled websites. Also, the “How” question really has multiple answers, and two good case studies are covered in-depth in the Webinar video Emily linked to above.

    • Thanks for the extra resources, Brandon! There are some great Drupal case studies out there that could be useful for those who want more real life examples of decoupled CMS.

      We’ve begun aggregating a lot of these resources for both WordPress and Drupal here: pantheon.io/decoupled-cms

  9. Interesting thanks re de-coupling. I. The days before WP our Dev teams were doing this with SQL as a back end and our primitive version of an API with front-end separated. Tools have improved and that’s good but it also underlines the restrictive nature of many themes. For me I am looking for more design front-end freedom too but need that front end layer to be able to be readily maintained.

    Better design/front-end tools beyond relatively primitive Customizer menu options etc that an organisation can rely upon but enhances creativity is what I believe the community needs. Vital Dev work in De-coupling needed to innovate with leaders in theme development path to next gen visual tools a must. Demos and examples please in follow-up would be much appreciated. There are framework type themes with their own front-end visualisers but surely a more creative front end is vital for all. Not everyone will want to code the front end. Interesting times ahead and we should keep an eye on other platforms where emphasis has already been on the front end. It maybe unpopular to say this but I am concerned how slowly the core front end is moving forward.But I can see decoupled tools and libraries maybe critical to solving this problem. Thanks lots to think about! Look forward to hearing more.

    • I’m glad you found the post interesting. I look forward to learning more about the different builds and use cases for decoupled WordPress, and will share what I find!

  10. This sounds like a very interesting way to do it. Is there any other examples apart from Pixo Tech and possibly Mashable?

    • New York Times is decoupled – Scott Taylor who is the wordpress 4.4 lead works @ NYTimes and gave a great architecture layout example of the build they use this summer at word camp Maine. Very Modular so that pieces can be shifted if needed on their front end.

  11. I’ve used the decoupled paradigm very successfully on two totally different production applications.

    They both use the WP-API with the WP-JSON and PODS plugins to provide data to Node.js servers. The front ends are native JS for a set of content sites and Angular.js for a form generator. This architecture has proven to be a very flexible and powerful solution for us.

  12. We build business oriented tools for BuddyPress and are using the REST API with backbone to manage the entire thing. This works very well indeed for the elements we are currently concerned with. Whilst this is not fully decoupling by any means it is a large step in that direction.

  13. I have spent the past year implementing such a “decoupled” multi-user single-page TypeScript/JavaScript application called “NarraFirma”. NarraFirma is based on my wife’s work on “Participatory Narrative Inquiry” explained in her free book “Working with Stories in Your Community or Organization”. The application (designed by my wife) has more that forty “pages” all defined in TypeScript (and some JSON) using Mithril and D3 for the front-end GUI, which communicates to a backend using AJAX with JSON. The application backend can be either WordPress (via a PHP plugin) or via a small NodeJS server application in JavaScript. The backend code is maybe 1% of the frontend code in size. Data is primarily stored as messages consisting of triples in the WordPress database (one table per project, with one message per row, with database indexes) or as flat files under NodeJS (one directory per project, one file per message, with indexing and caching in memory). This message-oriented approach supports several users collaborating at once to modify the same “page” and reasonably quickly see updates without a page reload. Pages can include editable tables and editable 2D clustering diagrams. I’m currently working on improving the admin GUI for the WordPress plugin also using Mithril to make it easier to create multiple projects with various different access permissions. We plan on announcing the official release of the first major version in a few weeks. This project has been mostly a labor of love, although we hope in the long-term it will increase the demand for my wife’s consulting services related to her book.

    We have released all the code for the NarraFirma application under the GPL here:
    https://github.com/pdfernhout/narrafirma

    It’s exciting to see WordPress improving as an application platform supporting JavaScript applications. It’s hard to beat the “one click” install process of a web app that WordPress makes possible for tens of millions of users. While the NodeJS backend is more “efficient” than the WordPress backend as far as throughput per CPU cycle, the NodeJS backend is much harder to install and maintain for most people than the WordPress plugin and thus is “inefficient” of people’s time in that sense. The stand-alone NodeJS version also does not leverage an existing community’s or organization’s user base in terms of people who already have signed up for an account on a WordPress site and who can be authorized easily to use the plugin rather than having to create yet another account on some new system. So, we expect that most of the application’s users will install it via WordPress. I expect other developers may make a similar choice in the future for deploying JavaScript and mobile apps that need an easy-to-install-and-upgrade backend — especially if that backend is intended to support projects for a specific community or organization.

    • In case anyone is interested in trying out the NarraFirma WordPress plugin as an example of a significant “decoupled applicaton”, we have just put up an interactive demo version of it here.

      A big tradeoff so far has been that the application can take twenty seconds to load (while staring at a please wait message). That loading time is due to two things. About half of that load time is due to loading dozens of unbundled JavaScript files which could be reduced by packaging (I’ve just not gotten to that yet) and maybe some other clever on-demand loading. But the other half of the loading time is due to loading the project data (about 1000 transactional messages), and that time probably can not be reduced much as the app already bundles 100 messages at a time (other than a faster server and more bandwidth) with each round trip (plus 100 database record loads) taking about a second. That part of the loading time would go up with even bigger projects. However, once the application loads, it is snappy, including generating charts and graphs and scrolling through lists of hundreds of experiential stories and related metadata.

      We also have put up some more background information of the NarraFirma app effort in an entry to a Knight News Challenge on: “How might we make data work for individuals and communities?”

      It could be interesting and worthwhile to enhance the WordPress platform in ways that meet the needs of many of the other 1000 or so entries to that challenge.

  14. We are experimenting in de-coupling with pretty encouraging results at http://theinformr.com.

    First we migrated our legacy app’s front-end route by route from Symfony to Symfony2 + JS and are iteratively migrating parts of the backend to WP with help of the REST API.

    The motivation is that WordPress + ACF is just works. It gets content into the db where we need it without re-inveting the wheel.

    WordPress is familiar to most anyone we onboard and we free more time for our devs for front-end work which Emily points out as an advantage in her article.

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: