Monthly Archives: January 2013


What’s the difference between:

!!(obj1 && obj2);

(obj1 && obj2);


The first returns a “real” boolean value, because you first negate what is inside the parenthesis, but then immediately negate it again. So, it’s like saying something is “not not” truth-y, making it true. The second example simply checks for the existence of the obj1 andobj2, but might not necessarily return a “real” boolean value, instead returning something that is either truth-y or false-y. This can be problematic, because false-y can be the number 0, or an empty string, etc. Simple existence can be truth-y. A “real” boolean will only be trueor false.

don’t use setAttribute

When does div.setAttribute('###') not equal div.###?


When you’re trying to set an element’s class attribute, IE has issues. Therefore, it’s better to use .className instead of .setAttribute(). There is also an issue with.setAttribute() and style in IE, so .style should be used.

// Don't do this:
el.setAttribute('class', 'foobar');

// Do this instead:
el.className = 'foobar';

// Don't do this:
el.setAttribute('style', 'color: #000');

// Do this instead: = '#000';

a simple real world explanation of using prototype (car properties)

In the beginning, I made objects like this…

var Car = function(type, color) {
  var type = type;
  var wheels = 4;
  var color = color;


var fit = Car('fit', 'red');
var kia = Car('kia', 'blue');

And it was good. However, if you looked at these objects behind the scenes, you would see that each of them had their own wheel property. Since a car object will always have 4 wheels, why should each object have it’s own wheels property? If I have 1000 cars, that’s 999 unnecessary wheel properties. Potential for memory issues? Sure.

So then I did this…

var Car = function(type, color) {
  this.type = type;
  this.color = color;
Car.prototype.wheels = 4;

var fit = new Car('fit', 'red');
var kia = new Car('kia', 'blue');

And lo and behold, things were better. No longer would I waste memory on duplicate properties, for all car objects would share the same prototype chain! Glory, glory hallelujah.

trying to understand node.js

This makes things a little clearer.

People who try to explain node.js fail to give people that knowledge that event-based programming is a different paradigm from object oriented programming, even though most people are familiar with OOP!

interesting analogies, but the comments have some criticisisms.

My feeling is that node is especially suited for applications where you’d like to maintain a persistent connection from the browser back to the server. Using a technique known as “long-polling”, you can write an application that sends updates to the user in real time. Doing long polling on many of the web’s giants, like rails or django, would create immense load on the server, because each active client eats up one server process.

It’s worth mentioning that ruby and python both have tools to do this sort of thing (eventmachine and twisted, respectively), but that node does it exceptionally well, and from the ground up. JavaScript is exceptionally well situated to a callback-based concurrency model, and it excels here. Also, being able to serialize and deserialize with json native to both the client and the server is pretty nifty.

Still no reason to use node.js