Infrequently Noted

IE's abysmal memory management is the bane of any professional JS developer's life. Without rehashing all of the patterns, you can tell your app is running afoul of IE's crappy reference counting when users report that it "feels slow" but that flushing the cache and/or restarting the browser "fixes" it. At this point you can either dig into the MSDN and Usenet articles on the topic and try to develop a workaround for your app, or you can use dojo.event.connect().

We didn't cover it in the event system article,but Dojo transparently prevents leakage when you use dojo.event.connect(). Dojo isn't the first system to do this, of course. The Signals and Slots system from netWindows baked in leakage prevention and others predate even it. As the problem has recently become better appreciated, other modern tools are starting to deal with leaks.

For those using Dojo, the solution to leakage is amazingly straightforward. In almost every case, you can just replace your node.onclick = function(){ ... }; statements with dojo.event.connect() equivalents and the leakage disappears. Under the covers, the node and the connected-to event handlers are placed in a "registry" for cleanup when the page starts to dissapear. A small map of property names is stored on the nodes so that the system never tries to strip more properties than necessary (which can be a serious performance problem).

The only exception to the transparency of this system is when DOM nodes are destroyed before the page unloaded. In these cases, DOM nodes may go out of scope and become "unreachable" by the event system for cleanup when the page unloads. To prevent leakage in these situations, Dojo provides dojo.event.browser.clean(nodeRef) to let you make sure that you're "OK". If you are going to remove nodes from a page, you can use this idiom to make sure that your app doesn't leak:

dojo.event.browser.clean( parent.removeChild( child ) );

Of course, this leak prevention is also tied into the guts of the Dojo widget system. Event handlers in widget templates are automatically registered for cleaning and when a widget is destroyed, the system takes care to clean up after you.

While many developers will inevitably roll their own and spend painful weeks trying to manually track down leakage, users of Dojo may never have to know that it was a problem. Which is how it should be.

Next time: how dojo.io.bind() lets you upload files and beat memory leaks, all before lunch.

I work at a pretty magical place. Not only is working with Jot like programming for the "giant data store in the sky", I get to work on Dojo and do so with an amazing group of folks. Take, for example, the case of dojo.string.Builder.

The basic idea is that instead of doing naive "+=" concatenation of strings, the string builder class should more efficiently manage the creation of huge string variables. In most scripting languages, the way the creation of huge, immutable intermediate variables is by creating an array or list and adding each new fragment to it, eventually join()-ing it to produce the end string. Until this week, dojo.string.Builder did exactly this.

David smelled a rat, though. His experience didn't match the conventional wisdom. We quickly had a set of tests for comparing the speed of various string creation methods. On JScript (Internet Explorer and WSH), it seems that stringArray.join("") is fastest by a wide margin. Testing showed it to be 10x faster than the "+=" operator in most cases. Interestingly, on Spidermonkey (Mozilla and Firefox) and Rhino the "+=" operator beat array construction/join by 3x. As a result, dojo.string.Builder now picks the fastest variant available for the interpreter your code is running on.

Taken alone, it's a small thing, but incidents like this make me feel amazingly lucky to be working with the crew that's contributing to Dojo.

About a year ago, I tried to invite PPK to the Dojo project. He declined at the time, stating that he doesn't find libraries useful, which seemed a reasonable thing to say. If it doesn't fit his tastes, so be it.

Today, however, he went a step further (via ajaxian), stating that neither client side nor server side programmers are qualified to write the coming generation of responsive webapps. From a semantic standpoint, I think I might agree: if someone considers themselves just one or the other, they won't be able to do it. But I don't think that's his point, and on that point I think he's dead wrong. I think Mark Wubben and Bob Ippolito's comments on the ajaxian post are dead on.

Sure, JavaScript isn't a "fun" language unless you magically wind up using it in a non-browser environment (in which case you should probably be using Python anyway), but to do "real engineering" in a browser, you need a "real engineer" on the client side. Someone who gets HTTP, JS, DOM, whatever your server-side language is, and can shoot the shit about TCP/IP stack config paramaters on whatever your server-side OS happens to be.

Anyone who can credibly claim to have written a non-trivial amount of idiomatic JS (can you explain a closure? how does prototype inheritance differ from class-based inheritance?) probably fits this bill, and if not, they already show the ability to pick up difficult concepts and will be able to fill in where they aren't already experts. The question isn't "server side" or "client side", but do you come at it from an engineer's perspective, regardless of what side you're on?

As a library author, I find his remarks about them interesting but still naive. I know PPK doesn't like libraries, but they tend to be written first and foremost for the benefit of the people who wrote them: e.g., just the kinds of engineers he dismisses on both sides of the HTTP stack.

Frankly, good engineer's don't re-invent the wheel for kicks, and so a good engineer dropped from a server environment to a client-side environment will instinctively look for good tools. Implying that one has to suffer to get things done on the client is just plain wrong. Suffering doesn't make one a better client-side engineer. Engineering things does.

I worry a lot about not being introduced to enough new things. For the last couple of years I've spent most of my professional and personal time on DHTML and JavaScript. While I used to write quite a bit of Python, I now spend my time almost exclusively in some sort of ECMA-262 interpreter, and it scares me. Not perhaps because it's too limiting an environment, but because I've gotten too used to my own pre-conceptions of what is possible. With DHTML in particular, I find just having my conceptions of what's possible expanded is enough to turn intractable problems into straightforward tasks. Being able to value a problem more accurately is the key to solving or avoiding it.

A conversation I was recently in turned directly to the value of valuing things. Someone pointed out that in the valley, and esp in a time of growth like right now, it might just be better to shut up and let the hype do some free marketing for you. Another other countered was that if you stop exercising the capacity to discern good from bad, you eventually loose the ability to make the distinction. Obviously, making the distinciton and announcing it are different, but both points still stuck. The value of looking locally for short-term opportunity is a bet against the opportunity cost of continually integrating new information which would allow better foresight of what can happen. Conversely, investing in expanding my view of the possible robs from making the currently possible a reality.

That's the basic tension playing out in my head. On the one hand, I know I need to spend time discovering new things, but in doing so I consciously allocate time away from things with measureable payoff, e.g., fixing one more Dojo bug vs. learning a new programming language. So 8 years after I started first feeling this particular brand of guilt I'm only now coming to terms with the fact that it will always be with me. I'm not sure if that's liberating or frightening.

Every day I mourn suck a little. It's buoyancy seemed tied to the rising, and eventually draining, tide of New Economy inanity it started amidst. As a recent Silicon Valley arrival, I can only imagine the lunacy that one must have endured just by overhearing the conversations taking place in South Park as a hundred dot-commies sipped coffee while walking their dogs.

Like canaries in our proverbial coal-mine, the humorists always try (in vain) to show how terribly, terribly stupid we are collectively being. Looks like the New Bubble is starting off strong.