FatBusinessman.com

Year of the DOM?

I’m going to start with a confession: I don’t like JavaScript. Whether this is because of unfortunate experiences in the past or unfortunate experiences in the present, I’m not entirely sure. I guess I’ve seen JavaScript used badly far too many times to trust it. In fact, I have even perpetrated some of those bad uses: I once wrote an entire quotation database in JavaScript. The things we have to do when our web hosting doesn’t provide any support for scripting…

Of course, not all misuses of JavaScript are quite so noble: I’m sure we’ve all come across those really annoying scripts which stop you right-clicking on a document (especially annoying when you’re using the All-in-one Gestures plugin).

So far we’ve got the noble-but-flawed uses, the just-plain-annoying uses, and of course the now-outdated uses (JavaScript image rollovers – yes, I’ve used them too). What, then, is JavaScript actually good for, and why are Zeldman (of ‘three-legged stool’ fame), Holzschlag and Willison all interested in it from the point of view of standards-based design?

To be honest, I’m not fully sure: as I’ve said, I’ve steered clear of anything JavaScripty for a long time, but it’s apparently to do with a Document Object Model which allows you to play around with the structure of an HTML document post hoc. It all seems like a horrible hack to me, but someone’s managed to pull off image-free rounded corners with it while leaving the document markup nice and semantic. Of course, there’s also Gmail, which doesn’t even attempt to follow standards but gets points for being really rather shiny.

So, in summary, JavaScript is a nasty horrible hack, but it looks like being a nasty horrible hack which can do some rather nifty tricks while letting you keep your standards intact.

One Response to “Year of the DOM?”

  1. While accepting that JavaScript has/is used for some terrible things I think you need to get over the “JavaScript is bad” presumption. It depends, instead, on how you build the site.

    The Document Object Model (HTML or XML, depending on which flavour X/HTML you like to use) is a way of accessing and modifying any element in the document tree. It’s how XML is so useful and powerful (hello XPath) and it applies to HTML as well. As well as reading/writing from/to existing nodes in your Document tree you can also create new child nodes, of course.

    JavaScript should be used in two ways: As a tool for writing web applications, where you are permitted to specify higher requirements on users than a traditional website or as a tool for enhancing traditional, static sites. The DOM is an immensely useful tool for both, since it is a standard and well supported in all current browsers.

    In the former use you are free to do what you like – you use JavaScript in an identical way to how you’d use any other backend programming language to achieve runtime functionality. The DOM has facilitated powerful manipulation of your application’s content and XMLHttpRequest (Ajax, iirc) allows for dynamic loading of additional content in the background without reloading the entire page. Google chose to do this with GMail (for better or worse) and produce an application that has quite high browser requirements (Opera will only support it when version 8 goes final).

    The latter use is the most famous and the most mixed. Put aside websites which use JavaScript to generate content, they are bad, but consider using JavaScript to enhance a static site. Take a look at Dunstan’s search implementation in his blog sidebar – the results are loaded dynamically by JavaScript and loaded into the sidebar as you type (with JavaScript). If JavaScript is disabled then you just hit Enter like normal and you’ll be taken to a new page with the results. There is, in my opinion, nothing at all wrong with that and lots right about it. The content is still just as accessible, but for the end user with JavaScript it’s enhanced for convenience and user-experience.

    Dunstan also uses it to provide presentation of mark-up that browsers don’t normally present. Consider the cite attribute of blockquotes. This information is potentially of interest to the reader but wont actually be presented on screen in any major browser. Using JavaScript and the DOM you can take the content of cite and append it after the blockquote element. Useful data that wouldn’t normally appear in the page is suddenly presented, but without duplicating information that you’ve provided in your X/HTML.

    To be honest, I’m disappointed with the way GMail is constructed. When using it in a full desktop browser it’s great but if they’d built it to be JavaScript-free first and then added dynamic Javascript over the top (so as to provide the fancy functionality). If only they’d done it that way then GMail would work without modification on my phone (non access to my email while I’m away from the computer is pissing me off a bit).

    Oh, and don’t forget that the majority of Firefox’s front-end (and any other XUL application) is largely powered by JavaScript, so don’t slag it all off.