JavaScript in Chrome

Google Chrome has taken the browser world by storm. It makes for an exciting release, no doubt, especially with a brand new JavaScript engine on the table.

However the most important question, to JavaScript developers, is: How will this affect my normal development routine? I’ve done some research, talked to some developers, submitted some bugs and come back with a list of things that you should probably be aware.

In all, there are some exciting tweaks, simple bugs, and baffling removals.

Timer Delay

Absolutely the most exciting change: Timer delays are the value that you set. For example if you do:

setTimeout(someFunction, 2);

then someFunction will attempt to execute in 2 milliseconds (depending on if there’s any other extenuating circumstances, naturally).

The only exception to the above is if a timer delay of < 1ms is provided then it will be rounded up to 1ms. I chatted with Mike Belshe, the developer who implemented timers in Chrome, and he hopes to completely remove that delay at some point. In browser development every millisecond counts.

I’ve done some analysis on this in the past and found that all browsers bottom-out at a certain point. Generally it’s around 10-15ms – if you provide a timer delay any smaller than that value it’ll be rounded up to the browser’s minimum.

There is no specification stating the level at which a timer minimum should work – and that’s a good thing – think of a mobile device. If a processor-limited mobile device wanted to raise the minimum bound for a timer it should be allowed to do so. At the same time a browser should be able to provide any lower bound that it can.

The obvious question becomes: Why aren’t other browsers doing this? There are a couple reasons:

  1. It will allow the user to peg the CPU, blocking the browser’s user interface. This isn’t an issue in Chrome since each site is contained within its own process (the CPU will still be pegged but only the host site will be affected).
  2. It may have some unforeseen side effects. This is the tricky part that no one is sure about at this point. It may cause weird problems in some sites – but no one is really sure yet. Chrome is being the canary-in-the-coalmine on this, keeping track of any new problems.

One muted question existed concerning performance tests. If a performance test used a timer interval less than 10ms would Chrome get an unnecessary advantage? The Chrome team did some research and they were unable to find any tests that did this – but I’m sure if one such test existed it could be, easily, rewritten to work better across browsers.

No Script Execution Dialog

In most other browsers if you try and run a consecutive piece of JavaScript for too long (for most browsers it’s around 5 seconds) a dialog will pop up asking the user if they wish to stop the execution of script on the page.

No such dialog exists in Chrome. Since script execution is confined to each process they simply allow it to run unchecked. If you wish to stop execution you must close the tab and re-open it. I’m not sure if this is the right UI for the task (maybe if a long-running script is executing and the user closes the tab then a dialog should pop up).

Personally, I’ve been having fun with this – keeping a page with a while(true){} open at all times, while running Chrome.

Update: A number of readers have reported that they actually have been able to trigger a long-running script error dialog. Although there doesn’t seem to be much rhyme-or-reason as to when it appears. (I wasn’t able to get it to come up, for example.) Here’s a picture from Andrew Hawken:

for loop order

Currently all major browsers loop over the properties of an object in the order in which they were defined. Chrome does this as well, except for a couple cases (V8 bug, Chrome bug).

You can see the issue in the following demo:

var obj = {first: [1, 2, 3], second: "blah"},
  str = "<b>A property contains an array:</b><br/>",
  count = 1;

for ( var i in obj ) {
	str += (count++) + ": " + i + "<br/>";
}

str += "<hr/><b>Properties all contain strings:</b><br/>";
obj = {first: "blah", second: "blah"};
count = 1;

for ( var i in obj ) {
	str += (count++) + ": " + i + "<br/>";
}

window.onload = function(){
	document.body.innerHTML = str;
};

If an object contains a value which is not a primitive (as is the case in the first example) then its properties will be enumerated in a different order from which they were defined.

This is an interesting bug due to one fact: This behavior is explicitly left undefined by the ECMAScript specification. In ECMA-262, section 12.6.4:

The mechanics of enumerating the properties … is implementation dependent.

However, specification is quite different from implementation. All modern implementations of ECMAScript iterate through object properties in the order in which they were defined. Because of this the Chrome team has deemed this to be a bug and will be fixing it.

Text Node Serialization

This is, currently, causing the only regression in jQuery, for Chrome. It’s an odd WebKit bug which causes < and > characters to not be serialized to &lt; and &gt; when put in a text node. This has already been fixed in WebKit trunk and will be fixed the next time Chrome syncs its source.

Gears / Client-Side Storage

This is a tough nut to crack: Google has opted to bundle Gears directly with Chrome (which is a whole other discussion) but has explicitly removed WebKit’s HTML 5-compatible Client-Side Storage API.

Gears has its SQL database API bundled (contained within its own namespace and using its own API – different from the HTML 5 API) which makes this especially strange. Why, when there’s two client-side storage implementations on the table, would you pick the one that’s less spec-compliant?

I’m willing to give them the benefit of a doubt, especially considering that the Chrome FAQ mentions this case explicitly, but it definitely leaves me feeling quite confused.

Honestly, not much has changed in Chrome, over WebKit/Safari 3.1. The Chrome team hasn’t written any new features (save for those contained within Gears) or implemented any new specifications (quite different from the JavaScript situation in Internet Explorer 8). I realize that we’re still very early in the release of this browser and I hope to see many excellent contributions make their way into the Open Source WebKit codebase via the Chrome team.

Posted: September 5th, 2008

Subscribe for email updates

51 Comments (Show Comments)


Comments are closed.
Comments are automatically turned off two weeks after the original post. If you have a question concerning the content of this post, please feel free to contact me.

Secrets of the JavaScript Ninja

Secrets of the JS Ninja

Secret techniques of top JavaScript programmers. Published by Manning.

Subscribe for email updates

John Resig Twitter Updates

@jeresig / Mastodon

Infrequent, short, updates and links.