Falsies

We call values that loosely evaluate to false “falsy.” What does “loosely” mean in this context? There are two comparison operators to test equivalence in JavaScript (== and ===). The first is loose, and the second is strict.

The results of the loose form are sometimes surprising, as you’ll soon find out.

What sorts of things are falsy? Douglas Crockford lists these: 0, NaN, the empty string(” or “”), false, null, undefined. In essence, they are the zero or false or empty versions of JavaScript’s various types.

Tripped Up

The worst trouble I have with falsy values are when I’m comparing to a number and I forget that 0 might be one of the numbers I’m going to get. I did this recently in my sorting post in the final bit of code. I used == when I should have used ===. (Note: I’ve since fixed the code in that post.)

I’ve had this blog post in my mind for about a month. I’ve been waiting for a stroke of brilliance to come so I could make all this falsy stuff completely clear once and for all. The stroke of brilliance never came, so I’ve decided to make a table for you that tell what falsy values loosely and strictly equal other falsy values.

== / === false 0 NaN null undefined “” (empty string) ” ” (white space) [] {}
false yes/yes yes/no no/no no/no no/no yes/no yes/no yes/no no/no
0 yes/no yes/yes no/no no/no no/no yes/no yes/no yes/no no/no
NaN no/no no/no no/no no/no no/no no/no no/no no/no no/no
null no/no no/no no/no yes/yes yes/no no/no no/no no/no no/no
undefined no/no no/no no/no yes/no yes/yes no/no no/no no/no no/no
“” (empty string) yes/no yes/no no/no no/no no/no yes/yes no/no yes/no no/no
” ” (white space) yes/no yes/no no/no no/no no/no no/no yes/yes no/no no/no
[] yes/no yes/no no/no no/no no/no yes/no no/no no/no no/no
{} no/no no/no no/no no/no no/no no/no no/no no/no no/no

In the table above, you see the result of each value when compared loosely (with ==), then when compared strictly (with ===). The next table tries to convert each value logically by negating the negation of it.

value !!value
false false
0 false
NaN false
null false
undefined false
“” (empty string) false
” ” (white space) true
[] true
{} true

Eye-Popping Results

Most interesting observations from the tables? How about NaN, which doesn’t even loosely equal itself? The empty object {} is the same way. They are the ultimate Dr. No’s. Interestingly, the empty array loosely equals false, 0, and the empty string.

A string of white space loosely equals more than I thought it would.

0 and false are pretty damned close to each other.

According to the first chart, NaN, null, undefined, and {} are not falsy, because they don’t equal false in a loose comparison. In the second chart, ” ” (white space), [], and {} and not falsy.

So, now you know why it’s safer to use ===. If you find a good use for ==, make sure you’ve thought hard about things that might go wrong. I might even go so far as to say you should comment every usage of ==, because it’s bound to be misunderstood in many cases.

Can you tell falsies when you see them? I used to think I could, but now I’m not so sure.

Do While Once in a While

The other day, a programmer I follow on Twitter was pleased because he had found a good use for a do/while loop.

When a programmer gets excited by a loop construct, you know something is wrong. The truth is that do/while is underutilized, not just in JavaScript but in all C-based languages.

The rule of thumb is that you should use always use a do/while loop when the body of the loop must execute at least once. Use a while loop when the body of the loop may never execute.

Maybe it’s true that a while loop is indicated more often than a do/while loop, but I’ve often seen programmers do a little jury-rigging to patch up the while loop to do their bidding when a do/while would have meant less typing and have made more sense.

Why? Well, programmers get into habits. If you get to know while very well, you may be shy about using do/while.

But I think there’s some clumsiness inherent in do/while that also plays a part in its unpopularity. It’s a result of JavaScript getting its syntax genes from C rather than the Wirth family of languages. Pascal and the others (Modula-2 and Oberon) used repeat/until

    JavaScript
do {
  a = a + 1;
} while (a!==10);

    Pascal
repeat
  a := a + 1
until a = 10;

I think repeat/until is superior to do/while for these reasons:

  • In JavaScript, the reuse of the identifier “while” is awkward. When you see it, you tend to expect the loop body to come after it. See how it just sits there AFTER the close brace? Like a teenage boy avoiding a girl at a middle school dance.
  • do/while‘s ending condition is the same as while‘s starting condition. Pascal’s until condition is logically negated, which I think is more natural at the end of a loop. Do something over and over UNTIL something is true, rather than do something over and over WHILE something is true. REPEAT UNTIL i hits 5, rather than DO WHILE i is less than 5. A possible solution would be to allow do/until as well as do/while. This would allow for backward compatibility. Someone remind me I said that the next time I invent my own computer language.

In short, the do/while construct just doesn’t sit quite right in C, encouraging the overuse of the while loop, which sits just fine. In any case, repeat/until seems to get more use in Pascal than do/while gets in C.

Don’t forget do/while is there, waiting for you to be excited to use it. It’s the right choice when you must execute the body at least once.

Sort of Confusing

Some of the worst JavaScript code I have seen has to do with sorting data.

JavaScript has a flexible array sort method, but it takes a while to get the hang of using it. Programmers seem to do fine sorting a simple array, but if the data format is something just a bit less trivial, many JavaScript programmers throw their hands up in the air. You can almost see the frustration in the code (sometimes in the comments).

One common situation that many people seem stumped by is sorting an array of objects based on a given key.

Suppose we have this array of objects:

    arr[0]={r:100,g:100,b:250};
    arr[1]={r:50,g:127,b:255};
    arr[2]={r:255,g:255,b:100};

Now suppose you want to sort the array by any of r, g, or b, and that you want to support both ascending and descending sorts. How would you approach the problem?

Back To Basics

Remember that to sort an array, you just invoke the “sort” method that belongs to JavaScript’s array type.

    arr.sort();

That works for sorting an array of strings, but it doesn’t work for sorting an array of numbers. That’s why even the novice JavaScript programmer recognizes the code for sorting numeric values.

    function sortNumber(a,b) {
        return a - b;
    }

    arr.sort(sortNumber);

JavaScript lets us pass in a function that is used to judge whether a value is less than, equal, or greater than another value.

Having that hook into the guts of the sort method lets us solve just about any sorting problem. But how?

Here’s a solution for the {r,g,b} problem above, where I want to be able to sort on r, g, or b in either ascending or descending mode.

    function sortByKey(arr,key,direction) {
        function sortNumeric(a,b) {
            if (direction=="ASC") {
                return a[key]-b[key];
            } else {
                return b[key]-a[key];   
            }
        }       
        return arr.sort(sortNumeric);
    }

The outer function is a handy way to keep the key (what we’re sorting on) and direction (which way we’re sorting) around, since there is no simple way to pass that information into the sort method. Remember that the inner function has access to the outer function’s variables, and that includes the parameters that come in.

Oh, by the way, the code is easier to understand if you recall that obj.r is the same as obj[“r”]. We can pass in a string to a function and use that string as a key to get a value. That way we get around the need to write a separate evaluation function for each key.

Call the function like this:

    sortByKey(arr,"r","DESC");

to sort the objects in descending r order, or

    sortByKey(arr,"g","ASC");

to sort the objects in ascending g order.

Real Life Intrudes

Sometimes the data is not nice. You may have blank (empty or missing) spots in your data. In Excel, whether you sort ascending or descending, cells that are empty always show up at the end of the list. I recently needed to match that functionality in an Adobe AIR utility program I was writing. Here’s the code (blank cells from Excel ended up as empty strings in my data).

    function sortByKey(arr,key,direction) {
        function sortNumeric(a,b) {
            var c=a[key],d=b[key];
            if (direction=="ASC") {
                return (c==="")-(d==="") || c-d;
            } else {
                return (c==="")-(d==="") || d-c;   
            }
        }       
        return arr.sort(sortNumeric);
     }

A bit longer, codewise. But exactly what I needed for my data.

Once you get the hang of using inner functions, JavaScript’s sort method makes much more sense. It’s easy to extend this idea to accomodate other kinds of data (like strings), or to support secondary sorts, where a second key can be used to break ties.

9007199254740992

After my discussion of JavaScript’s numeric limitations when working with integers, I was curious. There must be some integer that’s the biggest one that JavaScript can represent.

A brute force method (my favorite kind) would simply increment a variable and see when it stops going up. Add one. Add one. Add one. Stuck.

That number is so large, though, that even I didn’t have the patience to wait for the loop to end. So I broke the problem up into two pieces.

First I set a variable to 1. I keep doubling it until I find a number that is the same as that number plus one. That’s my high limit and half that number is valid.

Then I do a binary search inside that range. The code looks like this:

    a=1;
    b=2;
    //find one that fails
    while (a!=b) {
        old=a;
        a+=a;
        b=a+1;
    }
    //do binary search
    low=old;
    high=a;
    while (high-low>1) {
        mid=parseInt((low+high)/2,10);
        a=mid;
        b=a+1;
        if (a==b) {
            high=mid;
        } else {
            low=mid;
        }
    }
    console.log(high);

The answer is 9007199254740992. Something over 9 quadrillion. Makes more sense why it would be a limit when you look at the number in hexadecimal. That’s 0x020000000000000.

That’s right. JavaScript can tell the difference between 9007199254740991 and 9007199254740992, but it thinks that 9007199254740992 and 9007199254740993 are the same. That falls out from the IEEE-754 double-precision floating-point spec that JavaScript uses to represent all numbers.

Remember that next time you want to write a for loop that counts to 10 quadrillion–it’s an infinite loop. You’ll never get there.

JavaScript Numbers Can Bite

Sooner or later, JavaScript’s numbers will bite you. They bit me in a probability function, and I didn’t even see it coming.

Maybe you took a probability and statistics class and learned about combinations and permutations. You may remember that the formulas for those involve factorials. Let’s take a look at my combination routine.

    //---------------------------------------------------------
    // Function: combinations
    //   returns the combinations of k objects from a set of n objects
    combinations=function(n,k) {
        function factorial(a) {
            return a<2 ? 1 : a*factorial(a-1);
        }
        return Math.round(factorial(n)/(factorial(k)*factorial(n-k)));
    }

Kind of an interesting looking function, isn’t it? When you find the number of possible ways that you can put together a k objects from a set of n objects, you need to do three factorial functions. Since I didn’t need factorial anywhere else, I stuffed it inside the combinations function.

But what’s the Math.round doing there? Aren’t we dealing with whole numbers here? Yep. In most languages, we’d explicitly declare the variables for this function to be integers, but that’s just not an option in JavaScript–all numbers in JavaScript are floating point numbers.

Trouble Ahead

So where do we run into trouble? If n is 23 and k is 2, combinations returns 253.00000000000003.

Even more frustrating is this answer because it’s one we can come up with off the top of our heads: If n is 24 and k is 23, we get 23.999999999999996.

What’s happening? Our numbers are growing so large in factorial that they can no longer be represented exactly in JavaScript. The solution? In this case, I fix the result with Math.round().

Playing Computer

But we can do better if we play computer with even a small case. Let’s take n=5, k=2;

combinations=(5*4*3*2*1) / ((3*2*1) * (2*1));
//largest number calculated is 120

That could be changed to

combinations=(5*4) / (2*1);
//largest number calculated is 20

A huge change. Much better. Three floating point operations rather than nine. Less chance for mischief.

Factorial is a well known function, and the combination formula is easy to write in terms of factorial, but that ease of representation comes at a huge computational cost, and in the case of JavaScript, sometimes a cost of precision.

If we rewrite the function to take advantage of this insight, we’ll be able to support much larger parameters before we run into trouble.

The General Idea

The solution to most of these problems is to rearrange the math so intermediate results don’t get as big.

This was a nasty problem to catch, because many results were calculated correctly. But it didn’t take long to come up with a couple solutions.

Welcome Mr. Future JavaScript Programmer

Your mission: You are a Web 4.0 programmer from the future. For some reason we cannot possibly comprehend, you have come back to 2008 to impregnate your grandmother.

While you’re here it’s crucial to your mission that you also write a Web 2.0 app. Difficulty? Working in our ancient dialect of JavaScript. Solution? Mascara.

No, you don’t wear it, you use it.

Mascara is a program that translates tomorrow’s JavaScript into today’s JavaScript.

It’s been mentioned in some of the big JS venues like here and here, but I’ve been watching since and the author is really knocking the cover off the ball with new releases. I want to make sure he gets the attention he deserves.

Here’s the site:

http://ecmascript4.com/

And here’s the blog where you can read his changelist:

http://blog.ecmascript4.com/

What’s This All About?

JavaScript moves slowly. Programmers are hesitant to use new features of the language until it shows up in all major browsers. You can’t just decide one day to move to the latest version. The version of JavaScript you have available depends on the browser that your client has installed.

Now, if you’re working on an Intranet, or on a Point-of-Sales system, you can mandate the browser. But for applications written for the web, you have to wait, and wait, and wait. Even after all that waiting, some people still haven’t managed to upgrade from IE6 yet. So you roll your eyes and wait some more.

One solution is to check to see if some language features are missing and provide them yourself (there are JavaScript libraries designed to help you out). That works fine when methods are missing, but it doesn’t work for new syntax.

What Mascara does it take future JavaScript (ECMAScript 4) and translate it into current JavaScript. It also does compile-time error checking.

Way to go We can all be future JavaScript programmers now.

You Could Lose Your Mind

What happens if you initialize an object with the same key (name) twice? I tried it in FireFox, Internet Explorer, Safari, and Opera.

In all cases, the last assignment (the rightmost one) is the winner.

var obj={a:1,b:2,a:3,b:4};

You end up with an object like this:

{a:3,b:4}

I’m not sure that’s mandated by the language spec. It might depend on the implementation. Anyone know?

Missing and Default Parameters in JavaScript

Passing parameters to JavaScript functions seems simple enough. Since the language is weakly-typed, all the parameters in the call are simply comma-separated.

And in the definition of the function it can get no more complicated than that–a comma-separated list of parameters.

Not much room for flexibility, is there?

But let’s take a closer look. Suppose you don’t pass all the parameters that a function is expecting. What happens?

If you shortchange a function, all the parameters you failed to supply are undefined.

What happens if you give more parameters than the function expects? They are ignored, but you can find they are still accessible in an array-like list called arguments. (No, it’s not an array. While it does have a length, it’s missing the methods that come with arrays.)

Now What?

So we’ve revealed a bit of flexibility–JavaScript won’t come to a screaming halt if you supply more or less parameters than a function expects. It’s more flexible in handling parameters than we might have suspected.

Some languages allow you to specify default parameters. Can JavaScript do that? Well, it’s not in the spec, but JavaScript programmers commonly provide default parameters using JavaScript’s || operator.

a = a || 1;

If a is undefined, a will be assigned 1. A will also be assigned 1 if a is 0. That’s not always what you want, so sometimes a condition is best:

if (a===undefined) {
  a=1;
}

Let’s try one. We’ll make a function that takes three parameters.

  • a will have the default value of 1
  • b will have the default value of 2
  • c will have the default value of 3
function test(a,b,c) {
    a=a||1;
    b=b||2;
    c=c||3;
    console.log(a,b,c);
}

We can call it like this:

test(1,2,5);
test(undefined,3,undefined);
test();

And get output like this:

1,2,5
1,3,3
1,2,3

If you have a lot of parameters coming in, that can get messy fast. Is there a better way?

There Is a Better Way

More than a few programmers have taken a stab at providing a nice default parameter implementation, and JavaScript is flexible enough to provide many ways to do it.

Most of these solutions feel over-engineered to me, so I spent some time thinking about the problem and came up with my own solution. I wrote a function called defaultHandler. This is going to be easy! Take a look:

    defaultHandler=function(defaults,params) {
        var i;
        for (i in params) {
            defaults[i]=params[i];
        }
        return defaults;
    }

We start with the “defaults” object that was passed in. Obviously, this holds all the default values for the parameters we expect to get passed in. Then we spin through everything that was passed in as a parameter and add it to the defaults, overwriting values when we run into identical keys.

Simple. Too simple, perhaps. The trick must be in how we use it. Is that it? Well, here’s an example.

    function test(obj) {
        var params=defaultHandler({a:1,b:2,c:3},obj);
        console.log(params);
    }

Hmm. Not much going on there, either. I told you this was going to be easy!

Here, I call our test function:

    test({a:5,x:"tuna"});
    test({});
    test({b:10,y:5});

And get the following output:

Object a=5 b=2 c=3 x=tuna
Object a=1 b=2 c=3
Object a=1 b=10 c=3 y=5

That’s all there is to it. Instead of passing parameters, we always pass in one single object that holds all the parameters.

In effect, we’re ignoring JavaScript’s “almost an array, but not really” parameter-passing system, and using a full-blown object to do the parameter passing work. Since objects can hold anything (numbers, booleans, arrays, objects, functions, probably even regex descriptions), nothing has changed except the packaging and naming of parameters. And we’ve gained tons of flexibility.

Come to think of it, you don’t even really need the default handler. That’s just a nice way of pruning down the parameters which need to be passed.

Why Would I Do This?

Imagine you’ve written an operating system. It has a nice windowing user interface. You have function calls like “OpenWindow” that take some parameters. In a later version of the interface you want to start adding parameters to the function.

It can get messy. You want to keep backwards compatibility so old applications don’t break. So maybe you have a slew of new functions like “NewOpenWindow.” Then you come out with another revision and you want to add still more parameters.

When it gets silly enough, you look for another solution. The Amiga guys solved this problem with taglists. Taglists were much like an object–a list of names and corresponding values. You only supply the parameters you want to.

That was the first time I saw this sort of solution. They added an OpenWindowTags() function and that solved the problem forever. Unfortunately, in the case of the Amiga, “forever” didn’t last very long.

It’s a great solution for APIs of JavaScript libraries. You can add new stuff in the future without breaking any old calls to your library.

A good rule of thumb is to use JavaScript’s normal parameter conventions whenever the number of parameters are small and it’s inconceivable that they might change. Otherwise, pass in an object.

In Which I Discover I’m More Interesting and Provocative in Spanish

Some terrific Spanish-speaking people linked to this blog. Thanks to all those English-as-a-second-language readers out there who take the time to work through a blog like mine.

Google’s delightful Spanish-to-English translation…

Dreaming in Javascript

The more I write JavaScript, but I’m sure thinking that the language domain. Just when I decide one way to do something, I can think of another way of doing amazingly better.

JavaScript is a language that seems to have grown up with the sun shining on him. While Java is the caretaker of the beach, blonde boat and surrounded by plastic boobs embobados, JavaScript is disturbingly mysterious maiden forest that you can barely glimpse for a moment while you open passage between blackberries and brambles.

Two assertions of the most intriguing blog Dreaming in Javascript. Undoubtedly he invented the word recommended.

They are quoting from The Object Slinger post. Who knew I had such a flair for writing in Spanish?

A Challenge

Over here on his blog, Thomas has this “neat little HTML encoding trick in JavaScript”:

I came across a really neat trick in javascript lately that actually goes ahead and kind of cheats in a very effective manor!

Here’s the problem with javascript, everytime you send information from a form to a server side script, such as with AJAX, with HTML brackets it will return an error.  You can either manually fix this, or use a really neat trick called “escape”

 function escapeHTMLEncode(str) {
     var div = document.createElement(’div’);
     var text = document.createTextNode(str);
     div.appendChild(text);
     return div.innerHTML;
 }

What this simple little function does is take the internal HTML conversion code from your browser and returns a string converted to HTML.  It’s an awsome trick with how simple it is.

See, you have to note that whenever a browser creates an element in javascript, and a text node is created, the browser will go ahead and make sure that string comes out as raw code, and not as HTML, thus the term textnode and not innerHTML.

Now if they only had a way to reverse it that was that easy. lol

If only. Well, I’m here for ya buddy. Yeah, turns out that browsers have a nifty little html escape/unescape machine built in, and we can harness that built-in power.

Sample HTML Conversions
< .......... &lt;
> .......... &gt;
& .......... &amp;

I spent some time in Firebug playing with innerHTML. Stuff a string into innerHTML, and angle brackets get turned into their HMTL codes in the innerText field.

Like Magic

Now stuff HTML codes into innerText and *POP*, out it come angle brackets in the innerHTML field. Fun! I took a bit more direct route and managed to turn this trick both ways.

    escapeHTMLEncode=function(str) {
        var div=document.createElement('div');
        div.textContent=div.innerText=str;
        return div.innerHTML.replace(/>/g,"&gt;");
    }

    unescapeHTMLDecode=function(str) {
        var div=document.createElement('div');
	div.innerHTML=str;
	return div.textContent || div.innerText;
    }

Safari Manages to Piss Me Off

Complications? I don’t need to tell you that IE causes trouble, do I? This time it’s by using the field textContent rather than innerText. We handle that in the escape by just creating both fields. What does it hurt? This is a phantom div that will never be attached to a page anyway. In the unescape we || them together. One of them will be undefined and || gives us the one that’s not.

IE always causes problems, so no surprise there. But this time Safari offends as well by leaving “>” unconverted. This is mystifying to me. I did some searching and sure enough, that quirk has pissed off some developers. We convert it by hand with a replace.

This is all loads of fun (I’m dancing in my chair from the thrill of it all), but it shows that any time you rely on the browser to do something, you need to remember that you’re relying on four major (and untold minor) browsers to carry a load. In this case, probably safest to make the conversions yourself with a string of chained replace calls.

True story.

Yeah, I can solve Rubik’s Cube. For some reason, my children are amazed by this.

« Older entries