Yahoo! User Interface Blog

with Statement Considered Harmful

JavaScript’s with statement was intended to provide a shorthand for writing recurring accesses to objects. So instead of writing

ooo.eee.oo.ah_ah.ting.tang.walla.walla.bing = true;
ooo.eee.oo.ah_ah.ting.tang.walla.walla.bang = true;

You can write

with (ooo.eee.oo.ah_ah.ting.tang.walla.walla) {
    bing = true;
    bang = true;
}

That looks a lot nicer. Except for one thing. There is no way that you can tell by looking at the code which bing and bang will get modifed. Will ooo.eee.oo.ah_ah.ting.tang.walla.walla be modified? Or will the global variables bing and bang get clobbered? It is impossible to know for sure.

The with statement adds the members of an object to the current scope. Only if there is a bing in ooo.eee.oo.ah_ah.ting.tang.walla.walla will ooo.eee.oo.ah_ah.ting.tang.walla.walla.bing be accessed.

If you can’t read a program and be confident that you know what it is going to do, you can’t have confidence that it is going to work correctly. For this reason, the with statement should be avoided.

Fortunately, JavaScript also provides a better alternative. We can simply define a var.

var o = ooo.eee.oo.ah_ah.ting.tang.walla.walla;
o.bing = true;
o.bang = true;

Now there is no ambiguity. We can have confidence that it is ooo.eee.oo.ah_ah.ting.tang.walla.walla.bing and ooo.eee.oo.ah_ah.ting.tang.walla.walla.bang that are being set, and not some hapless variables.

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

Synchronous v. Asynchronous

XMLHttpRequest can operate synchronously or asynchronously. Many people prefer to use it synchronously. When used this way, the JavaScript engine is blocked until the interaction with the server is complete. Because it blocks, the flow of control looks a lot like an ordinary function invocation. Temporal complexity is abstracted away, leaving a very familiar and comfortable programming pattern. It works particularly well when the server is on the same machine, or nearby on the LAN. Unfortunately, it can perform very badly if the server is under heavy load, or if the browser is connected to the server over a slow link. Because the JavaScript engine is blocked until the request completes, the browser will be frozen. The user cannot cancel the request, cannot click away, cannot go to another tab. This is extremely bad behavior.

Fortunately, XMLHttpRequest provides an option for asynchronous operation. When you set the asyncFlag flag to true, the JavaScript engine does not block. Instead the request returns immediately, with a potential action that will be triggered later when the result on the request is known. The Yahoo! Connection Manager provides a very nice interface for this.

var cObj = YAHOO.util.Connect.asyncRequest('GET', 'http://myservice.com?req=update', {
    success: function (response) {
        alert(response.responseText);
    },
    failure: function (response) {
        alert(response.statusText);
    }
});

You supply two functions. Your success function contains everything that should happen as a result of the request succeeding. So if the request was to obtain some JSON text which should be delivered to the app.update method, then your success function could be

    success: function (response) {
        app.update(eval('(' + response.statusText + ')'));
    }

Asynchronous programming is slightly more complicated because the consequence of making a request is encapsulated in a function instead of following the request statement. But the realtime behavior that the user experiences can be significantly better because they will not see a sluggish server or sluggish network cause the browser to act as though it had crashed. Synchronous programming is disrespectful and should not be employed in applications which are used by people.

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!