The Downside to Ajaxing WordPress

"Hijax" is a term used to describe a progressive enhancement in which internal site links are "hijacked" by JavaScript in order to load the content dynamically. It reveals to developers a whole new world of interactivity control. It's a fancy and futuristic world—a world not without a gotcha or two.

Sometimes Hijax is referred to as "Ajaxing" or "Ajaxifying", but these are less specific terms. It's important from the start to understand that Hijax is a specific variety of Ajax, and thus the two terms are not strictly interchangeable. I will explain both over the course of this article.

I am not the first to fall victim to the siren song of Ajax. In 2011, an older style of Hijax Ajax called "Hashbang URLs" brought down Gawker, who were just trying to be cool. Similarly, I realized during my most recent project that I, too, was in over my head, spending more time constructing stopgaps to ensure that arbitrary third-party plugins would work than I was spending on anything else.

Maybe you've been there and you're familiar with the perils. Maybe not. Either way, before you begin steering your ship towards Sirenum ajaxuli, let my experience serve as a warning: strap yourself to the mast and consider the cons of Ajaxing your WordPress theme.

What is Ajax?

For those who aren't familiar with it, Ajax is a simple but powerful (and increasingly common) front-end technique in which JavaScript makes a server request in the background. Then, instead of loading a whole new page, the server returns its data to the JavaScript, which can process it or load it into the DOM. Meanwhile, the client can continue without interruption. Ajax is like sending the intern to Starbucks so you can keep working.

So, if Ajax allows for an uninterrupted browsing experience, why don't developers use it for everything? Well, it turns out that Ajax does have its share of consequences depending on what you're trying to accomplish. Ultimately for this project, three major issues caused me to renege on full-site Hijax in favor of a more targeted approach.

Issue #1 - Specific information is hard to come by

Stick some combination of "ajaxify"/"ajax"/"hijax" into the search bar and you'll quickly discover that there's no standardized terminology for any of this, meaning even if there is pertinent information out there, you'll never find it beneath heaps of articles about plugins and forms and whatever else. Maybe I'm naive, but WordPress' native implementation of Ajax shows up in search results so consistently that I began to question my understanding that it was irrelevant (it was) and wasted a bunch of time as a result.

Yes, it turns out that Ajax has tons of uses, and adding sex-appeal via Hijax is just one of them. A couple common uses are form validation, shopping carts, and saving drafts on the fly, but really, Ajax can be considered for anything where you need to swap data asynchronously between client and server.

The side effect of its broad appeal is that it's sort of difficult to find the right information for the right kind of Ajax. Specifically, good information on how to properly implement Hijax is surprisingly lacking, which brings me to my next point...

Issue #2 - What information there is, is obsolete

Ajax is a burgeoning and rapidly changing paradigm in web development. When you do find Hijax-relevant resources, even from a year or two ago, you have to be careful of out of date information. For the basics, CSS-Tricks has a great screencast on "Ajaxing" a WordPress theme.

Unfortunately it's from 2010 and uses the outdated "hashbang" or fragment identifier technique that was fashionable at the time (the same one that got Gawker in trouble). You'll find plenty of articles on this technique, but it's pretty flawed, and nowadays there's a better alternative in the modern History API, which does all the good stuff without breaking the internet.

Luckily, it is fairly easy to adapt the CSS-Tricks code to use it. You will still need to provide a fallback for browsers that don't support the History API (IE9), but since you're not cutting up URLs, that's as simple as a redirect:

if (typeof history.pushState === 'undefined') {  
    // Refresh the page to the new URL if pushState not supported
    location.href = url;

So as you start massaging that code into your theme, you suddenly realize...

Issue #3 - All your JavaScript widgets and plugins don't work anymore

Honestly, implementing Hijax isn't that difficult, even without a library like jQuery. The problem lies in the fact that managing JavaScript and CSS resources becomes much more difficult when your site runs on Ajax.

Many WordPress plugins count on specific JavaScript being executed when the page is loaded, but Ajax throws a wrench into that. Unless you have full control over what users can and cannot add to their site (hahaha), you're going to have to resort to one of two options:

Option 1 - Specifically add code to reload known widgets. The operative word being "known". On Henley Edition, I use something like this:

glassApp.pageSetup.reload = function() {  
    // do all the normal page setup
    // re-scan for code blocks

Option 2 - Hack something together to parse the GET data for script tags and execute them manually, which just sounds like an awful idea from the get-go. You might be tempted to do really gross things that will almost certainly get you into trouble. Maybe store loaded resources in an array so as not to load the same script/stylesheet more than once? You might also need to remove certain scripts from page to page, lest your site crumple to its knees.

If you're a tricky son of a gun, you might be able to make it work, but you can see we're not in Kansas anymore. It was around this point that I began questioning whether this enhancement was really worth the hassle.

Summing up

Moral of the story: don't try to add Hijax to a public WordPress theme. Because third-party scripts generally need to be hard-coded into the theme for Hijax to work properly, compatibility with JavaScript plugins is pretty limited.

If you do have control, though, I say go for it. The responsiveness of a well-tailored Ajax-driven website is a wonderful thing, and once you know when to use it, you'll want to implement it in every project.