getiblog

Grab UI by the Handlebar

getify — Sun, 21 Feb 2010 21:53:03 +0000

A couple weeks back, I talked about HAML and why I’m not a fan of its approach. I promised in that article that I would be following up with some discussion of how I think UI templating should work. I intended to post earlier than this, but then I dove into a fun new coding project (which I will write about here soon), and I’m just now resurfacing for air.

Disclaimer: The criticisms I have of various web application frameworks and platforms are not entirely universal. There are some solutions out there which have vastly improved their approaches. For instance, I’ve borrowed some good parts from Django, Mustache.JS, even (whisper) .NET MVC. The problem is, the bad stuff is so overwhelmingly prevalent in the development community, it chokes out the life of those who really are trying to make it better. Add my voice to that list, and a +1 for all the others who are on that same page.

This will not be a simple quick post. There’s so much I need to write, and it just can’t all fit into a few paragraphs. Please bear with me as I expound on this topic.

Handlebar?

Before I go into further explanation, go check out HandlebarJS Template Engine, my entry into the arena of how to construct web UI. It’s important to note, this is not some “Yet-Another-” all-in-one framework that has sexy themeable widgets, a CMS, or auto-generated admin interfaces. All you will find there is a basic, simple Templating Engine, that takes JSON data as input, processes and compiles text-based templates (that you create and control 100%) into “executables”, and pumps the JSON data into the compiled templates to return a “View”.

There’s much more planned for HandlebarJS, including tools for build-processes, filters, compression, UI optimization, etc. They will come in the form of loosely coupled “plugins” that are compatible with HandlebarJS’ “view” of the world.

HandlebarJS is really quite the opposite of most UI frameworks: it’s a stripped down, deconstructed, anti-framework tool for what is now being called the “middle end” — the stuff that sits between the front-end and the back-end, and negotiates communication, View construction (templating), URL routing, data validation, and other fun things.

What HandlebarJS is not is any kind of RIA framework that attempts to handle the behavioral side (JavaScript) of rich UI. HandlebarJS is only concerned with as quickly and efficiently as possible generating the markup for the UI.

HandlebarJS is intended to be one of several independent components for re-thinking the middle-end UI architecture of web applications. Those other components deserve their own full projects and explanations/write-ups, so you’ll just have to keep an eye out here over the coming weeks for those.

Why should I care?

You may ask yourself at this point: “I have XYZ framework or platform (.NET, Java/Swing, RoR, Django, etc) already, and it does all that stuff for me. Why do I need something else?” Well, that’s a great and valid question, one that deserves a lot more discussion than can ever fit into one blog post. I do have a very specific set of answers to that question, and I will be unveiling it little by little through blog posts (including this one), separate dedicated websites, and even an upcoming planned book.

For now, I’m going to ask you the reader to take my word just a little bit — that’s there strong reasoning behind what I’m trying to do — and let me develop and explain it bit by bit. This post will present some of the high level motivations and discuss specifically HandlebarJS for templating — my goal for now is that you’ll come away more knowledgeable about just an alternative to how your web application currently approaches its Views. I’m not yet trying to convince you that you need an entirely different application architecture — we’ll get there slowly, and it won’t be as scary as it may seem.

What am I trying to solve?

I don’t want to re-write here the entire article and underlying arguments I had against the HAML approach. But, I do encourage you to read it to understand better where I’m coming from.

However, here are the primary thoughts that were motivating factors for creating HandlebarJS:

DRY and Portability: For decades, the development community has operated (to varying degrees of authenticity and success) under the principle of not repeating yourself, meaning as much as possible, don’t have two different sets of code that do the same thing. The advent of functions/sub-routines laid the ground work years ago, upon which Object-Oriented programming expounded to give us even better patterns for write once, use many.
The problem is, the explosion of the web application paradigm has thrown several wrenches into the mix. What fundamentally used to be a single monolithic application, or even a straightforward server-client application, is now a highly complex, distributed, cloud-integrated, web connected, desktop and mobile consumed, rich, thin-and-thick application conglomeration that challenges with orders of magnitude more complexity than our older patterns are capable of handling. It’s almost like we went from n-tier to n^2-tier architecture in a relatively short period of time.

Moreover, the paradigm of the presentation layer residing in a browser has both extended and limited the evolution of such applications. For several years, even after the invention of Ajax (which revolutionized the page-refresh), web developers have struggled with wanting to do more with Rich Interfaces than the browser (or even internet connection or host computer) was capable of handling. The latest generation of browsers, web technology standards, and computing equipment has finally broken down many of those barriers.

But just as we finally got to the point where the desktop web browser could be an effective tier in the overall application (not just a thinly veiled client), now we have an intense push to extend all our web application presences into a new frontier of “connected” devices (mobile, smart phone, netbooks, etc), many of which are (in some ways) throw backs to the performance (CPU, connection speed, etc) we could rely on with desktop browsers 5 and 8 years ago.

Even as mobile Safari pushes to implement the latest and greatest HTML5/CSS3 standards, the reality is that mobile web apps are still handcuffed by limited processor capacity, severely limited browser caches, and unreliable (at best) connectivity.

So what does all this have to do with DRY and portability?

I believe we are at an inflection point in the web UI evolution where we must start to think about things differently if we have any hope of keeping up with the exponentially complicating trends of consumer technology. We’re starting to see the fundamental inadequacies (and the pain it brings) of established solutions, in their inability to efficiently handle the rapidly expanding array of consumers of UI presentation.

These all-in-one frameworks are so attractive to development teams because they fully abstract away all of the messy details of how markup and data are combined to be the delivered UI product. But with that ease-of-use comes a price — lack of flexibility to control and optimize such UI delivery on the fly depending on who is consuming it. A fancy .NET list widget may rock for UI delivered in IE8 on a desktop, but is it up to the task of usable and functional behavior/display in a mobile Opera browser on a screen 1/16 the size of a laptop screen and with 1/10 the memory and CPU? The sad answer is often: absolutely not.

And no, it’s not enough to just have a different stylesheet for mobile browsers and expect that CSS will save the usability of your app. Mobile (narrow-screen) is an entirely different paradigm in almost all respects to desktop computing. To effectively leverage both platforms simultaneously, AND with the same (unrepeated) code bases, we’re gonna have to get a lot more creative.

“And now, for something completely different”

We need an approach to UI that is powerful yet compact, that is portable (meaning it can run in both a server environment and in a variety of browser host environments), and that is flexible enough to be extended/composed/dissected/etc as necessary for the different devices consuming the UI. This isn’t just an incremental improvement on existing systems, it’s an entirely new new kind of approach.

Of course, if you prefer to write code over and over again, and maintain different application branches for different presentation consumers, then you’ll probably totally disagree with me here — you’d probably rather just stay the course. But I think the future is more re-use and convergence, not less. And I make no apologies for the fact that this is my fundamental bias for everything I’m trying to do here. I do not like at all to Repeat Myself, and I’m going to do everything I can to keep that out of my development practices.

And I’m just crazy enough to believe in the idealism that it IS possible to achieve this utopia. We’re just gonna have to be brave enough to question everything we’re currently doing. No big deal, right?
Do front-end type work in……ONLY front-end technologies: I feel like I’m probably admitting frequently on this blog to not only being strongly opinionated but also a little bit crazy. But that’s ok with me. I can tell you we are not gonna ever solve any real problems by thinking the same way we always do. And I like that I’m a fundamentalist — that I believe less is more.
I think we could use a lot more of that mindset in the development community. You wouldn’t get in a jet-liner to travel up to the corner store — so why do we feel that these immensely complex frameworks and platforms are the right approach to web applications?

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. — Antoine de Saint-Exupery

Let’s face it: we all (at one time or another) entertain dreams that our web application is going to need to scale to hundreds of millions of concurrent requests, and our development team is going to balloon to hundreds of distributed development groups, and we must plan for that now by using an enterprise-ready Solution.

Yet, when you look at the world’s biggest web applications — the Googles, the Yahoos, the Facebooks, and the Twitters of the world — you actually don’t see them using such non-sense to drive their applications. In fact, you often see fundamentalism blatantly plastered across their approach. Why? Because as things scale, what’s not needed is more machinery to manage it, but less to abstract away and play middle-man in the transformation of a request into a response.

This post is about UI, right?

Nowhere is this more true than in the UI layer (the middle-end). It’s been recently suggested by Steve Souders of Yahoo and Google fame that actually most of the performance bottle necks (of small and large applications alike) is the UI layer.

My thesis: the fewer layers of abstraction sit on top of the presentation layer, the more efficient the application will operate (in both low and heavy traffic situations). My corollary: This fundamentalist approach to UI will also lead to better separation of skillsets — a front-end engineer can completely control the UI of an application using only front-end technologies like HTML, JavaScript, and CSS, which they are likely best at.

This means that when they want to streamline the way their UI is constructed and delivered to address a page-load efficiency issue on their site (like JS/CSS concatenation for instance), they can get directly and immediately to the problem, in the front/middle-end layer (instead of wading through who knows how much back-end cruft that they may or may not be fully capable of navigating or changing). They can also use the technologies they are likely most familiar with (their core skillset) to solve the issues.

This may seem like a trivial distinction. But I believe it’s a critical and overlooked factor in developer efficiency: staying within one’s core skillset — the sweet spot — as much as possible. And this doesn’t just apply to developers but to technologies as well. I believe there’s a reason that Java largely didn’t survive as a pure front-end technology, and why there hasn’t been a pig push by the community to bring native Ruby processing to the browser. These technologies have their place, but the browser is not that place.

Whether you like JavaScript or not, it’s quite clear that it is uniquely and best positioned to service all the needs that the UI layer needs. And as you’ll see in a little bit, that means both in browser and on the server. You may not ever (want or need to) re-write your hundreds of thousands of lines of Java, but I hope maybe you’ll consider delegating your UI code to the technology that rules the UI.

“Both-enders”

I can just hear some of you right now: you’re the ones who wear both the hat of front-end developer and back-end developer (sometimes at the same time). For you, it’s no big deal at all to “context switch” mentally and use back-end technology (like a JSP taglib) to generate your front-end. In fact, if you’re not a specialist in UI technologies, that may be more comfortable and productive for you to do so.

I don’t claim that I can convince you otherwise. But let me just submit to you this suggestion: is it possible that you might be more efficient at your UI hat tasks if you didn’t have to concern yourself at all with back-end architecture issues? And vice versa, would your back-end work be more fun and efficient if you didn’t have to constantly worry about markup, box model quirks, or cross-browser JavaScript’ing?

I think it would. In fact, I’m almost certain of it (at least the UI hat side of things). I’ve worn both hats many times in many different jobs. And I can tell you that unequivocally, I was noticeably more efficient when I had the ability to only wear one hat any given time. What is good for the back-end is often times irrelevant (or bad) for the UI, and vice versa. They are two entirely different disciplines, and it’s time we admit that. Not that you can’t do both, and effectively, but just that you can’t do both at the same time effectively.
Stop meddling in my code: Probably my biggest issue with how most frameworks and platforms approach templating is that the templating engine is deeply embedded in, and hopelessly intertwined with, the back-end technology. This invariably leads to far too often bending/breaking the fundamental rule of the MVC pattern (keep the View, Controller and Model separate).
For instance, consider PHP as a simple example. PHP is a templating engine (if you weren’t already aware). It allows you to take a predominantly HTML file and litter any manner of PHP code logic all throughout it. THIS IS NO BETTER THAN THE SPAGHETTI CODE OF QBASIC FROM 20 YEARS AGO. You actually have to fight hard against these urges (and pretty much every tutorial on the web), and go to great lengths to keep your templates free from such mess.

And why go to this trouble, you may wonder? Let me give this example:
```
   IsLoggedIn() && $user->CanPublish()) { ?>
      Publish
   
```
Seems harmless enough, right? WRONG. This is pure and undefiled evil. You think that just because you put the login session logic and access control logic into your Model (wait, shouldn’t that actually be in the Controller???), and you merely call and use those methods in your template, you’ve achieved separation? WRONG.

Why do I feel so strongly? Because this pattern is blatantly opening up the doors to putting Controller (and Model) logic right inside the View. First of all, your front-end developer (if that’s not also you Mr. Back-end Engineer) has to know something about your back-end technology (PHP in this case) — and in some cases, they need to know a lot about the back-end to even accomplish a small UI task. This is probably not his or her core skillset (see #2 above), so it’s bound to slow down the efficiency of UI work.

Also, you have now tied business logic into your View, which is against proper patterns we all learned in Software 101. Consider this scenario (which is so common it’s almost self-obvious): The View developer writes code like the above. Then he leaves the company.

6 months later, a back-end developer goes through and refactors the Model. He decides for one reason or another that Access Control Permissions are now going to be exposed in the Model (ie, across all the back-end code) as a bitmask property upon which efficient bitwise operators (| &) can be used to figure out permissions. Because they want to keep the back-end code pure and efficient, and don’t want unnecessary methods literring the Model, they remove the $user->CanPublish() method. No problem, right? We just do a grep/code search and find all instances of CanPublish(), and we change that code to instead be ($user->perms & USER_CAN_PUBLISH).

Ugh. If this doesn’t scream out at you as bad, I don’t know what planet you develop on. It gets worse. 6 months later, the back-end developer quits, and shortly thereafter, the business folks decide that a user must have both USER_CAN_PUBLISH permission and not ($user->restrictions & USER_IS_DISABLED). I bet at this point, the new back-end developer instead gives in and creates a method $user->CanPublishAndEnabled(). Yet more Controller/Model logic hopelessly embedded in the View. And yet another round of View refactorings. I bet your front-end developers (who don’t know much PHP) are getting annoyed by now. Are you seeing the pattern?

What if instead, there was a pre-agreed-upon Boolean property in the View data (ahem, not Model), called “allow_publish”. The Controller takes care of setting that property (with whatever logic is appropriate at that moment in time) before it invokes the View, and it just passes along that Boolean flag to the View. Then, no matter what kind of back-end refactorings or logic changes occur, the View always look like this:
```
   
      Publish
   
```
The difference may seem subtle, but it’s actually enormously important. While I’d definitely call this an improvement, there’s definitely more we can (and should) try to achieve.

But, my MVC can do that

The point is not really whether your current environment can do what I’m suggesting. The point is that it probably isn’t, and moreover, it probably feels easier to all involved if it doesn’t. Otherwise, you probably wouldn’t still be reading this article, because you’d be so furiously effciently coding away in your utopian development environment and would have no desire to read my crazy ramblings on the topic!

I believe we need to encourage Templating Engine solutions to be absolutely minimalist on the amount of “programming” they allow in the Views. The bias should be: allow only the bare minimum of logic as is necessary to select templates and fill them with data. If it’s any harder than that, then it’s logic that belongs back in the Controller (or deeper). Sure, you need basic things like boolean logic for selecting sub-templates, simple looping constructs, and such. But you don’t need the ability to call functions, invoke complicated, deep instantiation heirarchies of mixed Models, run math computations, or any of that non-sense. Remember: Jet-liner to the corner store.

Nodding off

OK, so at this point, you must be exhausted reading this post. I’m exhausted writing it. I promise I’m gonna wrap up quickly. I know it’s a lot of information to take in, but I’m intensely passionate that it needs to be said, and these questions and issues need to be addressed.

This article has thus far been almost entirely me laying out the reasons why I didn’t like most of the templating solutions that are common across the vast majority of web application frameworks and platforms. This is by far not an exhaustive list of the problems, but those 3 points above are a pretty good summary of the types of problems motivating me to find and present another way.

So, if you’re still with me after all that, let me try to briefly explain how I believe HandlebarJS addresses these concerns (and others).

Finally, some Handlebars

HandlebarJS gets its name as the upside down mustache (from MustacheJS templating). The { and } are the things of which we speak.

Here’s what you should know about HandlebarJS:

HandlebarJS is entirely written in JavaScript. In fact, it’s entirely written in a manner that allows it to run in either a synchronous or asynchronous environment, either in the browser or on the server (using any of several available server-side JavaScript environments). This allows the exact same code base to run either in browser or on server. Period. Doesn’t get any more DRY than that. You can do templating in either place, or both, as your application requires.
It’s small and portable and so should be suitable for your templating tasks in a wide variety of JavaScript friendly environments, including even (and especially) mobile.
It follows naturally that since the HandlebarJS code is portable and identical both in browser and on server, the templates themselves are also identical. Absolutely. The templating “language” is simple but expressive and capable of any tasks you should rightly tackle with templating. And so you can write your templates once, and run/interpret them in any HandlebarJS capable environment. Again, this is really DRY.
HandlebarJS accepts JSON data, and only JSON data, as its input. This means that any platform/environment which can serialize its Model/data down to JSON can send that data to a HandlebarJS instance and get back a processed template View output. Pretty much every language on the planet has JSON serialization/de-serialization support built-in (or at least available easily). JSON data is also the only format of data that is fully and natively portable from server to browser.
That’s right, some browsers (and clients) don’t natively understand XML even, but they all understand JavaScript, and thus all understand JSON data. Why go to the inefficient trouble of wrapping your data up in some other non-natively-parseable data abstraction? Just use JSON. Trust me, there is no other format better for the task.
HandlebarJS is built with simplicity and efficiency in mind. The templating language is as simple as possible to get the job done. It doesn’t give you too much rope to hang yourself. You really can’t embed Controller or Model logic in these Views.
Also, HandlebarJS compiles templates from their text files into executable JavaScript snippets. This “compilation” can be done on the fly (in either browser or server) if necessary, or it can be done as part of a build-process to increase efficency. HandlebarJS will operate the same functionally regardless of whether it’s dealing with pre-compiled templates or needing to compile them on-demand.

Fin

OK, that’s it, I’m done, I promise. I hope by this point you’re at least convinced it might be a good idea to take a look at HandlebarJS. Even if you are still certain that your existing application architecture is sufficient and won’t need to change, perhaps you might consider exploring if just the View portion can, in whole or in part, be separated off and delegated to a HandlebarJS instance.

If you only want to use HandlebarJS in the browser, you can do so without any architectural/server changes at all. Just drop it into an existing page and start converting your existing templates one-at-a-time. See how easy it is!

And absolutely the only required dependency for HandlebarJS (on the server) is a simple server-side JavaScript environment (many options are available). In fact, keep an eye for the next blog post here, as I will be discussing my brand new released BikechainJS, which is a SSJS wrapper around the V8 JavaScript engine, allowing drop-dead simple JavaScript execution on the server. HandlebarJS and BikechainJS are specifically built to be simple and compatible.

Seriously, stop reading this blog post now and go check out HandlebarJS — isn’t it about time for you to grab your UI by the “Handlebar” and make it do what you want?

Simulated Chaining in JavaScript

getify — Wed, 10 Feb 2010 16:18:04 +0000

What I have to talk about here is not going to be earth shattering, but it is a technique that has proved useful in a few different sites and scenarios for me. In fact, I regularly get questions regarding advanced use cases for LABjs (a parallel JavaScript loader), and invariably it comes back to something along these lines.

If you already understand object/function call chaining, just skip down to the good stuff.

The chains that bind you

Just so we’re all on the same page, “chaining” is this wonderful functional property of languages like JavaScript (which treat a function as a first-class citizen). It essentially amounts to making a function call, and the return value from the function is itself either another callable function, or more often, an object that has functions which are directly callable.

jQuery is probably the most prevalent use of this concept. Some example jQuery code:

$("p.neat").addClass("ohmy").show("slow");

In this snippet, $(…) is actually a function call, just like foo(…) or doSomethingReallyEvilButDontTellAnyone(…) (just kidding; only Google would name a function something crazy like that).

The return value from the $(…) call is an object, that has a bunch of properties on it, many of whom are functions. Consider that conceptually an object is returned like this (not actual code):

function $(...) {
   // do something cool
   return {
      addClass:function(...){...},
      show:function(...){...},
      ...
   };
}

So, what happens is that when that object is returned from the function, JavaScript will allow you to immediately de-reference the return value (the object), and using “.” (dot notation), access its properties. So $(…).addClass(…) makes the first chained call (“addClass”) off the return value from $(…). Then, addClass(…) also returns the same (same kind, not identical) object, and so this second return value can identically be de-referenced and a chained function be called. I like to refer to each chained function call as a “chain link”.

This chaining can theoretically go on forever (although for code readability it can be argued that 3 or 4 chain links is probably the most you want to practically do in production code, exceptions aside).

Why chains?

Probably the single biggest argument for developing code API’s that are of this chaining style is to pass context along from one function call to another in an automatic and graceful feeling way. For instance, in jQuery’s case, the reason for chaining is that internally, there’s a collection (a fancy array) of objects, and as each chained function is called, internally it loops over the collection of objects and performs tasks (such as expanding/contracting the collection, modifying objects in the collection, etc).

jQuery could work functionally this way and achieve the same effect:

var collection = $("p.neat");
$.addClass(collection,"ohmy");
$.show(collection,"slow");

See how we had to pass in the “collection” object/array for every function call? It works, but that code is arguably a little less graceful. And certainly it’s a little more repetitive.

So, chaining was a way to accomplish the same task (context passing across function calls) but in a prettier, more graceful fashion. Generally, the idea of adjusting the way a set of code works to make it more expressive or pleasant is called adding “syntactic sugar”.

To be fair, syntactic sugar is not the only reason why chaining in functional languages is useful. In fact, with LABjs, which also has a similar type of chaining API (although internally operates quite differently from jQuery), the reasons were only partially “sugar”; chaining in LABjs’ case actually provides an effective solution to guard against certain types of race conditions.

Because of how JavaScript (single-threaded) works, a chain of function calls is more or less guaranteed to complete fully before any other code comes in and interrupts to execute. This is also probably true of a series of distinct function calls in a single code block, but even more definitely so for a chain of function calls or (as we’ll see in a moment), a loop of function calls.

So why not a chain?

Since chains are powerful and also tend to lead to more expressive code (unless abused) and also generally less code, you may wonder, why wouldn’t we always use chains for everything?

The obvious: some function calls are, by their nature, independent and thus do not need to (or should not!) share a context. Also, under certain circumstances, chaining can be less efficient internally, depending on how the context is stored/shared/used.

Let’s face it: if you really want to write your entire “program” on one line with a bunch of obscure/abusive syntactical tricks, just go write some Perl. I kid, I kid.

But beyond those things, one fundamental fact of chaining is that it’s not “dynamic”. Basically, what I mean by this is that you pretty much hard-code at the time of code writing (aka, “build time”) how a chain is constructed. You can’t decide at run time based on environmental conditions that some parts of the chain are conditionally not executed (like by wrapping them in an if-statement, etc).

The ability to do that kind of run-time logic is restricted syntactically to individual statements/function calls, so a chain will be considered an atomic single indivisible unit for those purposes. You could conditionally decide whether to run one of several different chains depending on conditions, but each chain to be chosen would be pre-defined and for the most part immutable.

So, the truth is, chaining provides a syntactically prettier (more expressive) code approach, but it limits us a little bit in terms of coding flexibility.

I need more concrete

To illustrate, let’s revisit jQuery’s example code from above. Let’s say instead that what you really want to do is only run the addClass(…) call if some condition is true (like for instance, the user has a valid login session, or whatever). So, you want to basically do conceptually something like this:

$("p.neat")
if (userLoggedIn()) {  .addClass("ohmy")  }  // invalid syntax; will not work!
.show("slow");

As I mentioned, you could just have two different chains, one with addClass(…) in the chain, one without it, and choose which chain to execute with your if-statement. This leads to more and repetitive code; a bad thing. DRY (don’t repeat yourself).

And to be honest, you could also model this in a pure jQuery way (only in the chain using various filters), a variety of different ways. For instance, something like this (while ugly) might work:

$("p.neat")
.filter(function(){
   return isLoggedIn();
})
.addClass("ohmy")
.end() // ends the most recent filtering operation
.show("slow");

What I did here was use filter(…) to basically conditionally empty out the internal collection if not logged in (by returning false for all iterations), meaning the addClass(…) call is essentially ignored, and then revert back to my original collection with a .end() call before lastly calling .show(…).

Let me be clear: while you can do it this way, this is by far not the most efficient or code-friendly way to do so. This would be an example of an anti-pattern, where you are abusing jQuery’s syntax to solve a problem in a way that it should not be solved. It goes contrary to the spirit of jQuery (“write less, do more”).

Other examples?

Conditional inclusion of “chain links” is only one scenario where traditional chaining is kind of limiting. What if you want to be able to piece together different parts of a chain from various different snippets of code across mutliple functions? This may sound strange, but with complex Web 2.0 web applications, this kind of thing is not uncommon. And it flys in the face of the simple syntactic sugar that chaining is supposed to give us.

Nor are these problems limited to jQuery. With LABjs for instance, a chain might look like this:

$LAB
.script("framework.js")
.script("loggedin.js")
.wait(function(){
  // do something
});

Notice there I may want to only load “loggedin.js” if the user is, in fact, logged in. Same syntactic problem as above. But LABjs has no conditional “filters” that can modify the chain’s context, so we have less options (which in this case is a good thing!)

Or, what if I have a CMS system (like Wordpress for instance) that, across various functions, files, templates, etc, needs to load up a variety of different files, all based on various different environmental conditions and which templates are active, etc. Could I do individual $LAB chain calls in each location? Yes. But then I lose the ability to sequence the loads (ensure execution order). Also, it’s less memory efficient to do 8 different chains with 1 script in each, as opposed to one chain with 8 scripts in it.

Or, what if I want to use LABjs in a larger solution for creating robust fallback for resource loading from CDN locations? I need to conditionally decide during loading/run-time if I need to add more scripts to the “queue” because one load failed. Not possible with traditional chaining.

Unravel the ball of yarn

All this leads up to say that chaining is great and expressive and powerful, but it’s not complete for all our needs. So, we need to get a little more creative in those cases. And this technique is what I’m going to call “Simulated Chaining”.

Recall that at the top of this post, we talked about how chaining works because the return value from a function is either a function itself (and thus can be called directly), or it can be an object that can be de-refenenced and has properties which are functions to be executed.

So, our solution lies in that sentence (emphasis added). The return value from a function can either be used immediately, or it can be stored and used later. This isn’t anything new; if you’ve ever called any function in any language, you know it can return a value that you can store in a variable. What might have escaped you until now is that this return value that you store can be a contextually sensitive object that would otherwise have been used immediately in a chaining situation. And the cool part is it can be used later (like the next loop iteration) to pick up where the chain left off.

So, instead of pre-defining a chain in our code/build-time, we can instead programatically (at run-time) build up a “list” (an array/queue for instance) of functions to be called, and then “simulate” a chain by looping through the list, calling each function, and storing the return value for use in the next iteration.

For instance, the LABjs script code above can be done like this instead:

var queue = []; // empty array for now
...
queue[queue.length] = "framework.js";
...
if (isLoggedIn()) { queue[queue.length] = "loggedin.js";
...
var $L = $LAB;
for (var i=0, len=queue.length; i
I simulated a chain of function calls with an iterative for-loop. (NOTE: this is conceptually very similar to how you might take what would otherwise be a recursive set of function calls and turn it into a non-recrusive, iterative loop instead, like for performance reasons). The key is: store the return value from a function call, and then use that stored value as the object that makes the next call. Plain and simple. And now more powerful as you can build up your chains at run-time in as complex a way as is necessary.
Theoretically, a very similar approach could be taken for the jQuery examples above. However, I’ll leave that as an exercise for the reader.
Let’s look at one last slightly more advanced example of how to use simulated chaining with LABjs (which is nearly identical to how I do it on several of my sites):
var queue = [];
...
if (conditionOne()) {
   queue.push("framework.js",false); // false will create an empty .wait()
}
...
if (conditionTwo()) {
   queue.push("plugin1.js","plugin2.js",function(){
      // initialize plugins
   });
}
...
queue.push("mypage.js");
...
var $L = $LAB;
for (var i=0, len=queue.length; i
I specify a queue array that can have one of three types of entries: a [string] is interpreted as a script to load, a [false] is interpreted as an empty .wait() call, and a [function] is passed to a .wait(…) call. I can use any manner of complex logic to build up the queue, and then in one for-loop at the bottom of the page, simulate the chain by looping over the queue.
Hopefully this helps clear up some of the mysticism that is chaining and give you some other ways to approach the challenging use cases you may face in your code. Go forth and chain (or loop)!

HowTo: Custom “Error” types in JavaScript

getify — Mon, 08 Feb 2010 20:10:31 +0000

There are lots of patterns for various styles of object-oriented JavaScript. They range from the simple few-liner patterns to the complex libraries with lots of syntax sugar. Also, this great book on OO JS by Nicholas Zakas is a must-read.

However, I have to admit that I am typically not a fan of most Object-Oriented JavaScript patterns. Well, I should clarify that to say, I’m not a fan of inheritance patterns in JavaScript (or any interpreted language for that matter).

The reason is usually performance related, and also because most scripting languages do a poor job of supporting the right syntax to make this efficient (hence the aforementioned libraries that go to great lengths to support it for you). Also, JavaScript has this really annoying habit of losing the “this” binding all too easily, which makes properly coding with “this” to be more a pain than most would like.

In my opinion, I shouldn’t have to think so hard about a programming construct that it actually gets in the way of what I want to do. Granted, maybe it’s a perpetual cycle, because I’ve never been fond of OOJS, nor had much use for it, that I’ve not been exposed enough to where it just comes naturally for me to think that way.

By contrast, I do get JavaScript closures, in a deep and profound way that makes me all warm and fuzzy inside. So it follows naturally that I use them all the time, for OO patterns such as encapsulation. I find it to be absolutely invaluable, and I have no trouble coding them almost in my sleep.

Many others however consider closures to be confusing and even somewhat mystical, almost the same way that subtle differences between “references” and “pointers” in C++ have tripped up many a developer.

Anyway, listening recently to Alex Sexton speak about such things in his “Superclassy Inheritance in JavaScript” talk from Developer Day (Austin), I realized one area that I’ve always wanted to inject a little OO (inheritance) into my JS — Error Handling.

All the world’s an error

I assume you are aware of the fact that JavaScript has errors! Almost every page on the web has, at one time or another, thrown frustrating errors at unsuspecting visitors. If you are blissfully unaware of such things because your browser hides them from you, I’m sure you’ve at least missed out on some intended interaction experience because of broken scripts at one point or another.

The reason JavaScript errors get thrown in our faces so often is that code is often not written in a robust manner. It’s written quickly or sloppily or just in best-case scenario world only. When an unexpected error condition occurs, and “noone” (ie, none of the script) is paying attention, the error bubbles all the way up to the browser, and everything stops. Talk about worst-case scenario.

Just try me

JavaScript has, for a long time, supported the “try/catch” paradigm (popular in other OO languages like C++ and Java), which is supposed to be a way to handle errors more robustly. The thought goes, if you “wrap” a try/catch clause around a potentially problematic set of code before you “try” it, you can “catch” an error on-the-fly that may occur, and respond in a more graceful way than just stopping and quitting.

For instance, you could try an alternate syntax for the offending statement, or at the very least, you could politely message to the user than an error happened and that they should refresh or try again later.

Those familiar with object-oriented programming know that the preferred pattern for how to handle errors in the bowels of a function or object is not to just quit, or return “0″ or “-1″ (as was the style of old-school C programs, for instance). Instead, you should simply “raise” or “throw” an error, hopefully with some helpful info like why, and then let the originating code “catch” the error and correct as appropriate.

Example:

function doSomething(val) {
   if (val < 1) throw new Error("val should be greater than 1");
   ...
}

try {
   doSomething(0);
}
catch (err) {
   doSomething(1);
}

So, obviously in that trivial example it looks rather contrived. But, you should get the point: if necessary, throw an error somewhere, let somewhere else catch that error and proceed accordingly.

So, use try/catch everywhere, right?

To be sure, you should not write sloppy code and just assume that try/catch clauses will save the day. Not only will that style of coding lead to inefficient and bloated code, but also you are really abusing what the pattern was intended for: graceful error handling.

Nothing could be less graceful than a try/catch around every line of code, or worse yet, just one big try/catch wrapped around everything. You should design your code to be as robust as possible, and use try/catch clauses in specific areas where it will be helpful and more graceful than just dying in the code execution.

Then what?

I'm gonna skip forward and assume that you now understand how to properly and wisely use try/catch in your code. If you go and abuse it, don't come blaming me, 'cause I warned you.

So, the real problem with just the standard generic "Error" object in JavaScript is that it fails to give the "catching" code much good information about what kind of (or, why the) error occured. Imagine a function that can throw one of 4 different specific errors, as well as the occasional uncaught general exception. The single try/catch around that function call is going to have a really hard time deciding which of those 5 cases it was, and thus what to do about it.

That's why in more traditional languages like C++ and Java (and even Actionscript!), the pattern really says that you should create a specific typed error when you throw one manually. The "catching" code can then examine the type of what was caught, and act appropriately. Again, more graceful.

So now we see why I started talking about object-oriented inheritance at the top of the article... to accomplish all this pattern has to offer, we need a good/easy way to extend the built in native Error object in JavaScript, so that when we throw them, and other code catches them, it knows what kind of error was actually thrown.

What I'm going to present here should not at all be considered the only (or maybe even best) way to do this, but I'm quite happy with this pattern as it supports all the necessary requirements I had. Most specifically, it's a pattern of code you can put in place without using any other library/dependency, and once your "Custom Error" class (or classes) is/are in place, using them should be pretty straightforward and true to pure JavaScript coding. It also gives you some basic inheritance (prototypal) behavior to make code a little easier to maintain and extend.

Here's a custom error class that extends the native Error object with a custom field/method:

var MyError = (function() {
   function F(){}
   function CustomError() {
      // correct if not called with "new"
      var _this = (this===window) ? new F() : this,
          tmp = Error.prototype.constructor.apply(_this,arguments)
      ;
      for (var i in tmp) {
         if (tmp.hasOwnProperty(i)) _this[i] = tmp[i];
      }
      return _this;
   }
   function SubClass(){}
   SubClass.prototype = Error.prototype;
   F.prototype = CustomError.prototype = new SubClass();
   CustomError.prototype.constructor = CustomError;

   // add a custom method
   CustomError.prototype.CustomField1 = function(custom_1){
      if (custom_1 != null) this.custom_1 = custom_1;
      return this.custom_1;
   }

   return CustomError;
})();

I don't want to spend too much time explaining all the ins and outs of this code and how it does what it does. But I'll try to explain the most important things.

Firstly, how you use it:

function doSomething(val) {
   if (val < 1) {
      var err = new MyError("something");
      err.CustomField1("val was less than 1");
      throw err;
   }
   ...
}
...
try {
   doSomething(0);
}
catch (err) {
   if (err instanceof MyError) alert(err.CustomField1());
   else alert("A generic error occured.");
}

So, when an error/exception condition is detected, we instantiate a new MyError instance in the way you'd expect: var err = new MyError("something");. (NOTE: you don't have to use the "new" keyword, as the code has detection to correct for this if you forget it, but it's definitely better and more efficient if you do.)

Then, we call a custom method on our custom error instance, "CustomField1", and in this case, we pass in a value that gets set as a custom field/property on our instance. We could have just done err.custom_1 = "..."; but that's not very OO is it!?

Now, we simply "throw" the error object. You'll see that the function doSomething() is "try"d and thus the error we threw will be caught. Lastly, to distinguish between our custom error and a generic error thrown by the JS interpreter, we use the "instanceof" operator check.

Pretty cool huh? We created a custom "class" of "MyError" that extends from (and inherits behavior from) the native Error object, we added custom behavior to it, we created and threw the error, we caught it, and then we checked to make sure what we caught was the correct type of error.

Going further

Here is a demo of extending the Error object to create custom Error classes. The demo shows "MyError" extending "Error", and then "MoreMyError" in turn extending "MyError" and overriding some of its inherited functionality.

For reference (if you don't want to view-source on that demo), the source code for the demo is available on github.

Special thanks to John-David Dalton (and, as mentioned before, Alex Sexton), for inspiration and assistance in getting something like this to work properly. As I said, my OOJS kung fu is not as strong as it is with closures, but I'm happy that this is a good solid solution that I can now start using in my code. Hopefully it'll help you make better, more graceful error handling code for your JS projects.

Why I don’t like HAML

getify — Thu, 04 Feb 2010 19:38:52 +0000

Disclaimer

Before I begin, let me share my personal mantra: “everyone is entitled to their own (wrong) opinions.” This includes me. This post is purely opinion. It’s an editorial. It means nothing unless you care what my opinion is. If you’re easily offended, or if you just love HAML, or if you’re a closed minded bigot, or whatever, just move on. Really.

I really don’t care what your opinion is on this topic, I just want to express mine, for the record, for posterity sake. And I’m not trying to convince anyone to use or not use HAML. I simply want to state the things I dislike about it.

I’m a fundamentalist, and I prefer simplicity in almost all cases. My bias toward performance, customization, control, optimization, and other such ethics should be evident from this blog already. This automatically makes me suspicious of “all-in-one” anythings. I’m the anti-framework guy. I’m the anti-platform guy. I’m the guy who wants the bare minimum in place to get my task done effectively. And I believe that in doing so, with as few layers of abstraction (and processing) as feasible and possible, you will end up with more performant code.

But this doesn’t have to come at the price of less maintainable code. It’s just that for years, the development community has strived for more maintainable code, and the only answer we’ve ever figured out collectively is to put higher and higher levels of abstractions on things.

Some abstraction is good and smart (we don’t write 0’s and 1’s, thanks @brandonaaron!!), but to the level that a lot of people take it, I liken it to using a pictures-only menu at a fast food restaurant. No offense to the foreign or illiterate, who I’m sure that is helpful to, but if you can read, you should. Pointing to the picture of a hamburger, then the picture of a ketchup bottle, then… this is inferior to just saying “Hamburger with ketchup”, if you can say that. Just my opinion.

Anyway, my goal with this post is to identify the fundamental approaches (not just nit-picking) of HAML that I dislike. Actually, to be fair, HAML is not the problem itself, HAML is just a symptom of the larger problem, convenient to help me illustrate some thoughts on templating as a discipline.

I’ll continue the discourse in subsequent post(s) with other opinions, and even some suggestions I have for solutions. Hopefully you’ll stick around and get something out of it. If not, that’s fine, too.

Brief overview of HAML

For those who aren’t aware, HAML is a templating language, apparently most closely associated with Ruby, that uses some “shorthand” to express HTML structures. It’s important to note that it’s more involved than a simple shorthand such as Wiki/markdown, as it appears aimed to be a full-fledged templating engine.

As it includes a templating “language” (a DSL, technically), it has the usual suspects, including variable replacement, logical selection operators, “sub-template” includes, comments, etc. It also allows/includes Ruby (or Ruby-like, not quite sure) syntax for more complicated logic, such as function definitions, looping, math operations, etc.

Let’s identify first the most important characteristics of HAML (at least, those relevant to my points):

HAML uses CSS-like shorthand to reverse-declare HTML tags. (HAML assumes a “
” tag type unless otherwise specified).
Example:
```
#mydiv
    %span.message
        Hello World
```
Would result in:
```
    Hello World
```
It’s easy to see how in this respect, the “shorthand” for the resultant HTML seems easier to write/maintain.
HAML uses whitespace indentation nesting to signal scope of tag blocks. This is critical for HAML being able to know where a block ends without needing closing tags, a big part of the “shorthand” being achieved.
```
#mydiv
    %ol#mylist
        %li.myitem
            Hello
        %li.myitem
            World
```
Results in:
```
    
        Hello
        World
    
```
Again, clearly the “shorthand” syntax has some appealing aspects, so far. If you like/don’t mind “whitespace sensitive languages” like Python and VB, you’ll be ok with using indentation in place of closing tags.
For more complex tasks, like math operations, dropping in variable replacements, calling functions, executing logic, etc, HAML allows you to use an = sign to signal a line of Ruby code to be executed in the context of the template parsing, with the output being added to the template at that point. (You use a – to indicate Ruby that should execute but which returns no desired output to include in the template).

Example:
```
- (42...45).each do |i|
    %p= i
```
Results in:
```
42
43
44
45
```
There are other variations of how to include/execute Ruby code as well. The point is, HAML tries to make it pretty easy for you to execute logic in your template, as long as that logic is Ruby. Also, they make one little buried warning in the documentation about encouraging you not to run Ruby logic which should be in the Controller. It’s not enforced in anyway, but I guess if you read and obey, that’s helpful.

There’s certainly more (a lot more, in fact) to HAML than this short list. I’m not writing a book on HAML (or anti-HAML) here, so I’m just trying to keep it to a minimum. But let’s just suffice it to say, there’s a few dozen different syntax rules, tag types, practices, etc that are required to use a HAML template for a non-trivial task like building a full dynamic web app page. Also, you’re going to have to know Ruby to get much more than simple “shorthand” HTML out of the deal.

My opinions

I’m going to assume if you’re still reading this blog post at this point, you’re here because you a) care about my opinions, or b) care enough to want to discredit my opinions. If you’re in group (a), read on. If you’re in group (b)… well… refer back to the first sentence of the post about my personal mantra.

Whitspace/indentation scoping

So, first off, I hate, absolutely detest, cannot stand, whitespace-sensitive languages. I cannot think of hardly anything in programming paradigms that irks me more than having to try and determine a set of logic context and having to count the number of indented columns (if they are spaces and not tabs, for instance) to figure out which blocks go together. This is doubly true if you choose to use like 1 or 2 space indentation, which I’ve seen at a couple of my previous jobs.

I suppose if you used 10 spaces for each indentation mark, it might make things obvious enough, but then you’re defeating the purpose of trying to use shorthand if you have to add and manage a bunch of extra characters to help make scope identifiable.

This brings up my counter opinion: languages like C and JavaScript use just 2 characters to identify blocks; the “{” and the “}”. This also makes it easier for code editors to give you helpful hints like highlighting closing and opening “tags”, and helping you know if you have unbalanced/unclosed elements, etc. I like this in JavaScript and C styled languages, so it natually should extend that I like this in HTML.

I don’t like complications

The above examples look really nice, and are probably the sweet spot for how HAML shines. But if you read the long form documentation, you’ll quickly see that there are lots of other complicating scenarios which you must learn to deal with. Indeed, HAML is not just shorthand convenient HAML, it’s a DSL with sytnax and rules and exceptions and gotchas all its own.

For instance, consider the case of wanting to add some attributes to a tag. Here’s an example from the documentation of the proper way to do it with HAML.

Say you want this HTML:

Just use this “little” snippet of goodness (makes me hungry just reading it):

def hash1
    {:bread => 'white', :filling => 'peanut butter and jelly'}
end
def hash2
    {:bread => 'whole wheat'}
end
%sandwich{hash1, hash2, :delicious => true}/

Uhhh, wait a second. I thought HAML was supposed to be shorter and simpler. I dunno about you, but this does not appear shorter or simpler to me. Maybe that’s just because I’m not a Ruby developer. Or maybe that’s just because at the point where I want to write HTML, I want to write stuff that looks like… HTML.

Moreover, if I have someone whose specialty is HTML and not Ruby, I really don’t want them trying to write such Ruby code. But maybe that’s just me.

When writing HTML, I should be writing… HTML

Perhaps I should state rather than just imply a bias I have here: if I’m in the mode of doing front-end (HTML) development (’cause I know a lot of us wear many different hats from front-end dev to back-end dev in our jobs), I want to think in HTML (not something else) at that point in time. Just like when doing back-end app development, or when building out database schemas, I darn sure don’t want to care (at that moment) about the eccentricities of cross-browser CSS and box-model support.

I think this kind of role separation (and thus skill separation) makes my job easier. It makes is clearer what I’m doing at any given point, instead of trying to blur syntactical lines between various technologies in the name of convenience.

I just find I work more effectively when I do only what is necessary for a given task at any one time.

Templates and Code Logic should not mix

I feel like this point is almost so self-obvious, I’m boring you by mentioning it. But yet time after time I see various platforms and frameworks (everything from .NET to Java to PHP to RoR to HAML to everything else in between) making exceptions to these rules, in whole or in part, and allowing (or even encouraging!) you to add some host language logic directly inside your templates.

I guess the logic follows that if you’re a Ruby developer, and you’re also tasked with doing front-end (HTML) development, you won’t mind mixing the two in your mind, using Ruby code logic to assemble your templates and data.

Well, that’s great until you hire a rock-star HTML/CSS guy to make templates who has zero knowledge of Ruby. I suppose you just hand him a Ruby book and say, “good luck.”? Or what about if you decide at some point to change the back-end platform technology you’re using from Ruby to say Scala or Erlang or PHP or whatever. What becomes of all your templates? Do you keep the Ruby based stuff, or do you ditch them entirely and re-write all your presentation layer as well?

And, btw, how does your development team make decisions effectively about what’s ok to be Ruby embedded in your templates, and what must be in the controllers? How do you train new developers to your team how to effectively make these decisions quickly right along side all your seasoned developers who’ve stubbed their toes on those topics for years? How do you decide, philosophically, if logic related to formatting (say a date or currency) is logic that should belong in the templates or in the controllers?

You see, in my opinion, all these questions are harder because you’re using a system that’s more flexible, more powerful, more complicated than it needs to be or should be.

Just because I can hammer a nail in with a sledge hammer doesn’t mean that’s the most effective tool for the job. If I have a little hammer suitable for the task, I think it’ll be more accurate and efficient to use it than the big sledge hammer. And that’ll also be true when I hand off the task of nailing things in to a new person who’s never used the sledge hammer before.

Point: You don’t need the power of Ruby to construct templates. If you do, you’re doing templating wrong. Again, in my opinion. Templating only needs a few simple constructs to be effective. Anything beyond that should be in your Controllers. At least, that’s what we were all taught in our CS classes when we learned about the proper Object-Oriented approach to MVC and we had it drilled into us that the “M”, the “V”, and the “C” should be separate. How quickly we abandon “separation” when it becomes too convenient in the heat of the moment.

I love this quote I just read on twitter: “good programmers appreciate the features you put in. expert programmers appreciate the features you left out.” (via KentBeck)

Portability

I’m also not a fan of having to use more than one templating system. By this, I mean, it is a reality of most (even mildly) complex web apps that there are two classes of templating: build-time (on the server) and dynamic (run-time, in the browser, with user input). Of course, various web apps have a different mix, and if you’re in the small class that is entirely one or the other and always will be, just skip over this point.

However, for the rest of us, almost nothing upsets me more than having to repeat myself. We’ve all heard DRY (don’t repeat yourself), but I don’t just quote that as a nice-to-have, I try hard to live by it in my development career. I am not 100% sure, but I’d hazard a good guess that it’s impossible to use the exact same templates (with Ruby logic and all) in both a server environment and a client environment. Moreover, even if there is a port (to JavaScript) of the HAML interpreter that could run in the browser (with alternate templates of course), this is of course two different separate copies of a templating engine that must be independently maintained.

A fundamental “law” in Computer Science is that anytime there is more than one copy of something, one copy is always wrong. That’s where DRY was born from. And it goes for tools as well as content.

You may be saying to yourself, “wait, that’s not possible with any templating engine.” Ahh, but it is! Stay tuned, in a (soon) future blog post here I’ll be talking about a templating engine I’ve built which can do just that.

You what technologies can and do run in both contexts? JavaScript and HTML. Anything other than that, and you’ve almost certainly failed this point. Game over.

One more thing

One last point of contention: I am unable to confirm how HAML handles “compilation” of templates. If it does so on-the-fly, every time, at run time (since it also has to execute Ruby code to drop in data), then this is more inefficient to convert from shorthand code to raw HTML each time.

If however it has some sort of two-pass compilation, where at build time you compile the shorthand HAML to raw HTML, and then at run-time you execute the embedded Ruby to drop in data, then this is probably a better approach efficiency wise.

Still, the point remains, that type of technique is important for performance, and it’s not very common amongst most templating solutions.

Enough already

OK, that’s enough ranting for one post. Again, the purpose here was to lay out what I don’t like about HAML. The underyling frustrations however are not specific to HAML but are true of many, many templating solutions. So up coming will be posts where I try to be more constructive and offer some solutions. Hopefully you’ll find this dialogue helpful. That is of course if you haven’t already written me off as being a crazy, eccentric, opinionated technology bigot.

A visual of page-load improvements (via LABjs)

getify — Thu, 03 Dec 2009 07:21:23 +0000

If you run a website but you’re not aware of Google’s free Webmaster Tools, you need to get in the loop! These tools allow you to analyze a number of important aspects of how your site is viewed/analyzed by Google’s search engine index.

Yet, with all the power and insight these tools give, it still feels like it’s best-kept-secret kind of thing that such tools even exist. I never hear anyone talking or writing about them. But I fire them up probably at least once a month to keep an eye on my various sites.

But the hush-hush of Google’s toolset makes it more exciting to highlight a really cool addition announced today, the new Site Performance tool. True, it’s still in development and very early on, but it already is showing the promise to give great new insights into how your site is performing out in the wild.

We all got the hint a few weeks ago that Google is planning to start considering page-load speed in its indexing algorithm. It would seem to be somewhat “evil” for the world’s largest search engine to start holding page-load speed against everyone’s sites without being part of the solution. So it shouldn’t be a surprise that the G would begin releasing various “tools” to help the rest of us actually make our sites load faster.

Bye, bye, birdie!

Yesterday, the Google Analytics team released a long-overdue update to their suggested snippet for including “ga.js” in pages. They wisely ditched the horrid “document.write()” approach that has been the standard for the longest time, in favor of this new asynchronous loading technique. The reason? Quite obviously, this now will unblock the loading of GA from page loads, thus preventing Google from being at fault for slower load times!

Side Note: the suggested code that Google has released has been shown not to be safe with all page structures in some browsers, including (ironically!) Chrome, and Opera. The problem is a faulty assumption that “document.documentElement.firstChild” will always return a reference to the HEAD element to append the