WordPress PlugIn Tech Foundations – PHP vs JavaScript

This post elaborates on the sense and nonsense of technology choices for a WordPress plugin implementation. It compares two diametrically different technological foundations, PHP vs JavaScript, for WordPress plugins.1

Motivation

When I implemented Hackadelic SEO Table Of Contents, there hardly was an alternative TOC solution for WordPress. Meanwhile, several have arisen, all of which provide a subset of SEO Table Of Contents’ features. When observing this development, I’ve been (naturally) asking myself why people bother to reinvent the wheel. Artem Russakovskii, who has also contributed to the development of SEO Table Of Contents, has recently asked that question out loud at the youngest offspring in the TOC plugin familly, Ted Carnahan’s WordPress jQuery Table of Contents plugin.

What makes this one stand out from most others is its choice of technology to base its implementation on. It uses JavaScript (jQuery, to be exact), to extract post headers and dynamically generate a TOC.

This technological choice is the most compelling characteristic of Ted’s plugin – and the most problematic one. In fact I have considered a jQuery implementation myself, and it hurt me badly that I had to reject it – for a good reason. Follow me on this…

But before I continue let me say that I’ve taken a look at Ted’s code, and found his implementation extremely clean and snappy (from which I conclude his programming skills are clearly above-average). It is not Ted’s implementation I’ll be critically examining, but the strategic decision to base the functionality of a WP plugin on JavaScript in general.

Also, let me state explicitly that I’m all pro JavaScript, and jQuery in particular. I simply love it! I much rather program in JavaScript than PHP. But there are right and wrong tools for every job, so…

Alleged Advantages of JavaScript Implementations

Saving Server Time

One advantage Ted lists in favor of JavaScript is saving server time. I have an ambivalent view about this. While it’s absolutely true that moving computing from the server to the client/browser saves server time, this is not necessarily beneficial. Too much (or poor) JavaScript can well make page loading slower from the user’s perspective. Or more clumsy. Or both. AJAX has been around for long enough for the most of us to know what I’m talking about: Clumsy websites that appear to load piece by piece like a patchwork, putting our patience to test for ages. I tend not to revisit such sites, and I don’t think I’m especially exotic or picky on this. So all their saved server time won’t make up for the users they loose.

Manipulates DOM instead of HTML text

This is the real, most compelling advantage of JavaScript: It has access to the so-called DOM (Document Object Model)2 representation of the viewed page as the browser sees it. This has two immediate – and great – implications:

The DOM is ultimately well-formed. There is practically no way to “spoil” the well-formed-ness of the DOM by manipulating it. Manipulating a clean HTML document through the DOM always results in a clean HTML document.3

The DOM is browser-specific, so cross-browser differences how irregular HTML is rendered are already ruled out.4

Alas, as we will see in a second, this presumable advantage is also the main disadvantage of the JavaScript approach.

Disadvantages of  JavaScript in Favor of  PHP

The problem with JavaScript is when it runs, and that is after the whole HTML page has been generated and transmitted to the browser. This ultimately means that JavaScript code sees the whole page, and has no access to WordPress-specific information about WordPress-specific parts of it. Because by the time the page is in the browser, all page components have been merged to one big chunk of HTML.

Generally, JavaScript has no access to information that is not present on the rendered HTML page (but is well present in the WordPress database).

In the case of a table of contents, the most important deficiency implied is that it will fail to produce a complete TOC for a multi-page post (as it will only ever see the headers on the current page only).

Conclusion

While there is no one who would be more glad if things were different, moving the core computing of a WordPress plugin from PHP to JavaScript is not generally a promising option. My own rule of thumb is to use JavaScript for dynamic “effects” and PHP for content processing. Of course there are situations when either JavaScript (like in the case of Widget Voodoo) or PHP is the only answer, but most of the time there is space for decision, and than the benefit of being able to access WordPress-internal data largely outweighs the discomfort of abstaining from JavaScript and the great libraries around it.

1. Of course, every WordPress plugin will ultimately contain at least some administrative portions of PHP code in order to hook into WordPress. I’m referring to the main computing though, and whether it takes place in PHP or JavaScript code. [↩]
2. The DOM is a representation of a HTML document as a hierarchy (i.e. tree) of HTML elements. [↩]
3. Though you may well violate some specific W3C standards even by DOM manipulation, but that’s another story. [↩]
4. For example, a HTML paragraph (<p> tag) does not normally allow nesting. When the HTML text contains nested paragraphs, it is rendered differently in different browsers. The DOM already represents that post-render state, so you don’t have to worry how things will be rendered (except when you are injecting HTML through JavaScript, which will cause that part to re-render). [↩]

1 Comment

• 
  Best WP Plugins February 22, 2010 at 11:24 pm

  Your blog is amazing, i first landed to another post but then get interested and thought, i will just look a little more arround to see what else i can find out about best plugins arround.