Infrequently Noted

These are exciting times for JavaScript. Just a couple of years ago, what community was left around JavaScript and DHTML was dying. No one who was seriously interested in doing development with the language back then could have imagined that JavaScript and the yet-to-be-named Ajax would have it's own track at OSCON, but that's exactly what's happened. I'm happy to announce that Elaine Wherry of Meebo and I are co-chairing a JavaScript and Ajax track at OSCON 2006.

While the Call for Participation page doesn't yet include our track as one of the options, time is short for getting talks in (just over 2 weeks at this point). If you've been itching to talk about something JavaScript, DHTML, or Ajax related, please go fill out the CFP form and mention that it's for the JS/Ajax track. Obviously, we can't guarantee that your talk will be accepted by the committee, but there's nothing to lose and you can propose multiple talks.

If you're one of those folks who has scads of DHTML/JavaScript experience and just isn't sure what to propose a talk on, just send me mail and we can discuss what topics might be better than others.

Good luck, and see you at OSCON '06!

Every generation of browsers has its boat anchor: that browser which is so painful to develop for that there's nothing professionals would love more than to see it instantly disappear from the desks of users. This is different than simply being old. Old browsers will eventually cycle oh-so-slowly out of circulation. Webdevs understand this and live with it. We're used to pain.

What really rankles is when there's no light at the end of the tunnel. No year we can wistfully mark on the calendar as the date when we can use feature X of the latest CSS spec ("position: fixed;" anyone?). In the last 3 years, the title of the Web's Boat Anchor has been handed off from Netscape 4 to IE 6. Like the dreary days of NN 4.7.x, IE 6 is patched and patched again, but never to fix bugs we care about. With Firefox ascendant, MS had no choice but to restart development on IE in order to prevent it from being relegated to displaying help files in Office via an ActiveX control. The IE 7 team has shown a willingness to be candid about what they will and won't fix, and that much is commendable. Unfortunately, developers of dynamic applications (cough Ajax) have been entirely left in the cold. If Microsoft doesn't commit to fixing the following issues in the near future, no number of CSS rendering updates are going to stem the tide. The problems on the list are by no means simple to address. In some cases, they may require re-architecting large tracts of IE internally. Here's a little hint to whoever is the PM in charge of the renewed IE 7 effort: we don't care. We don't care how much it costs you. We've been cleaning up your messes for years. Those of us tasked with "just making it work" have spent so many sleepless days and nights routing around IE brokenness that our empathy and sympathy are entirely tapped out. All that's left is a combination of despair and loathing. You want us to give a (expletive) that you blog and are "engaging with the community"? Fine. Fix your (expletive) browser. That's the bar the IE 7 team needs to hurdle. I hope they've internalized that.

At a minimum, dynamic web apps need the following out of IE and JScript in the very near future:

• Memory leaks need to simply disappear
• Fix the cache+gzip bugs
• Give us getters/setters in JScript or give back watch()
• Fix the event object. Pass it in to DOM handlers by default. Also, offsetLeft and offsetTop are so ambiguious as to be useless. Give us currentTarget.
• Bump the limit on the number of concurrent HTTP connections if those connections are initiated after onload (either via XMLHTTP or other methods)
• Today, allocating more than 5K objects or so brings JScript to its knees. Object allocation cost needs to be O(1)
• Either revive (and start to fix) VML or give it an SVG-Tiny+DOM facade
• Give us a persistent, string-keyed, local cache in the MB range (5-10MB/domain seems a good start)
• Fast DOM queries. CSS selectors or XPath, we don't care. Just give us a way to say "get us all DOM node objects matching this"
• A way to toggle the box model on a per-element basis without switching doctypes. The CSS 3 box model spec seems a good starting point

If Microsoft is to re-build any credibility around their browser, they need to show us the goods. CSS fixes won't suffice this time around.

JavaScript (the language, not the browser bindings for the DOM, etc.) can be either brutally hard or refreshingly flexible. It's difficulty is directly related to how well you grok a couple of core concepts. I'm going to just list them and leave in-depth explanations to Tom's forthcoming book on advanced JavaScript.

Here goes:

• Everything in JavaScript is an Object. Even functions
• Every object is always mutable
• The dot operator is equivalent to de-referencing by hash (e.g., foo.bar === foo["bar"])
• The new keyword creates an object that class constructors run inside of, thereby imprinting them
• Functions are always closures (combine w/ previous rule to create OOP)
• The this keyword is relative to the execution context, not the declaration context
• The prototype property is mutable

If all of that makes sense to you, JavaScript can be a fun, liberating experience. If not, it's going to be a world of pain and broken expectations as you shed the baggage of less dynamic languages.

Good luck.

My work on Dojo isn't solely the product of a gigantic sleep deficit. Were it not for the generous support of JotSpot, the application platform cleverly disguised as a wiki, I think Dojo might not be a reality today.

Jot's support has been massive and prolonged, and over the past year we've built multiple features and products on top of the wiki platform that use Dojo in some way. This past monday we took the wraps off of our most heavily Dojo-based product yet: Tracker, a tool for doing lightweight list-like collaboration on the web. Think of each line in a Tracker "spreadsheet" as a wiki page which you can allow anyone to edit and attach things like images and files to. Spreadsheet++, if you will.

As the word "Beta" implies, we know there are a lot of the sharp edges and are working hard on getting them rounded off for you, but please do give it a try. If it doesn't keep you from firing up another instance of Excel for tracking a small list of things, we'd love to know why.