"Attentive" JavaScript

We've been discussing JavaScript patterns at work. It seems like the patterns that we're considering go step further than unobtrusive JavaScript. It seems like they could described better described by the word "attentive". As in the script is paying attention to what's on the page. It waits for the page to load and then wires up events automagically by listening for certain pre-structured elements.

This is a whole different style of coding to me. It has a lot in common with Domain Specific Languages, though. It could also be described as a declarative syntax for JavaScript based on structure of markup.

It's pretty nifty. I'm getting kinda pumped up.

Ritual Purification

I was talking with Mark Sherrill a couple of weeks ago about standards. Not web standards or or anything. Personal standards. Now it's important to note that Mark is perhaps the best designer that I have ever met. So you see, it was kind of an important talk for me. I think I learned something about how to set the bar for myself and my work.

Anyway Mark starts telling this crazy story from his undergrad years about a professor that he had who lit his student's projects on fire and watched them burn. He burned the projects. Because he didn't feel like it was worth teaching students to adhere to a lower standard.

Wanna know something crazier? There was a story in WIRED not so long ago about Samsung that starts with Kun-hee Lee's famous "voluntary incineration" at Gunmi after a batch of defective cellular phones.

At Lee's command, the factory's 2,000 employees donned headbands labeled Quality First and assembled in a courtyard. There they found their entire inventory piled in a heap - cell phones, fax machines, nearly $50 million worth of equipment. A banner before them read Quality Is My Pride. Beneath it sat Lee and his board of directors. Ten workers took the products one by one, smashed them with hammers, and threw them into a bonfire. Before it was over, employees were weeping.

To get to your best, you can't settle for alright.

Performing tonight: Internet Explorer 6!

For the first time in my career, I'm encountering profound JavaScript performance issues in Internet Explorer while trying to manipulate elements in a very large DOM.

The situation involves pulling down a large chunk of JSON data from the server and then creating a DOM representation of that data along with all of the relevant event triggers. For reference, with a data set consisting of 50 items, this works out to somewhere in the neighborhood of a hell of a lot of DOM elements and 1500 event triggers.

The problem is rendering performance in IE, which is hovering around 15 seconds compared to half a second for Safari and a few for Firefox. Ugly, right?

So... even though I'm not finished profiling the rendering process, I thought I would share some of the information that is helping me understand how to optimize JavaScript for Internet Explorer. Enjoy.

• Quirksmode: Benchmark - W3C DOM vs. innerHTML
• IEBlog: IE+JScript Performance Recommendations
• Comet: JavaScript Performance Issues

Update:

The Comet link contained materials that were just plain wrong... so I'd like you to mentally replace it with this link from Joseph Smarr's talk on high performance JavaScript at OSCON