I’ve called it simple-node-server or “sns” for short, and you can fork it on my github account.

There are a lot of folks building SSJS clones of Django and WSGI and Rack the like. However, Python and Ruby have blocking IO, and even while they have the capacity for asynchronous behavior, it’s not the default.

I believe that, in order to get a really good JavaScript application framework, and cultivate new development in this green field, we must start with what we have, and iterate until it is closer to the ideal. I am skeptical that we’ll be able to get there by cloning the productions of synchronicity, no matter how sophisticated they may be.

It is possible today to build a web server in a day, in a flexible dynamic language, which can serve an alarming number of requests per second, by embracing asynchronous architecture.

Let’s play: simple-node-server

All “work from home” emails or “out of office” emails had to be sent in the form of a haiku. This rule was not enforced, but it’s the kind of thing that one person does, and then a few others pick up. Once someone starts doing it, they rarely stop.

Here are some examples:

Sick on an airplane.
Second carry-on: virus.
Infect passengers.

OS API:
Sadly, not writing itself.
Avoid distractions.

Roommate needs his car.
Internet works in new place.
May as well use it!

Nothing in iCal:
Must take advantage of this.
Work in pajamas.

Still not feeling well
Resting and working from home
Please ping or call me

Have suffered relapse
To this weekend's brief illness
So I work from home

Sneezing mightily
Wish not to infect colleagues
Thus working from home

A couplet for my recent vacation:

Been a busy year.
No vacations since ’06
Burnt out: Do not want.

Visit with old friends.
New England trees in autumn.
Rejuvenation.

Having worked on a bunch of teams, I’ve taken this custom with me as much as possible, to the Brand Universe team, and the Buzz team, and most recently the YAP team. There’s no proselytizing involved. I just send a haiku I’m working from home. Some people think it’s fun, and play a round of “speaking in poetry” via email. Some people adopt the custom, and it sticks. Others, for whatever reason, never get involved.

I’m not sure why some seem to instinctively carry it on, and others instead prefer just the subject of “wfh” or “ooo” with no message body. I’ve been told that there are other teams at Yahoo and elsewhere that this custom has spread. In Games, it’s all but gone, now that Dean has moved on.

Like the Twitter of the Edo Period, haiku (then called haikai) used terse imagery to elevate the normal and mundane to the deep and meaningful.

Most people learn in grade school that a haiku is 3 lines, with syllables numbering 5/7/5. While this is the typical standard, it’s not just about fitting into the right number of syllables.

The goal of haiku is to find powerful expression in a small intense dose, to elicit an “AH HA!” experience by virtue of succinctly expressing meaning via simple language and powerful imagery.

Limitation—whether 5/7/5 or 140 characters—is part of the equation. Because the limits are so draconian, the writer is forced to be clear. Squeezing ideas into uncomfortably small packages shaves off the excess. When the excess is removed, enlightenment remains.

Like Twitter, haiku can be terribly inane and useless. That is bad haiku. Truth be told, most WFH emails basically are expressing a single sentiment, and the form adds little to the composition. It’s just fun.

Good programming is like good poetry. The best programmers I’ve known are obsessively minimalist in their code, and do tremendously powerful things with simple logic and short functions. The same can be said for all levels of design: a simple business model, a straightforward user flow, a clean visual treatment.

Less is more. Like the kendō master who practices calligraphy, or the actor who studies yoga, the pursuit of excellence in one area can balance and ready the mind for one’s primary activity.

The next time you have to send an email to your team telling them that you’ll be out of the office for some reason, put it in the form of a haiku. Don’t explain it or call attention to it. It will be your gift. Watch how it is received.

In case you’ve never hit them organically: 404 401 403 410

The “YUI method of class creation” is not distinctively YUI—it’s just what Javascript gives you for free. You can use the “Module Pattern” alone on a page with no library at all! You can call it Crockford’s Module Pattern, but it seems to me that he discovered or popularized it more than “invented” it.

This, to me, highlights the biggest difference in approach between YUI and every other library: YUI doesn’t attempt to re-write the language, but rather to show off what the language can do and how those features can be effectively put to use. My experience with Prototype and Dojo and Mochikit all made me feel a bit like the author must not have liked Javascript very much. (Dojo actually goes a bit further—it rewrites HTML as well!) It seems like the other libraries say, “This Javascript language is too hard and confusing. Let’s make it into something else.” YUI says, “This language is beautiful and powerful, but it would be handy if we had some conventions and a common approach to these rough edges. Let’s build those common pieces.” It’s the difference between teaching someone to fish and giving them a fish, except instead of giving him a fish, you pass the fish through a slow and complex machine that spits out Java code.

Of course, I’m a bit biased. I imprinted upon YUI at a fairly early stage in my Javascript development. I work here, so I get to request features directly through our internal bugzilla instead of pleading in the public arenas. But the approach is one that I’ve always favored. If you feel the need to rewrite the language, then just go use another language. Javascript is the common tongue of the internet, and will remain so for the indefinite future. Don’t fight it. (Hat-tip to Jeff Atwood.)

Crockford’s “Module Pattern” is a great way to create a singleton that has some private methods. In fact, in my opinion, it’s the best and only way that this task should be done. (There are others, but they tend to be more obtuse, IMO.) But that’s not the only task of an object-oriented development. Sometimes, you need to have a bunch of objects, and if they have shared functionality, then that should be handled with a class of sorts. In Javascript, that means that they’re stamped from the same Constructor and Prototype. The Module Pattern does not address this in a very clear way, but it does highlight the principle of data-hiding through a closure that is the key to OOP in Javascript.

To create a class, I usually do something like this, which takes the essence of the Module Pattern and uses it to create a reusable class.

(function () {
  // these are properly private static, not just private
  // but with scope correction, that’s good enough for functions.
  // private function, called with privateFunction.call(this, a, b, c);
  var privateFunction = function (a, b) {
    this.a = a;
    this.b = b;
  };
  // private static data. Shared between all instances!
  var privateStaticData = “I’m private and static. All instances share me.”;
  YAHOO.myProject.myClass = function (a, b, id) {
    // a and b are public, since they’re set on this.
    this.a = a;
    this.b = b;
    YAHOO.myProject.myClass.instances[id] = this;
  };
  YAHOO.myProject.myClass.instances = {};
  YAHOO.myProject.myClass.prototype = {
    myPublicProperty : “I’m accessible as

(When in doubt, wrap it in a closure. Global variables are evil.)

I’d rather work with someone who is a bit green with Javascript but can learn, rather than someone who is an expert with Prototype or Dojo. The more time someone spends building applications with a library like Prototype, the further they get from Javascript, and the more dependent they become on the library. By contrast, time spent using YUI tends to breed developers who are experts in Javascript, and that skill is far more useful than being an expert in a particular library.

Consider this code fragment:

var obj = {
 foo : 'quux',
 bar : 'baz',
 doSomething : function () {
  // do something...
 }
};

So, we’ve created an object, and then some other things happen. Later in the code, we want to remove the “foo” property, so we do this:

obj.foo = undefined;

Still later, we only want to do something if the foo property has not been unset, so we check it:

if ( obj.foo !== undefined ) {
 // do something
}

That works, and it’s fairly common, but it’s klunky, and not as readable as this:

delete obj.foo;

if ( 'foo' in obj ) {
 // do something
}

The first one says, Delete “foo” from the object. The second asks, Is “foo” in the object? The difference between the first and second approaches is that the second uses intuitive wording in the code.

Note: You must use delete if you want to use in. Setting something to undefined manually will not cause it to return false when testing whether the property is in the object.

As an added bonus, using the delete operator also removes the property from the for/in iteration loop, since it actually removes it from the object’s key list rather than simply setting it’s value to undefined.

var obj = {asdf:'foo',bar:'baz'};
obj.asdf = undefined;
for ( var i in obj ) {
 console.log(i,obj[i]);
}
// outputs:
// asdf undefined
// bar baz

var obj = {asdf:'foo',bar:'baz'};
delete obj.asdf;
for ( var i in obj ) {
 console.log(i,obj[i]);
}
// outputs:
// bar baz

Note: you’ll need to wrap the “in” statement in parentheses if you want to negate it. For example, this is a bug:

var obj = { asdf:'foo',bar:'baz' };
var f = 'quux';
if ( !f in obj ) {
 alert( 'not there!' );
}

The alert will never fire. Can you figure out what’s happening? Here’s a clue:

var obj = { 'false':1, asdf:'foo', bar:'baz' };
var f = 'quux';
if ( !f in obj ) {
 alert( 'not there!' );
}

Now the alert will fire. What’s up?

The order of operations is this:

1. Process the !f, which converts ‘quux’ to a boolean (true), and then gets the opposite (false).
2. The “in” operator converts the value back to a string, and false.toString() is the string ‘false’.
3. Since ‘false’ is not a key in the object, the “in” operator returns false, and the conditional fails.

In the second case, since the string ‘false’ is a key in the object, the “in” operator returns true, and the conditional fires. Of course, using “false” as a key in an object is a really stupid thing to do, but if some bunk data comes into your program somehow, it can happen. Always wrap your “in” clauses in parentheses, and you’ll never have a problem. In this case, it works as expected:

var obj = { asdf:'foo', bar:'baz' };
var f = 'quux';
if ( !(f in obj) ) {
 alert( 'not there!' );
}

Update

I’m finding that a lot of people are hitting this page with search queries that seem to indicate they’re looking to remove a style property from a Dom node. delete won’t help you much there, since the style property is a get-and-set-only property. (IE, you can read from and write to it, but you can’t delete from it.)

Most of the time, you shouldn’t be messing with the style property directly in Javascript, anyhow. Instead, add and remove semantically meaningful class names, and put the style information related to those states in the CSS. Of course that’s not always an option, I know. So, you can remove the inline setting by simply setting it to an empty string, like this:

document.body.style.background="red"; // turns the page red.
document.body.style.background=""; // turns the page back to whatever it was.

Cheers!