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.
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’:
http://msdn.microsoft.com/msdnmag/issues/04/08/CuttingEdge/
January 5th, 2005 at 3:00 pm
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.
January 5th, 2005 at 8:24 pm
There are 3 things that are going to be huge in 2005, and one of them is XMLHttpRequest (the other two are del.icio.us and WordPress). XMLHTTPRequest allows for interaction between del.icio.us and the client browser, and this is something I think we’ll see a lot of this year.
January 5th, 2005 at 9:39 pm
I wonder, can we use serverside sessions with XMLHttpRequest ?
January 6th, 2005 at 3:19 am
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).
January 6th, 2005 at 9:15 am
Look at this software http://www.innuvo.com/. You can write all your code in Java which is complied into javascript. It makes programming dynamic javascript much easier.
January 6th, 2005 at 12:30 pm
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.
January 6th, 2005 at 4:56 pm
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.
January 6th, 2005 at 7:00 pm
seems like javascript finally has a purpose. except from opening annoying popups.
January 6th, 2005 at 7:59 pm
Hi i’ve implemented a simple XMLHttpRequest in this page http://www.smiwrap.it/modulo.php?IdPage=Offerta&Id=30&lang=en
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.
January 10th, 2005 at 9:39 am
I used XMLHTTPRequest extensively in my latest project – a CRM system (24SevenOffice.com). I agree…with better use of the DOM and smart techniques like XMLHTTPRequest, web-applications will become very useful.
http://sleepyhead81.blogspot.com/2005/01/web-applications-in-2005-case-study.html”>Have a look at my post about web-applications and the restult of the CRM system I made.
January 10th, 2005 at 2:34 pm
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
browser.
http://trimpath.com/project/wiki/JavaScriptTemplates
January 12th, 2005 at 10:26 pm
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.
January 20th, 2005 at 8:36 am
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.
January 20th, 2005 at 9:50 am
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.
January 20th, 2005 at 9:52 am
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.
January 20th, 2005 at 11:26 am
style=”display:none;”>
January 21st, 2005 at 10:05 pm
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?
January 24th, 2005 at 7:28 pm
I have a shareware editor with built-in syntax checker for Javascript, so any increase in Javascript activity is all good! Checkout http://www.scryptik.com
January 24th, 2005 at 11:14 pm
I really hope that 2005 will be year of DOMains.
January 27th, 2005 at 4:34 pm
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.
January 27th, 2005 at 7:38 pm
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.
January 31st, 2005 at 1:39 am
I have been using XMLHttpRequest via vcXMLRPC for a while with great sucess.
http://www.vcdn.org/Public/XMLRPC/
February 10th, 2005 at 8:18 am
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’t see 2005 as being the year of the DOM, as a whole I see 2005 as finally being the year of REAL functional browser based user interfaces and applications.
I hope we begin to see more production quality applications of the techniques utilizing micro Requests and W3C Standards.
February 14th, 2005 at 12:08 pm
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.
January 18th, 2005 at 8:23 pm
[...] From a philosophical, separation-of-content-presentation-behavior viewpoint, is the CSS background image a piece of content inside a style sheet, which should be presentation only? [...]
October 27th, 2005 at 7:30 pm