So I was monkeying around, and I decided to write a function to determine if a string were a palindrome. This is not a very difficult problem, but it might make for a descent introductory interview question (one of those questions you'd ask to rule out the truly inept).

With problems like this, I'm mostly interested in two things:

1. Writing the function in a clever way, so as to achieve the least amount of code possible
2. Writing the function in the most efficient way possible

Now, if it were Ruby, writing the clever solution (which might also happen to be the most efficient solution in that language -- not sure) would be ridiculously easy:

That's so trivial, it's probably not even worth writing.

But Javascript doesn't have a .reverse() method on strings, so you have to take an extra step (still pretty easy though):

Split the string into an array, reverse the array, and then join it back together. Since this is all native Javascript stuff, it turns out to be reasonably fast, though one might expect you could do better.

For grins and giggles, I decided to see how a manual solution, where I compare characters starting at each end of the string and work towards the middle, would compare:

This function will probably fail quickly, so that's good, but it also turns out to be generally faster than the split/reverse/join version. It makes sense, since you're going through the string only one time and twice as fast as normal since you're traversing from both ends at the same time.

Can you do even better though? Maybe. At least in Firefox you can, and quick tests seemed to confirm across other browsers too (but I didn't test extensively).

What if we split the string in half, and only reverse half of it. Then we can compare the first half with the original half:

The idea here is just split the string in half, reverse one of the two pieces and compare them. For example:

TOOT: splits into "TO" and "OT." Reverse one of them, say the second part ("OT") and compare.

If you've got a odd number of characters, you can ignore the middle most character:

RACECAR: splits into "RAC" and "CAR" (ignore the "E" in the middle). Reverse the second part ("CAR") and compare.

As it turned out, this seemed to be faster than the other two methods. Not by orders of magnitude, but not insignificantly either. Here are the number from Firefox, running each function 10,000 time on the string "gohangasalamiimalasagnahog" (go hang a salami, i'm a lasagna hog).

• (Traverse from both ends): 797ms
• (Split/Reverse/Join): 969ms
• (Compare halves): 640ms

Of course, numbers varied slightly during each run, but overall the they were consistent relative to each other.

So there ya go. Nothing in particular I wanted to point out here; just found it interesting and thought you might too.

Think my code sucks? Got a better solution? Say so in the comments (you won't hurt my feelings).

I was writing a script that dealt with images and I needed to know when an image had finished loading. Simple enough. Using Gimme (or your favorite addEvent(..)) equalizer the code looks something like:

It turns out that my load handler wasn't always firing in IE (in Firefox it worked consistently). The solution though is super simple.

You just need to make sure that you wire up the load handler before setting the image element's .src property. Why? Because if the image is being loaded from cache, IE (and Opera too) will load the image instantly. In fact, it will have finished loading the image before your load event handler is even wired up, which means, it won't fire!

Just change the code to something like this:

And there you have it.

Nothing earth-shattering and probably common knowledge for a lot of scripters, but a little refresher never hurts.

Auto Detach with 'unload'

In IE, if you wire up an event listener and fail to remove that listener when your page unloads, you're probably asking for a leak. One effective technique to ensure that listeners get removed is to wire up an 'unload' event to the window which detaches the listener for you. For example:

Keen readers might have noticed that I solved one problem (removing the 'click' listener from elem) by creating another one (attaching a new, anonymous listener to the windows's 'unload' event).

Why is this a problem?

In a previous blog entry, I mentioned that it wasn't possible to remove an event listener if that listener were anonymous, as in:

While it's true that the above code won't work, it's not entirely true to say that it's impossible to remove an anonymous listener. Why? Because every function actually has a reference to itself through its own arguments object. Specifically, through the .callee property of the arguments object.

We can use this to our advantage to detach the anonymous 'unload' listener from within the listener itself.

Why not just un-anonymize?

You certainly could just name all of your functions and then refer to them by name, but sometimes anonymous functions are very useful since they allow to create closures and do other nifty Javascript tricks. In those cases where it's desirable to use an anonymous function, this technique might be just the ticket!

Conclusion

I've conveniently (for me anyway) left out any non IE-specific code in this post. It's worth nothing that I don't generally use this technique except in IE, which means a little cross browser code is in order to ensure that this 'onunload' technique is only used for that browser.

Of course, it isn't going to hurt anything for other browsers (and it might even help) so there'd be no harm is using it across the board, bu you'll still need to write some cross-browser code (obviously). I'll leave that as an exercise for the reader though.

Happy scripting.

Comments welcome.

Recently, Kristoffer did a significant amount of investigation to track down a nasty IE memory leak issue. IE's problems with memory leaks are well known, but most of the time, you'll hear people saying things like "closures are the cause of memory leaks," or "failing to detach events is what causes memory leaks," and (probably the most common), "circular references are the culprit -- they cause memory leaks."

To some degree, all of these things are true. Closures can sometimes lead to memory leaks, failing to detach events can also lead to memory leaks, and yes, circular references to DOM elements can also be the cause of memory leaks.

One kind of leak that seems to get a little less attention though, is the one involving .innerHTML. Fortunately (thanks to Kristoffer's investigation) this one is pretty easy to deal with.

Before we can deal with the leak, we need to understand what causes it. Three conditions are required:

1. A orphaned DOM element must exist in memory.
2. That element's innerHTML must be set to a string of markup the creates an element with some DOM 0 event wired up.
3. The aforementioned innerHTML property must be set before the orphaned DOM element is "unorphaned" (added to the page).

If these conditions are met, get ready to call the (Javascript) plumber, because you've got a leak!

To make things a little less abstract, I'll write some code and explain piece by piece, how it fits the conditions above:

As you can see, the code above is not at all an uncommon scenario. Chances are though, if that's all you've got, you won't notice much of leak. This issue really only manifests itself when multiplied, that is, when you set .innerHTML in the above manner over and over and over again on the same page.

Why would ever do this? Think Web 2.0, think AJAX, think dynamic page updates and you probably won't have to search too hard to find a situation where someone might do this. Maybe you already know of (or helped write) a Web 2.0 app that does this.

Memory Leak Demo Page

Anyway, when above pattern is multiplied (whatever the reason) memory leaking chaos will ensue. To illustrate the problem, I've put together a sample page with a script that creates a orphaned <div> element, whose .innerHTML is set to a string of 2000 <a> tags with onclick events. When you click the "Start Leak" button, the script executes repeatedly, until you click the "Stop Leak" button. This give you a chance to use Perfmon to monitor memory consumption and see the results of the leak. The memory leak demo page can be found here.

The solution

It turns out, the solution is actually pretty easy: simply make sure to set .innerHTML after appending the DOM element to the page. That's it!

To see that this really does take care of the issue, I've put together another test page. In this one, the .innerHTML property is only set after the DOM element has been added to the page.

If you click the "Start Leak" button on each page and let it run for about 60 seconds or so, you should notice that the first page continues to consume more and more memory as time goes on, whereas the second page's memory consumptions remains relatively constant.

Demo Links

In case you're the kind of person who doesn't like to read paragraphs to find embedded links (I'm like that), here are the links to the two demo pages, for your convenicne:

• Leak Demo
• No Leak Demo

So there ya go: a nasty bug, but thanks to Kristoffer's work tracking tracking down the exact causes of this leak, a fairly easy one to handle.

Comments welcome.

It appears then, that null is interpreted as zero when used in mathematical expressions, which I guess isn't totally illogical (but certainly not what I expected).

A tad more digging and I found (not surprisingly) that this phenomenon is not limited to null. Turns out that many (but not all) "false-like" values are interpreted as zero in mathematical expressions (NaN and undefined being the two exceptions that I noticed):

It's also good to be aware that NaN is "toxic", meaning that the result of a mathematical expression will gravitate towards NaN if it shows up anywhere in the expression, directly (as in the last example above) or indirectly (as in the last two examples shown below):

What it means for you

Nothing earth-shattering really -- just that you should be careful if you're using isNaN(..) to find out if something is numeric or not. One thing you can do that (I think) is fool proof is first call parseInt(..) on the value in question and then call isNaN(..) as in:

This works because parseInt(..) of null is NaN, which of course, will return true when using with isNaN(..).

That's it. Nothing ground-breaking; just something good to keep in the back of your mind so that you spend a few less minutes scratching your head next time your run into it.

Comment welcome.

One concept he writes about that I particularly like is that of "branching." I've never actually heard it called that before, but it's a very sound concept and one that I doubt is being utilized often enough by today's Javascripters.

What is branching?

Put simply, branching (in Javascript) is the use of closures to get the browser to interpret a block of code only one time, when otherwise, it would interpret that block over and over and over again (presumably, each time you call your function).

Why would you want to do this? Because, when it comes to cross-browser code, chances are you have a lot object detection code whose primary purpose is to determine if the browser supports a particular feature/property, like this:

The above is a very simplified version of a cross-browser addEvent(..) function that takes care of (some of) the differences in event models between IE and W3C browsers. This is all well and good, but consider what happens when I do the following:

Five thousand times the browser is checking: if (typeof elem.addEventListener !== 'undefined')... -- once for each element in the elems array! Gosh, that feels like a waste, doesn't it? Wouldn't it be good if we could somehow tell the browser: Hey browser, once you've figured out that .addEventListener(..) is supported, don't bother checking again for the next 4999 iterations!?

It turns out you can achieve something like this, through the use of branching.

Branching in action

In a sense, branching is a lot like conditional compilation. Similarly to the way you can use #ifdef directives to instruct your C-style programs to conditionally compile certain blocks of code into your executable, branching allows you to conditionally "compile" (as it were) certain blocks of code into your Javascript.

This is accomplished by creating separate functions that contain your cross-browser logic and then wrapping them up inside of another function, which will return the appropriate function when executed. The nifty part though, is that this outer function will only be executed one time (that's the sort of "conditional compilation" part).

An example should help illustrate this:

In the preceding example, I've separated out the logic for IE and W3C browsers into two separate functions. Those functions have been declared within the scope of the addEvent(), so they're not accessible from outside.

The most critical thing to notice though, is the use of }(); at the very end of the code. It's important to realize what's happening here. We're declaring a function, addEvent, with the code: var addEvent = function() {, and then we're immediately executing that function at the end of its declaration with }();.

What it means for you

This means that as the Javascript interpreter is parsing your code, it will execute the addEvent() function right away, whose logic instructs the browser return one of two functions (but not both)!

The net effect of this is that addEvent will be equal to ie_addEvent when IE is being used, and it will be equal to w3c_addEvent when W3C browsers are being used. In either case, the browser only needed to execute the if-conditional one time. Beautiful!

You can prove to yourself that this works, but simply executing: alert(addEvent.toString()) in both IE and in a W3C browser. Notice that you'll get the proper function for each browser, but that neither function includes any if (typeof blah_blah_blah)... checks.

Conclusion

It's no surprise that this is going to be much more efficient than the original addEvent(..) function, which did not utilize branching. After all, it's 4,999 fewer if (typeof ...) checks for the browser to execute!

This concept isn't necessarily limited to cross-browser code either. Branching can be useful in lots of situations. As always, I'd recommend analyzing your particular situation and determining if branching is going to beneficial for you (chances are, it will).

If you haven't already, be sure to check out Dustin's article. Besides branching, he covers six other useful techniques that every Javascripter should be aware of.

Comments welcome.

The above code will work in just about every browser under the sun, including IE, but of course, it's the simplest case scenario for the .split(..) function. Many programmers will probably be aware that you're not limited to passing in a string; you can also pass in a regular expression, which IE (mostly) supports, but this is where things can start to fall apart on you (in IE anyway).

Read on to learn more.

The .split(..) function is pretty robust. You can pass in a simple string, which indicates what character (or characters) you want to use use as a delimiter, or you can pass in a regular expression instead of a string. Take the following example:

In the above example, the string, s will be split by any of the characters: "~", ".", or "-". The regular expression makes this really easy to do. But one thing you'll notice is that the delimiters themselves are not captured. This might not be a problem for you; in fact, you might not want the delimiters captured, in which case no problem. But suppose you do. Suppose you want the result of your split to be:

In that case, you need to modify your regular expression, and unfortunatly, the needed modification isn't going to work in IE. Here's how's you'd accomplish it in most other browsers (it's remarkably easy).

You'll notice (or maybe not, since the change was so minor) that I didn't have to do much to get the desired result. All that was needed was wrapping the contents of my regular expression in parenthesis, thus indicating a regular expression grouping.

Unfortunately, in IE's implementation of .split(..), it completely ignores the grouping request. So while your result will still be an array split by the requested delimiters, those delimiters won't be included in the array!

So, what do we do when IE won't cooperate with with us? Why, we beat it into submission of course, and here's how.

The .xSplit(..) function

I call it xSplit(..) because it's a sort of "eXtended" version of the native .split(..) function. Anytime I'm writing/enhancing a version of a function that already exists, I like to use the "x" to help my eyes quickly distinguish between the preferred native function and my own custom implementation (actually, I don't really do that; I just made that up now, but it seems like a reasonable idea, so maybe I'll start!).

The xSplit(..) function will work more or less like the native function, with just one small difference: it will only accept regular expressions. Strings won't be accepted; the native .split(..) function for that.

Here is the full code, with an explanation to follow.

Explanation:

The code isn't too hard, but it's worth pointing out a few specific points.

First, I'm extending the native String object using .prototype. I know some people aren't comfortable with this, and if you're one of them, feel free to write a stand-alone function where you pass in a string variable, as well as the regex.

Second, Most browsers actually will capture the delimiter when you use regular expression grouping, so if the client happens to be using a browser that can do it, we'll want to use the native implementation, as it will be much faster. We do it like this:

The above code does a very simple test in which we check to see if the split of "a~b" on the character "~" returns an array of length 3. If so, we assume support for regular expression grouping with the .split(..) function. Otherwise, we're forced to do this manually.

Now, if we do need to do this manually, the regular expression had better have its global (/g) flag set. Why? Because we're executing a .match(..) on the _regEx later on in the code, and in order for that to match more than just the first delimiter it finds, that global flag needs to be set.

This code first checks to see if the global flag is already set. If so, we're good shape; no need to make any alterations. If not, we'll need to set it. Problem is, the .global property of any regular expression object is read-only, so we must construct a new RegExp using the .source of the original _regEx and manually specify the global flag (by passing in a 'g'). Additionally, we need to make sure we maintain any request in the original regular expression to ignore case, which is accomplished with: (_regEx.ignoreCase ? 'i' : '').

The rest of the logic is pretty straight-forward. We loop through the given string, building, character by character, the strings that will make up the individual string elements in the array to be returned. At each iteration through the loop, we'll test (using .match(..)) to see if the string we've built so far, contains any of the delimiters specified by the passed in _regEx. If so, we need to push that string into the array, but we need to strip the delimiter out of the string before we do (hence the code: arr.push(str.replace(m[0], ''));).

We also need to push the delimiter itself into the array and then reset the str variable back to an empty string.

Final thoughts:

It's worth pointing out that compared to the native .split(..), my implementation is slow! So, whenever you don't need to capture regular expression groupings, stick with the native function. Of course, for browsers that support the feature natively, we'll be using the native .split(..) under the hood anyway, but regardless... if you know you won't need groupings, don't bother with .xSplit(..).

Comments welcome.

Some would say this is a good thing because "goto is evil." I don't have a problem with the fact that there is no goto statement in Javascript. I do, however, have a problem with people who unconditionally think "goto is evil."

I for one, do not think goto is (always) evil. Oh it can be, don't get me wrong. But it doesn't have to be, and you shouldn't automatically assume that it is.

Donald Knuth's Structured Programming with go to Statements ... analyzes many common programming tasks and finds that in some of them GOTO is the most optimal language construct to use.

Still, as Joey Tribbiani says, "it's a moo point (like a cow's opinion; it doesn't matter)," because there is no goto statement in Javascript.

Why all this talk in a Javscript blog about something that doesn't exist in the language? Because Javascript provides an alternative. One that, if you're me, your coworkers will criticize you for using (even though it made perfect sense and actually enhanced the readability of the code!)

Read on to learn more.

The labeled continue

Labeled continue is a perfectly valid language construct in ECMAScript-262 (Edition 3), and yet, I caught hell and had to fight a bitter battle in order to be able to use it.

The scenario? I was dealing with a nested loop. The outer loop was iterating an array of objects. Those objects happened to be arrays themselves which also needed to be traversed.

To make the example a little more concrete, let's pretend the outer array was an array of "Pastures." Each Pasture contains many "Cows." The idea was to loop through the array of Pastures checking to see if all the Cows in that Pasture were done eating (work with me here). If so, we'd fire a callback function to let Farmer Ned know that all the Cows in Pasture X were done eating.

Simple enough right? All we need to do is loop through the Pastures, check each cow in the given pasture to see if it's done eating, and only if all cows are done eating do we fire the callback function.

For efficiency, I decided to test the cows to see if any one cow was eating. If so, I could abort the remaining checks.

Here was my take:

Of course, as soon as the code-review process started, I got one developer and two PMs (PMs no less!) criticizing my use of "goto."

What bothered me wasn't so much the criticism of my code (heck, that happens all the time). What bothered me was that they automatically rejected it when they saw the labeled continue (without stopping to think if this might not actually make some sense!)

Now, I'm well aware that you could accomplish the same thing by creating a boolean variable, allDoneEating, which is initially true and which only gets set to false if some cow.isEating() statement returns true. Then you'd have to add an additional check outside of the inner for-loop, but inside the outer for-loop to see if the allDoneEating boolean were true, and if so, you could fire the callback function.

Phew! It was hardly worth typing that out.

Why in the world would I want to go through all that extra effort when a simple little continue pastureLoop; will do just fine?

Furthermore, what could be more readable than continue pastureLoop? It very clearly and very succinctly describes the fact that, if any cow is eating, we want to continue with the pasture loop!

I dunno, maybe it's just my own crazy brain that works this way, but I think the labeled continue is a clean and elegant solution in this particular case, and I don't see any reason why it should be shunned in favor of creating an extra boolean and requiring an extra if-conditional.

The labeled break:

I've done a lot of ranting and very little coding in this blog post, so to end, I'll offer a quick example of a similar construct to labeled continue: labeled break.

For this code snippet, I'll return to the cow example, but with slightly different requirements. This time, we want to know how healthy our cows are. We're going to loop through each pasture counting the number of healthy cows we can find until we find a sick cow, at which time we want to abort the entire process. A labeled break makes this really easy

And again, you could of course accomplish this without a labeled break. Depending on the complexity of your situation, might want to avoid the labeled break, but then again, it might be just the thing!

If there's anything I hope this post conveys, it's that you shouldn't unconditionally rule out any valid language construct just because a few naysayers claim that it's "evil." Analyze your situation, think about what you're trying to accomplish, and make a decision that's appropriate for your situation.

Happy ECMAScripting

But I'm guessing you probably haven't ever used it like this:

What's going on here? Isn't the result of a Logical AND/OR a boolean value?

Read on to learn more.

In Javascript, Logical AND/OR don't always return true or false. In fact, it wouldn't be inaccurate to say that they never intrinsically return true or false.

Here are the two basic rules:

• For Logical AND (&&): Javascript returns the first value that is "false-like", or the last value, if no values are "false-like".
• For Logical OR (||): Javascript returns the first value that is "truth-like", or the last value, if no values are "truth-like".

What is "truth-like"? It's any value in Javascript that, while not explicitly true, evaluates to true when used in an expression. This would be essentially anything that isn't "false-like" (more on that in a moment). Examples include:

• 5
• 'Steve'
• new Object()
• {}

The list goes on infinitely.

A "false-like" value is any value that evaluates to false in an expression. I think most people are pretty familiar with this one. It's precisely because of this that statements like:

actually work. The value of myDiv.addEventListener is neither true nor false, but it will treated as a "truth-like" or a "false-like" value, depending on whether or not the browser in question supports it.

"False-like" values include:

• null
• undefined
• ''
• ""
• 0
• NaN

Now, you can get along (presumably forever) without actually ever understanding the subtlety with which Javascript treats Logical AND/OR. Chances are you're going to end up with just the results you expect (especially if you restrict your use to if-conditionals). But, if you happen to know Javascript's unique handling of Logical AND/OR (and now you do), you can leverage it to slim down your code and, in some cases, make it more elegant.

We've already seen on example of this back at the beginning of this post. We leveraged Logical OR to provide a default value for a function parameter. This is definitely one of my favorite techniques. Not only does it cut down on the amount of code you need to write, but it reads really well to. When I see something like this:

I read that as: "x will be equal to n (if n is a valid value) or 100 (if n isn't valid)."

The real-world use for leveraging Logical AND in this way is probably a lot less. I can't think of too many scenarios in which you'd want the value of some variable to be the first "false-like" value in a list of values. I suppose you could use it to control program flow as in:

In the above example, the foo() function will execute, if x is "truth-like" (which it is in this case). The problem is, you generally want to execute a function conditionally, based on some much more specific proposition (i.e. x > 0). You can't get anything that specific from Logical AND. In this example, foo() would execute if x were any of: 'Steve', {}, -1, 0.04 (and of course, any other "truth-like" value).

My recommendation would be to simply understand how Javascript treats Logical AND, but I wouldn't recommend trying to leverage it as a "short cut" -- it'll probably just make things more confusing. When it comes to short cuts, stick with using Logical OR to provide default values for function parameters.

Of course, if anyone does know of a way to leverage Logical AND to do something creative and/or elegant, I'd love to hear it. Feel free to send me your comments.

Run the above code snippet, and you'll get an alert that says 'steve_99'. It sort of feels like the variable s should be undefined, but it's not. I'm sure there are lots of Javascripters who already know this, but I'm also pretty sure there's also a few who've never noticed this.

Is this always the case? Do all variables created with var end up being essentially global variables? Not exactly.

So in what scenario does variable scoping act that way you'd think it would in Javascript? It's pretty simple actually. All variables created with var are global variables (within their scoped context). Only functions (which in Javascript are objects) and the global object (which in web browsers maps to window) have variable scope. An example will help illustrate:

This is much more natural and (I think) what most programmers expect. We can combine first example and the second and it should be pretty easy to see what's going to happen.

So, as expected, x is still undefined (outside of the function foo()). And s, having been created with var is still "global". Global, that is, in the scope context of the foo() function.

What does this mean for the average Javascipter? Well, it just means you should be careful. Don't be fooled into thinking a variable has gone out of scope, when in fact, it has done no such thing.

Given Javsscript's (somewhat peculiar) handling of variables, you might suggest then, that there is no point in following the typical programming style of declaring variables as close to where they're first used as possible. I know Douglass Crockford believes you shouldn't do this in Javascript. A part of me agrees, but I still tend to do it, just because it helps me, personally, with readability. I can certainly understand the argument though, to do as Mr. Crockford suggests and declare all of your variables at the beginning of your functions.

What's interesting, is that while I haven't really gotten in the habit of doing this, I have gotten into the habit of not declaring looping variables inside of for loops (though admittedly, this is contrary to my above examples). But in most real-world scenarios, I tend to do this:

And not this:

I declare the i variable outside of the for loop for just the reasons we've been considering in this post. Since, after the above code executes, i will still be a valid variable with global scope, I prefer to write my code so that it looks that way. It's just too easy to look at the above code snippet and think that i is confined to the scope of the for loop (it's not).

I'm curious to know what other people think about this. I generally don't ask questions in my blog posts (and this probably more to do with the fact that i don't get a ton of traffic (yet) than anything else, but I figure... what the heck, I'll break my normal rules this one time.

What does everyone else prefer and why? What advantages and disadvantages do you see, and what programming notations/styles do you use to help keep variable scoping easily understood and readable in your code?

If you have thoughts on this, I'd love to hear them.

Comments welcome.