The days of old - the browser object model

When I started with JavaScript everything was about the browser object model (BOM). The DOM recommendation was not quite finished yet and the lack of browser support stopped it from being a standard (to me the implementation and general market support makes something a standard, not that a group defines it as one).

When you were talking JavaScript, you talked about document.write() to produce content, forking code to be supported by browsers with document.all and document.layers, scripting of frames and interaction and opening of different browser windows with the window.open() method.

In order to access the content of the current document (or the one in a popup window, a frame or, in the case of Netscape, in a layer you had document.images, document.links and last but not least document.forms with its elements collection. You used the name attributes to access different elements like forms.myform.surname.value and other abominations.

First steps outside the HTML world

That said, JavaScript was already reaching further. One of the first things I did with it outside the browser was 1999. I helped other developers in my company (etoys back then, RIP) to work faster and not having to do the same work over and over again by customizing the company-approved editor: Allaire Homesite 4.0. Homesite had an Application object that allowed you to access parts of the application itself, the document you are currently working on and all the others that are open. This allowed you to write quite powerful Macros in an easy manner using JavaScript. You also had access to the file system via the internal user dialogs.

In the browser world you also had bespoke implementations of JavaScript - first and foremost Microsoft's JScript to script Internet Explorer and access its chrome and other parts that weren't available to other browsers. If you renamed your HTML document from example.html to example.hta you even had a "HTML Application" which worked outside the browser's security model and gave you access to the file system to read out folders and file names.

Enter the DOM and subsequently DOM Scripting

Across the browsers, the DOM got support starting with patchy implementations in IE5 and Opera and finally getting full-on support and developer tutorials in Netscape 6 based on Gecko as the rendering engine and Spidermonkey as the scripting engine. This lead to Phoenix, then to Firebird and finally to Firefox as we know it now.

In order to flag up a change in the JavaScript development world, "DOM Scripting" got coined as a term for writing "modern" JavaScript. Instead of relying on custom browser implementations our scripts started using the W3C standard DOM to access the document and gave us full access to anything that is inside HTML tags. You can read out the hierarchy of the document, traverse the element tree and access, alter or even create elements as and when you need them.

This power made a lot of the cumbersome browser hacks and workarounds obsolete and allowed us to write cleaner scripts. And just in time as malware exploits and annoying advertising practices and the software counter-strike (PopUp blockers) made it less and less of a good plan to rely on multiple windows or frames. DOM scripting allowed us to create much slicker interfaces in a clean manner.

Ajax - breaking the rules

Then things got really wild when Ajax got its name. The use of XMLhttpRequest to create asynchronous calls was nothing new, but giving it a name and a methodology to follow worked out swimmingly.

Technically this was right up the alley of DOM scripting as the returned data in Ajax is XML, and you need the DOM or XSLT to convert this into data that can be displayed by a browser inside a HTML document. However, as we sent more and more complex information via Ajax, developers got bored of the cumbersome conversion and started to use responseText with the non-standard innerHTML to output data instead. This was so powerful and easy that innerHTML actually became part of the W3C recommendations.

This is where we are now, we use JavaScript a lot for all kind of Ajax applications that simulate rich client interfaces with CSS, JavaScript and HTML. And of course this leads to problems:

* We break the normal use of browsers and have to fix things like browser history and bookmarking with hacks
* We run into more and more security problems, as every JavaScript on the page is running with the same authority and we do send user data over an easy to intercept channel.

Fixing the back button

The first issue is quite known and we have to resort to hacks like fragment identifier updating and hidden iframes to seed the browser history (libraries make that easy for you, for example the Yahoo User Interface Browser History Manager).

If you look at it from a very pragmatic point of view though than it is a problem of the browser and shouldn't need our input. Ajax applications are a de-facto standard way of working and browsers should provide you with a technology hook to create them and keep a consistent application state.

This is happening right now, as both IE8 and the HTML 5 working drafts talk about a hashchange event that would allow you to seed the browser history, thus making bookmarking and the back button work without resorting to an iframe.

Trying to add higher security

The security issues are a much bigger problem, especially when we think realistically and consider that we will build more and more modules for application frameworks and networks (like Facebook) than page/site based products in the future. There is not much you can do to sandbox JavaScript as even embedding in an iframe allows the script to modify the top.location property and redirect the current page to other sites without the user's consent.

One approach is to write a pre-processor or converter that checks JavaScript for sanity and filters out potentially dangerous code. One of those is Caja.

The other option is to only allow a sub-set of JavaScript in third party code we implement in our systems. This is the approach of AdSafe and is much less overhead but also could mean limiting third party solutions.

Broadening the horizon of JavaScript development

If we take off our blinkers and look around the whole developer world we find that there is a group of developers that have been writing JavaScript for a long time, came up with good best practices and very impressive code without ever touching a browser: Flash developers.

As ActionScript is executed within the Flash environment none of the browser quirks and problems appear (except for the back button and browser history and the solution is the same). This lead to quite an impressive group of developers that have a very pragmatic view of JavaScript. With Adobe now offering AIR as an application framework that allows you to write HTML/CSS/JavaScript applications in an installable manner we should start mixing the world of Flash development where everything just clicks (ok, not really, but much more than outside it) and the vast knowledge of how browsers fail and what security issues to avoid when writing JavaScript. What this will give us is truly portable applications and code and idea re-use the like we never imagined possible.

Other products that try to help us patch the browser are for example Google gears, which allow you for example to have a local data storage and keep the interface of web applications very responsive even when there is a lot of calculation going on. The way Gears does that is by allowing multiple JavaScript threads that only do the heavy computation lifting whilst the main browser thread can go on keeping the interface in check.

What will the future bring?

JavaScript is here to stay, it is easy to learn and provides instant satisfaction when trying it out. Browsers as we know them now will change drastically and maybe make way for more clever applications and frameworks that allow us to use the same technologies and knowledge without the pain and uncertainty. The skillset of JavaScript is a great one to have right now and we can only make it better by keeping an open mind to new ideas rather than dwelling on knowledge gained painfully in the past.

Christian Heilmann
Yahoo Developer Network