There’s a couple of ways of doing that:

1. Setting style properties in the DOM

divTest.style.backgroundColor = "red";
divTest.style.fontWeight = "bold";

2. Setting the style property to a CSS string

divTest.style.cssText = "background-color: red; font-weight: bold; margin: 0px 0px 0px 0px;";

3. Setting a CSS class name

divTest.className = "newStyle";

newStyle{ background-color: red; font-weight: bold; margin: 0px 0px 0px 0px; } 

Whichever way a style for an element happens there is a couple of things that need to happen:

1. Dispatch to the DOM
2. Style calculation
3. Layout calculation
4. Rendering

As JavaScript (and to some extent the browser) is single threaded the first three steps need to happen before the next JavaScript statement can execute. For example if you set the color attribute for the body you would expect that any children who didn’t specify a fontColor would now return the value just set on the body. E.g.:

var divTest = document.getElementById("divTest"); 
alert(divTest.currentStyle["color"]); // alert's #000000 (default)
document.body.style.color = "blue";
alert(divTest.currentStyle["color"]); // alert's blue

That works in IE in other browsers you will need to use the standard getComputedStyle. As the same thing happens for attributes involving layout it’s reasonable to assume that layout is also calculated before the completion of the JavaScript statement.

What doesn’t happen is the actual rendering of the updated page. This frequently causes developers problems. For example if you tried to show a “please wait” dialog while some long running synchronous operation completes you’d find that the dialog doesn’t display and the page isn’t updated. This is true in IE but other browsers have different behavior.

With this knowledge we can start to time and measure the different ways of updating the page. To do it fairly we need to only consider the different approaches but also the complexity of the page.

Trying the three approaches on a couple of pages gets some interesting results:

var list = document.getElementById("itemList"); // ul containing 100 li elements
for (var i = 0; i < list.childNodes.length; i++) {
    list.childNodes[i].innerHTML = "New Item #" + i;
}

It looks pretty harmless but you need to consider the length of the nodes is actually a lookup from the DOM and not a simple comparison. As it’s a lookup it’s also can change so for every loop that statement needs to be evaluated. Realistically in JavaScript the length of the collection is very unlikely to change during execution, mainly because JavaScript is single threaded and in in IE it shares the UI thread so only IE or JavaScript can be interacting with that collection (for most intents and purposes). Thus a simple optimization would be to cache the length outside the loop:

var list = document.getElementById("itemList"); // ul containing 100 li elements
var numberOfNodes = list.childNodes.length;
for (var i = 0; i < numberOfNodes; i++) {
    list.childNodes[i].innerHTML = "Item #" + i;
}

Really this doesn’t gain you much as it’s a small fraction of the time compared to what ever you’re going to do inside the loop. It does mean that if in the future engines unwind loops the code above would benefit as it’s a much harder to unwind a volatile loop. But writing code hoping that in the future engines can take advantage of it is a poor idea and not something worth pursuing. In general it’s probably a bad idea to code patterns for specific engines as it may be slower on others.

There is another way  to iterate over a list using a loop and that’s to walk the node list, itself using a while loop, something like:

var list = document.getElementById("itemList"); // ul containing 100 li elements
var node = list.firstChild;
var i = 0;
while (node) {
    node.innerHTML = "Item #" + i;
    node = node.nextSibling;
    i++;
}

If you time a 1000 iterations of each above loops you the following times in milliseconds:

Iterating nodes is probably less common a pattern in JavaScript as you have to be careful around cross browser differences and in making sure you get the right node. But it just so happens that in all major browsers it’s faster. Why? Probably because it’s more similar to how the list is traversed in their internally implementations, but that’s speculation.

Advice in a nutshell: Try to declare all your functionality within closures and avoid declaring variables in the global scope or any part on the DOM.

Background

When you declare a variable in JavaScript that’s in the global scope it is defined onto the window object e.g.:

<script type="text/javascript">
    var foo = 1;
</script>

Variable foo can be accessed from anywhere on your page as either foo or window.foo. That sounds great as it’s a way to share data across functions and scripts. While it certainly does that it does it at a cost.

Because it’s defined on window that means that the variable is actually now part of the DOM. Which doesn’t sound too bad, except that the DOM isn’t actually part of the JavaScript engine  in IE. Which might not make sense at first but look at this way, JavaScript is only one of the ways you can manipulate the DOM. The other obvious way is the HTML on the page itself, but more subtlety other script engines can manipulate the DOM. For example in IE you can have JavaScript and  VBScript on the same page. So now two different script engine can access the DOM and the variable window.foo.

This is where it starts to get complicated as a script engine can’t own DOM elements then they need to be brokered through a 3^rd party i.e. the host, IE (more specifically the IActiveScript host) . Now whenever you need to look up window.foo the JavaScript engine needs to ask the host if the host has that variable. Also doesn’t sound too bad, except the most logically way of doing this one in Windows is via a mechanism called COM. Now many books have been written on COM but if I was given a sentence to describe it I would say. COM is a technology that enables different components to communicate with each other either in process, out of process or over a network. As the DOM and the JavaScript engine are different components it sounds like a great match and it is. But of course the mechanics of making two separate components work isn’t so simple. It requires dynamic integration of objects and type marshalling all of which cost CPU cycles.

Comparison

Comparing the two different scripts below, the first reads the variable via the DOM 1 million times the 2^nd reads a local variable 1 million times.

Script 1

<script type="text/javascript">
    var dateStart = new Date();
    var someMessage = "yay a message";
    for (var i = 0; i < 1000000; i++) {
        var x = someMessage;
    }
    var elapsedTime = new Date() - dateStart;
    alert(elapsedTime);
</script>

Script 2

<script type="text/javascript">
(function () {
    var dateStart = new Date();
    var someMessage = "yay a message";
    for (var i = 0; i < 1000000; i++) {
        var x = someMessage;
    }
    var elapsedTime = new Date() - dateStart;
    alert(elapsedTime);
})();
</script>

Executing the test 10 times and then taking an average I got the following:

As you can see accessing variables via the DOM is a lot slower than accessing them locally, for me it was 8x slower. While a million access might sound like a lot it’s not actually that many, try using the IE8 profiler on some sites as you type an email or chat online and you might be surprised as to how much goes on, a topic for another day.

Bonus Tip: Timings in IE & Date

In IE8 and below the clock used by Date has a resolution of ~10ms but if you go to the developer tools and press start profiling we change the clock resolution to be 1ms. This has some other side affects but nothing to worry about.

Over the next few months I intend to blog about the tools in IE and general tips from what I’ve learnt of web development having spent the last year working in IE.

Well I just finshed what will be the final update to Popfly, to place the shutdown notice on the front page. As John has blogged about on our team blog Popfly will go offline on 8/24.  

If you do have projects on Popfly then you will lose access to them on 8/24 if you want to download you projects for prosperity (they won't run locally) then you can always add a .zip onto the URL of the project to get a packaged up zip. E.g.:

https://www.popfly.com/users/Team/Soccer.zip

https://www.popfly.com/users/Andy/LiveSpacesURLGenerator

One of the blocks we recently added to Popfly is “Campaign Contributions”. As many of you know the 2008 Presidential race is on! As part of the race the FEC requires that all individuals who contribute $50 or more have to report it and subsequently they expose the contribution as public record. At Popfly we decided it would be fun to import that data and using .net 3.5sp1 data services create a block where you can query that information. The information we collect includes the name, employer/occupation, amount, zip code and of course who the money was given too. It’s all public domain and can be found on the FEC web site. By exposing the data in Popfly though you can create some mashups of the information.

Simple bar graph, the first mashup I made takes a ZIP code and returns all the people who donated sums up the money and puts it on a graph. You can see the mashup below (or on Popfly at https://www.popfly.com/users/Andy/Campaign%20Contributions%20By%20ZipCode), and you can copy it and create your own version at https://www.popfly.com/users/Andy/Campaign%20Contributions%20By%20ZipCode.project.

Go ahead open it up! See how it’s made and have a play.

You can also create a new mashup using the block by going to: https://www.popfly.com/mashupcreator and search for “campaign” and you should see the block “Campaign Contributions” you can also find it by expanded the “New & Updated” category.

Try some of the operations, write your own queries! Help for the block is at: https://www.popflywiki.com/users;popfly;Campaign%20Contributions.ashx and you can find some help for writing your own custom queries at: https://www.popflywiki.com/DataServiceQuery.ashx.