Foo Hack » Javascript Isaac Schlueter on Web Development Tue, 03 Nov 2015 06:34:16 +0000 en Simple Node Server Mon, 21 Dec 2009 18:09:00 +0000 Isaac ...Read More]]> Here is an example of a very simple lighttpd/nginx-style web server written in NodeJS.

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

CSS vs Tables: You’re Doing It Wrong Tue, 03 Feb 2009 07:40:22 +0000 Isaac ...Read More]]> Definitions first.


A specified set of columns and rows with cells that automatically and fairly smartly expand to fit their contents; cells can span rows or columns; the table as a whole can be treated as one block, and cells can contain tables. A table is a metaphor for visually laying out 2-dimensional content.


cascading style sheets; not floating divs, not any specific markup, but just the concept of the visual display of markup specified by a series of rules that are kept separate from the markup they operate on, generally in an external linked file or a style tag in the head of the document.

Talking Past Each Other

CSS is (for various reasons cited elsewhere ad nauseam), in most cases, the more optimal technological approach. That’s not to say that the existing state of the CSS language is perfect. In fact, even the most vocal CSS advocates regularly assert that there are deep problems with the existing spec and browser support.

Tables are (for various reasons cited elsewhere ad nauseam), in most cases, a more optimal metaphor than any of its rivals. There’s nothing inherently wonderful about the tags themselves. In fact, even the most vocal table advocates regularly assert that the markup is ugly.

Therein lies the crux of the problem. CSS is a great technological approach, and tables are a great metaphor. The question then usually becomes, Should I mark up my content using <div> tags or <table> tags?, which really means, Is the separation of style from content more or less important than using the optimal layout metaphor? The debate goes a little like this:


This layout metaphor is better, so you should use these tags. All you idealists are unrealistic! (Also, if you think markup matters, you believe in fairies. It so doesn’t!)


Metaphor shmetaphor! You don’t care about the sanctity of data or code quality. Think of the maintenance! (Also, if you can’t do it with divs, you’re stupid. It’s so easy!)

The Right Answer, it would seem, is to use the table metaphor with the CSS technology. In the ideal world, you’d always mark up your content using the tags that would communicate your meaning most clearly to your intended user agents. Then you’d tell user agents how to treat those tags visually. To describe this visual display, you should be able to use the table metaphor, or the float metaphor, or absolute and relative positioning, or anything else, but that should not be done by your markup.

Getting Real

In the real world, it’s not so nice. The CSS specification has a set of display values designed to mimic the table tags, but they aren’t well supported, and anyway, it’s an imperfect imitation of a hack that was not really intended to be used the way we all ended up using it.

In other words, CSS is not an ideal example of what CSS aims at, and the table/tr/td tags are not an ideal implementation of the table/grid metaphor. CSS tables, though they are clever and in some cases quite useful, take it from bad to worse.

The state of the CSS art is not at a point where you can realistically expect to make any significant stylistic changes to your pages without altering the markup. If you need to move the navigation bar from the right to the left, or re-skin the page with dropshadows instead of rounded corners, or convert your gradients from 2-tone to 3-tone, or make your boxes vertically centered instead of top-aligned, you’re probably going to have to change your markup, at least a little.

In theory, it’s possible. I know a handful of my colleagues will vehemently disagree and point at countless approaches to enable virtually any kind of reskinning using only CSS changes. (I’ve used Leslie Sommer’s CSS Mojo technique to great success in the past; we used it for pretty much everything on Yahoo! Buzz.) But let me tell you, from years of experience building production sites with CSS, most of the time, in reality it just doesn’t work that way.

And why should it? What kind of crazy lunatic writes all their HTML by hand in text files, anyhow? Clearly you have some kind of back-end engine spitting it out from templates, so you just change the template, and voilà!, the markup is changed everywhere.

A Very Blue Bike Shed

Working at Yahoo, I’ve met some webdevs with truly incredible CSS ability, who crank out live code under real deadlines to exacting standards. They use CSS, and not tables, and they Get Shit Done. There are a lot of them, more than I can list here, but Nate Koechley, Matt Sweeney, Hedger Wang, and Leslie Sommer all deserve a special mention. I came to Yahoo knowing CSS pretty well, but I became an expert largely as a result of working in such a highly skilled community of developers.

Also due to my time at Yahoo, I’ve seen some absolutely crazy debates about markup and coding standards on the devel-frontend mailing list. I mean, you think this little flare-up in the blogosphere is anything? You got no idea, buddy. Seriously. And these are coworkers who (for the most part) really like and respect one another.

You wanna know a secret? It makes no difference.

Language is as language does. If everyone uses the <table> tag for markup, guess what happens: <table> is now a semantically meaningless (or at least, semantically vague) tag, and any user agents that might care about navigating tabular data have to deal with that fact. It becomes just another <div>, for all intents and purposes, but a little less flexible, and with a default styling that makes it handy for layout.

The passion for the rants comes from the fact that it is meaningless! Of course it’s a fertile ground for bikeshedism!

That’s right: It doesn’t matter.

Use whatever tags work for you. I don’t care. You’ll still be a good person.

I can tell you from experience that a deep knowledge of CSS is essential for serious front-end development. (Most so-called DHTML is actually just manipulating CSS with Javascript, and the Javascript is pretty light.) CSS can do some things that table tags can’t, so you ought to learn it. The reverse is also true, so you should know how to use tables, too.

Write code that you can maintain, that is flexible enough to let you change it without sacrificing the stability of your product. Test it in the user agents that you expect to support. Stop debating the color of this bikeshed.

If there’s ever a good reason to go back and change your tables to divs, or vice versa, you can do that. Hell, plan for that, because whether you use CSS for layout or not, you’re going to need to touch your markup sometimes. It is much much harder to build a product people want than it is to build a product that works in Browser X.

Belorussian translation provided by fatcow

The Haiku OOO Email Mon, 03 Nov 2008 17:00:35 +0000 Isaac ...Read More]]> When I started at Yahoo on the Games team, there was a custom that resonated deeply with me, which was started by Dean Yu.

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.
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.

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

YUI’s “Module Pattern” vs. Prototype’s Class Function Mon, 13 Aug 2007 17:47:36 +0000 Isaac ...Read More]]> Via Geoffery Moller, I came across this article on Matt Snider’s blog. I’m surprised that no one noticed what (to me) was the most relevant difference in the libraries that he evaluated.

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, 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 .myPublicProperty.”,
    myPublicMethod : function () {
      var a = (new Date()).getTime();
      var b = a + 10000;
      // note the way that private functions are called., a, b);
})(); // close the closure and execute the code.
// later on…
(function () {
  var myInstance = new YAHOO.myProject.myClass(1,2,’blahblah’);
  // now you can deal with it as “myInstance” within this closure,
  // or as YAHOO.myProject.myClass.instances.blahblah elsewhere.

(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.