Archive for the ‘JavaScript’ Category

Great article for learning JavaScript for existing programmers

Posted on June 4th, 2010 in JavaScript | 1 Comment »

I’ve been teaching JavaScript to a person with no programming experience and one with lots of programming experience in other languages. Both situations can be tough as one has to learn certain programing concepts (as well as how the web generally works) and the other must unlearn some that don’t apply here (like getting out of the strongly-typed world and appreciating the benefits of duck-typing).

Explaining various concepts in JS such as prototypes, closures, and even “literal” shorthand is interesting. I find the questions from both ends great—sometimes even challenging to explain which actually strengthens me as a JS developer. Still some concepts are hard to explain and the JavaScript Rhino book is too large and boring to dish out as homework. Then I stumbled across this page by Simon Willison which was written as a re-introduction to JavaScript but also makes a perfect condensed overview of what JS is for existing programmers: It even goes over a little history of the language and how to avoid nasty memory leaks in IE (circular references). Saves us a lot of time and explaining so that we can continue with more complex topics.

JavaScript Memoization

Posted on February 25th, 2009 in JavaScript | 1 Comment »

I was taking a look at my friend Takashi’s JavaScript tweener which isn’t released yet and noticed he setup his code in a particular way for a few methods that get called dozens of times a second. He explained to me that it was for optimization through memoization. I ran a test case, and indeed it’s much faster. Check it out:

a = {};
a.deep = {};
a.deep.variable = {
    here: 3
function plain(){
function memoized(){
    var z =;
    return function(){
now = new Date();
    for (var i = 0, max = 5000; i < max; i++){
alert(new Date() - now);
now = new Date();
    for (var i = 0, max = 5000; i < max; i++){
alert(new Date() - now);
// plain:  759
// memoized: 36

There’s a more complex example on the subject posted a month ago on Ajaxian and an easier to understand one on Oliver Steele’s blog written back in 2006.

The difference between != and =!

Posted on December 31st, 2008 in JavaScript | No Comments »

I was helping a friend troubleshoot some of her code today and found the culprit to be a typo in one of her conditional statements:

// var USERID = 12345;
if (USERID =! null){
     // code

Her expression was always resolving to true because she had inverted her != (“not-null”) check which was actually assigning her variable to the return of a statement evaluation. Her mistake would be clearer to understand formatted as such:

// var USERID = 12345;
if (USERID = !null){
     // code

Since the inverse of false, null, and NaN is true her conditional statement (also an assignment) would always return true.

Which lead me to thinking, the not operator is a great way to write succinct code. In the right context, using the not operator in the right side of an assignment isn’t a bad idea.

Improve your jQuery – 25 excellent tips

Posted on December 16th, 2008 in JavaScript, jQuery | No Comments »

Here’s a nice write-up by Jon Hobbs-Smith at detailing 25 tips on using jQuery as well as regular JavaScript advice. Most of these tips probably aren’t anything new for the advanced jQuery user (Jon considers himself intermediate, I think that’s modest), however I love lists like this because there’s a treasure trove worth of experience being shared. Altruism at it’s best!

I plan on writing more entries on my own tips and tricks with JavaScript and jQuery as well as my methods of debugging in various browsers, compression techniques, etc., but in the meantime, I’ll just comment on Jon’s list:

2. Use a [jQuery] cheat sheet

I think Visual jQuery is all you need. And now that there’s live search and clickable examples it’s even better.

3. Combine all your scripts and minify them

Dead Edward’s packer is awesome for minifying, but before I do that, I like to run my code through jSlint to make sure it’s all valid. I ignore line-break errors as I don’t agree in many cases that it’s an issue.

Additionally, when I work on large JS codebases with a lot of other people who may not code as strictly as I do, I like to use JSmin on the minimal setting (cut-and-paste version here). The compression benefit is only slightly less and it preserves single linefeeds preventing JS errors where people forgot to end their statements with a semicolon. It also makes the code easier to read and debug in a production enviornment—great for the times you want the benefits of minification without the side effect of obfuscation.

5. Keep selection operations to a minimum by caching

I just wanted to comment in Ron’s example where he used:

var myList = $('.myList');

First, if I ever reference a jQuery collection in my scripts, I like to append the dollar sign character to the beginning of the variable name to signify that it is, in fact, a jQuery collection:

var $myList = $('.myList');

It’s a lot more helpful when you access that variable further down the road and don’t have to question whether it’s a jQuery wrapped set, an actual HTML element, or something else.

Secondly, whether you’re using a JS lib or not, I would never search for an HTML collection by class name alone; What the JavaScript engine is doing in the background is looping through every single element on the page which is very intensive. It would be better to find the closest parent container first or search by specific tag name(s):


var $myList = $('ul.myList'); //added benefit of knowing the type of element you'll
// receive


var $myList = $('#closest_parent_id .myList'); // searching the children of a parent
// container instead of all the elements on the page


var $myList = $('#closest_parent_id ul.myList'); // combination of both above

19. Use noconflict to rename the jquery object when using other frameworks
22. How to check if an element exists[...]

As I’ve probably mentioned before, I always like to use noConflict() in all my projects. I move jQuery to the $j namespace and save $ for a shorthand reference to document.getElementById – I think it’s what most js developers expect and if($('myDiv)) is a lot simpler to write out than if($('#myDiv).length !== 0) or even if($('#myDiv).length).

Thanks for the link Bryan!


Posted on October 27th, 2008 in JavaScript | 11 Comments »

I noticed that JavaScript has a String.fromCharCode for decoding a sequence of numbers to Unicode values but no String.toCharCode for doing the reverse. So here’s my rendition:

String.prototype.toCharCode = function(){
    var r = '', string = this.split('');
    for (var i in string){
        r += String.charCodeAt(string[i]) + ',';
    return r.substr(0,r.length - 1);
// returns "98,111,98"

Update: version from my good friend Takashi and link to his blog on why it’s more efficient:

String.prototype.toCharCode = function(){
    var str = this.split(''), len = str.length, work = new Array(len);
    for (var i = 0; i < len; ++i){
        work[i] = String.charCodeAt(str[i]);
    return work.join(',');
// returns "98,111,98"