By Simon Willison

2005: The year of the DOM

By Simon Willison

Jeffrey Zeldman popularised the concept of the “three legged stool” approach to web design in his book, Designing with Web Standards. The three legged stool consists of XHTML for content and structure, CSS for presentation and JavaScript and the DOM for “behaviour”. CSS and XHTML have had an excellent couple of years in 2003 and 2004, but what of JavaScript and the DOM?

I think that 2005 will be the year that proper use of the DOM really takes off. Most JavaScript on the web still hails from the late ’90s, but change is in the air. Netscape 4 is practically dead and gone, and the current crop of browsers all offer excellent DOM support (even Opera has caught up). There are very few reasons not to take the DOM seriously, and a great deal of effort is being invested in exploring new, effective ways of taking advantage of client-side scripting technology.

The challenge, of course, is accessibility: while JavaScript technologies allow for much improved interactivity they remain unavailable to a significant portion of user agents. The solution is to treat JavaScript as a tool for enhancing the user experience for those who can benefit from it, while avoiding cutting off access to others. A classic example is Google Suggest – it’s great if you have JavaScript turned on, but you can still use Google’s primary search function without it.


Google Suggest also demonstrates what I think will be a key theme for 2005: XMLHttpRequest. Loading additional data interactively from the server has been a dream of client-side developers for years, and XMLHttpRequest finally provides an “official” method for doing exactly that (previous remote scripting efforts had revolved around ingenious hacks). GMail and Google Suggest have sparked a huge interest in this technique and it’s certain that we’ll see a lot more of it over the next 12 months. The ObjectGraph Dictionary is another example.

Joel Spolsky concludes How Microsoft Lost the API War with the observation that “The new API is HTML, and the new winners in the application development marketplace will be the people who can make HTML sing.”. If that holds true in 2005, JavaScript and the DOM will have a very good year.

  • cejua

    The XmlHttpRequest object has been available for some time now in IE and its great to see it’s use in todays standards compliant browsers.

    As a sidenote – its interesting to see how ASP.NET 2.0 has the process of using XmlHttpRequest to quietly update a web page built in.

    If anyone is interested this article fully describes ‘ASP.NET 2.0 Script Callbacks’:

  • I agree that we’ll see cool uses of the DOM and XmlHttpRequest this year. I don’t think accessibility will suffer too much when creating these scripts among those who care about it, but the real issue is getting those who didn’t care about it in the first place to take notice and fix their scripts.

  • Dante Evans

    There are 3 things that are going to be huge in 2005, and one of them is XMLHttpRequest (the other two are and WordPress). XMLHTTPRequest allows for interaction between and the client browser, and this is something I think we’ll see a lot of this year.

  • I wonder, can we use serverside sessions with XMLHttpRequest ?

  • If by servserside sessions you mean maintaining a session for a user then yes, absolutely – the content retrieved by XMLHttpRequest is usually dynamically generated on the server, and can hence be customised based on the user’s cookie (or even a session identifier passed in the URL).

  • Anonymous

    Look at this software You can write all your code in Java which is complied into javascript. It makes programming dynamic javascript much easier.

  • Innuvo looks terrible: their main site doesn’t even load in Safari (you get a blank page instead) and it appears to generate web applications that are completely useless if you don’t have JavaScript – an accessibility nightmare! “Your browser currently has JavaScript disabled. Please enable JavaScript to properly view this application.” isn’t the kind of dynamic web application future I’m looking forward to.

  • I’ve been using xmlhttprequest in all of my latest projects. I have to agree that this is going to be really hot in 05.

  • someone

    seems like javascript finally has a purpose. except from opening annoying popups.

  • marcoax

    Hi i’ve implemented a simple XMLHttpRequest in this page
    seem to work better in ie5.5 and Mozilla

    selecting the Paper type the others fields will be update according your selection without reload the page.

  • Espen Antonsen

    I used XMLHTTPRequest extensively in my latest project – a CRM system ( I agree…with better use of the DOM and smart techniques like XMLHTTPRequest, web-applications will become very useful.“>Have a look at my post about web-applications and the restult of the CRM system I made.

  • Steve Yen

    I agree. My own contribution to help
    push the idea is JavaScript Templates.
    JST let’s one do PHP/ASP/JSP/Smarty-like
    template programming fully in the web

  • jbot

    JST sounds rather good. However, it’s just a play on ye olde JS entities – remember them, is that where you got the idea? It’s something I thought about doing myself, so looks like I won’t have to now LOL. Nice one, mate.

    Re: the comment about JS finally being able to do more than just popups. JS has always been able to do very many powerful things, such as LiveConnect, for example, where JS is able to program Java applets. Also XMLHttp isn’t quite as powerful as JScript/ADO, whereby you can program databases straight from script. Ok, so it’s Win IE only, but it’s still far more powerful than XMLHttp.

  • Jonathan

    Some disadvantages of XMLHttpRequest vs. hidden IFRAME:
    * In IE, XMLHTTP depends on ActiveX, so if users have that turned off (as they should), it won’t work.
    * Supports older browsers

    Some advantages of XMLHttpRequest vs. hidden IFRAME:
    * Better performance (in my tests)
    * You can access the HTTP response code and respond differently (e.g., 200 vs. 404). With IFRAME, you have to try to parse the returned HTML/text, which is iffy. (If IE has “friendly HTTP errors” turned on, your JavaScript will get an access denied error when trying to access the IFRAME contents.)
    * In Safari and Gecko, you can find out virtually instantly that the server is down, whereas with IFRAME, you have to wait for timeout.
    * Feels like less of a hack. Although the object is created differently, once you have the object, you can interact with it the same way across all modern browsers.

    For my company’s application, the JavaScript object which manages data transactions with the server will try to create an XMLHttpRequest connection, but will fall back on an IFRAME-based connection if it cannot.

  • How is the accessibility issue not going to suffer here? Updating pages without notifying the user is all well and good if you’re paying attention, but what about screen readers and retrograde platforms like smartphones which are always two steps behind the cutting edge of these sorts of technology?

    Sounds like a great idea, but how is it helping the cause? Just seems like a step backwards in some ways.

  • moltar

    What is going to be really hawt in ’05 is Ruby on Rails + JS on XMLHttpRequest + CSS. We will see some top class site get developed. We already seeing them now, but only a few.

  • Anonymous

    onerror=”document.getElementsByTagName(‘body’)[0].innerHTML = ”;”

  • I’m a designer using a Mac to code, and testing on multiple platforms/browsers, however I don’t have XP under service pack 2. I’ve been told that this configuration is giving lots of problems with javascript (I wasn’t given exact examples but was told there are lots of upset developers), has anyone else had experience of this?

  • I have a shareware editor with built-in syntax checker for Javascript, so any increase in Javascript activity is all good! Checkout

  • I really hope that 2005 will be year of DOMains.

  • itchybrain, so far I’ve only noticed a problem when I’m testing JS locally. The local security setting for XP trigger some kind of ‘Danger Will Robinson!’ alert forcing you to OK the actions of the script manually. When I moved the script to the live server it ran fine.

  • Thanks Alex, glad to hear it, I want to jump a couple of levels in my website functionality and was worried when I heard javascript might be causing trouble for these (large amount of) users.

  • Colin

    I have been using XMLHttpRequest via vcXMLRPC for a while with great sucess.

  • eelbaz

    I have been developing bleeding-edge web applications since 2002 utilizing emerging techniques via DOM and browser Micro Requests (my coined term for any mechanism that sends and retrieves data directly from the browser without UI reloading the user’s browser), with emerging techniques for sending and receiving data such as XMLHttpRequest I don

  • mmj

    In a previous blog entry, a commenter asked why XMLHttpRequest was any better than using a hidden iframe (or script) element ashas been available for years, and I would like to reinterate this question. XMLHttpRequest is a proprietary extension to JavaScript that was implemented first by Microsoft and is now available on recent Mozilla browsers (and some versions of Safari, I believe). It is less well supported than the former methods, and it works slightly differently between Microsoft and Mozilla’s implementation. Its main benefit is the ‘synchronous’ mode, though I personally prefer the ‘asynchonous’ mode, as it does not stop the other behaviours of the page while something is loading.

    Is there any indication that XMLHttpRequest is here to stay, and is going to be included (in its present form) in any public standard? It seems that the level 3 DOM specification has chosen a different path with its Load and Save specification.

  • Pingback: arkitrave :: architecture, web design, and stuff » CSS background images: content or presentation?()

Get the latest in JavaScript, once a week, for free.