Because by the time the page is in the browser, all page components have been merged to one big chunk of HTML.
#WORDPRESS SHOWHIDE PLUGIN PHP CODE#
This ultimately means that JavaScript code sees the whole page, and has no access to WordPress-specific information about WordPress-specific parts of it. The problem with JavaScript is when it runs, and that is after the whole HTML page has been generated and transmitted to the browser. Disadvantages of JavaScript in Favor of PHP 4Īlas, as we will see in a second, this presumable advantage is also the main disadvantage of the JavaScript approach. The DOM is browser-specific, so cross-browser differences how irregular HTML is rendered are already ruled out. Manipulating a clean HTML document through the DOM always results in a clean HTML document. There is practically no way to “spoil” the well-formed-ness of the DOM by manipulating it.
This has two immediate – and great – implications: 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. So all their saved server time won’t make up for the users they loose. I tend not to revisit such sites, and I don’t think I’m especially exotic or picky on this. 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. Too much (or poor) JavaScript can well make page loading slower from the user’s perspective. While it’s absolutely true that moving computing from the server to the client/browser saves server time, this is not necessarily beneficial. One advantage Ted lists in favor of JavaScript is saving server time. But there are right and wrong tools for every job, so… Alleged Advantages of JavaScript Implementations Saving Server Time
I simply love it! I much rather program in JavaScript than PHP.
#WORDPRESS SHOWHIDE PLUGIN PHP PRO#
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.Īlso, let me state explicitly that I’m all pro JavaScript, and jQuery in particular.
Follow me on this…īut 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). In fact I have considered a jQuery implementation myself, and it hurt me badly that I had to reject it – for a good reason. This technological choice is the most compelling characteristic of Ted’s plugin – and the most problematic one. It uses JavaScript (jQuery, to be exact), to extract post headers and dynamically generate a TOC. What makes this one stand out from most others is its choice of technology to base its implementation on. 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. When observing this development, I’ve been (naturally) asking myself why people bother to reinvent the wheel. Meanwhile, several have arisen, all of which provide a subset of SEO Table Of Contents’ features. When I implemented Hackadelic SEO Table Of Contents, there hardly was an alternative TOC solution for WordPress. It compares two diametrically different technological foundations, PHP vs JavaScript, for WordPress plugins. This post elaborates on the sense and nonsense of technology choices for a WordPress plugin implementation.
0 kommentar(er)
