Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

I'm ordering this book...right....NOW

Hot damn! The Python Essential Reference has a new version out! Huzzah!

The 2nd edition of this book has been in my backpack for going on 3 years now. It is the only Python book I can't live without. No offense to O'Reilly, but with the exception of "Learning Python" and the "Python Cookbook" books, their core Python language books have sucked major donkey. New Riders has them licked with just this one title. If you want a book on the best damned language this side of C and the other side of Scheme, "Python Essential Reference" is the way to go.

Conference Season!

Been bitten by Dojo bugs or have feature requests? Going to a conference any time in the next month or so? Odds are you'll be able to get your very own pound of flesh. The rundown:

That people keep asking us to talk about Dojo and are using it to build truly awesome apps is humbling. I always learn so much by talking to people at conferences, and I'm looking forward to doing that a lot in the next month.

See you there, wherever "there" may be!

ajaxWrong

Apparently a new XUL app called "ajaxWrite" was just launched. I think this thing is going to be my poster child for what's wrong with single-renderer markup languages from now on. It might be a fine app, I haven't used it long enough to have a strong opinion, but its marketing is truly reprehensible. I'm sure someone assured Michael Robertson that they couldn't launch a web-ish app without tacking the word "ajax" in the title and the folks with sense were shouted down. A pity.

This thing is appropriating the necessarily amorphous terminology of "Ajax" for an implementation that is directly at odds with why Ajax is an important technology. A XUL app being billed as "Ajax" is just as laughable as a Flex or XAML app suddenly growing the same moniker. That it's Mozilla's walled-garden language doesn't really excuse the gaffe.

But, I hear you ask, aren't Firefox/MoFo our only hope?

Perhaps, but only insofar as Firefox is a good HTML and SVG renderer. XUL is not a standard. No one else implements it, and it's not likley that anyone else ever will. And that's OK. What's not OK is when these walled-garden-web technologies start getting passed off as somehow being more open, more cost-lowering than they really are. The unspoken promise of Ajax is that it makes cross-browser apps that are more responsive possible. Stunts like "ajaxWrite" not only break the contract locally, they start to cast aspersions on the efforts of scripters everywhere who are dedicated to an open application platform.

The web has succeeded in part because in trade for control over UIs, businesses gained the ability to deploy to everyone everywhere. In a world where the web is how business gets done, "cross platform" really means "cross browser". Single-render apps are bad for the web and bad business. What (aside from a larger potential to succeed as an app) would have the functional "open vs. closed" difference been if this thing had been written in Flex? Or XAML? All of these platforms are highly capable. More capable than the Open Web is today, but they are not the Open Web. The term "Ajax" is a proxy and an ambassador for Open Web technologies today. The message that "javascript works now" means that the same kinds of universal access to information that the static web made possible is now available to application authors. But not if shameless marketing shills co-opt the term to mean something that's harmful to the web. "ajaxWrite" is just such an abomination.

So I'm calling on Michael Robertson to do the right thing and rename this product. A quick check shows "xulwrite.com" as still being available. There's still time to change course. Still time to avoid giving the Open Web the bird.

Fast DOM Queries in Today's Browsers

What follows is a janky hack. If you do not have the stomach for things that are useful in the real world, please stop reading here. "But it's not standards compliant!" comments will receive no sympathy. Validatorians, you've been warned.

If you're still reading, you're probably aware of the crappy primitives that the W3C has bestowed us with for scripting arbitrary collections of nodes. Things like Microsoft's HTC and Mozilla's XBL allow for browser-specific markup-upgrade paths but these aren't really feasible in the "real world" since they require lots of code branching and different semantics for attaching a behavior. Tools only succeed where they lower our costs. This is why Dojo and Behavior (and even netWindows, back in The Day) work so hard to provide a portable basis for applying behaviors.

Given that the W3C has f'd us in the ear and that the browser manufacturers can't get it together enough to come up with one non-standard way to apply scripts to collections of nodes, we're back to iteration. Updating the collection to which a behavior should be applied when a DOM is updated presents a particular challenge. IE doesn't throw mutation events for DOM changes nor does it provide client-side XSLT. Both hands our tied behind our back.

So we need something else. document.getElementsByName() would work quite well if the browsers paid attention to name attributes for any element. Alas, they don't. Which brings us back to the one fast query browsers will support on any element: document.getElementById(). With it we can build a fast, efficient query function for every browser but Safari:

function elementsById(id){
var nodes = [];
var tmpNode = document.getElementById(id);
while(tmpNode){
nodes.push(tmpNode);
tmpNode.id = "";
tmpNode = document.getElementById(id);
}
for(var x=0; x<nodes .length; x++){
nodes[x].id = id;
}
return nodes;
}

A permutation of this that caches the results and does not set the IDs back to the original value allows re-runs of the function to determine if new elements have been added to the group and/or if a node should be removed:

var groupCache = {};
function elementsById(id){
if(!groupCache[id]){
groupCache[id] = [];
}
var nodes = groupCache[id];
for(var x=0; x<nodes .length; x++){
if(nodes[x].id != ""){
nodes.splice(x, 1);
x--;
}
}
var tmpNode = document.getElementById(id);
while(tmpNode){
nodes.push(tmpNode);
tmpNode.id = "";
tmpNode = document.getElementById(id);
}
return nodes;
}

Obviously, getting a list of added/removed nodes from this function might be preferable to receiving the full list, but I'll leave a better API for this as an exercise. Safari is the only browser which appears to not support this method of constructing queries, but we can fall back to iteration. It's certainly not going to be any slower than current methods. The hack is also made somewhat less useful by the W3C's bone-headed decision to limit elements to a single ID.

The jury is still out as to whether or not this is going to prove useful, but I can already imagine it being an optional optimization for Dojo users looking to make their apps go like hell on pages with complex DOMs.

If only it weren't necessary.

Update: After reading much WebCore source code, I'm not aware of a way to make elementsById() work on the current Safari. There is good news, however. On the latest Konqueror release and nightly Safari builds this hack works flawlessly. In short, this will very soon the the most widely available, fastest DOM query method. More news regarding elementsById() to follow shortly.

Those loveable finks

My last attempt to rebuild my mail client of choice on the old Powerbook was something short of thrilling. It was with some trepidation that I moved my data to the new MacBook and attempted to fire up kmail. Thanks to the magic of rosetta, it worked. I was, in a word, stunned.

But I just can't leave well enough alone. Having read encouraging notes about fink on 10.4+Intel, I backed up my data and /sw directory plunged in, foolishness first.

Unlike my previous attempt at building KMail, the process was absolutely painless. Not only is the "ssl vs. non-ssl" war apparently over, dependencies satisfied themselves in the right order and the only input needed from me was the occasional mirror selection. An hour into the process things were well enough under way that I went to bed and just left the build running. When I came back to the terminal this morning, lo-and-behold, it had built cleanly. On firing it up, i can attest to the difference that native compilation makes. My mail has never been so speedy. As someone who lives-and-dies by the mailing traffic that flows into my laptop, all of this makes me one extra-happy camper.

The fink folks (particularly Benjamin Reed, the KDE maintainer) have clearly spent some quality time polishing the dependency code since last I had to preform this operation. My sincerest thanks go to them for the painless install this go 'round. Not only do I have the latest-and-greatest KDE available, I now feel comfortable recommending fink again to folks who want a better alternative to Mail.app.

Older Posts

Newer Posts