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:

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:

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).

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).

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.

I have been quite pleasantly surprised at how complete V8 is. It was really nice loading up my company’s web site (powered by jQuery, of course) and testing all of my code and seeing it all just work. And it’s a testament to the jQuery team that there’s only been one regression. Ensuring application code works is vastly different from ensuring library code works.

Ditto on the Gears vs HTML 5 API. I said a few months ago I was concerned with the fragmentation here. I don’t understand why they didn’t disable the relevant Gears code instead pushing people to HTML 5 (or better yet, update Gears appropriately).

While they may have good intent to support it in a future release, during this time in between, developers are left with a choice… which favors the non-standard Gears implementation since it can be installed in more places. When business makes the decision… standards takes a back seat, something I don’t like to see.

I am not really bothered by Google’s decision not to support HTML5 API in their first release for some reasons.

First they are building a browser from scratch, they will have an enormous work anyway to support the current features the other players support already. Why to spend time supporting features that an majority of developers won’t use because IE6 and IE7 will last for a long time yet?

Secondly, if the Gears team is planing to support the HTML5 spec and the Chrome will always ship it bundled, why can’t they choose to wait their implementation over to using Webkit right now?

And lastly, some non-standard feature implementations in the past wore not adopted and others non-standard are used today across all browsers (i.e. innerHTML in Javascript). Let’s await and see if the Gears implementation become popular, may be we could see some changes in the spec, who knows?

And of course, by their movement we can see an growing numbers of developers deploying features using gears because of chrome. They are giving a little push to their Gears comrades for sure.

@Iraê It’s not that they didn’t implement a particular new feature that they’d have to write “from scratch”. The third-party engine they used when building their browser “from scratch” already had HTML5 support, which they turned off. Instead they chose to ship a Google extension providing a competing API, which they had to adapt to their version of an engine.

I do think they will provide the standard APIs in time, but I think this shows that they prioritized their proprietary APIs over open standards.

@Iraê: I disagree completely. “First they are building a browser from scratch” that’s not true at all. This feature was already done for them – it came as part of the WebKit engine! They had to forcefully go through and remove it from the source (extra work) just to get to where they are. It required more work, on their end, to do this than just leaving it in.

“Why to spend time… because IE6 and IE7 will last for a long time yet?” This doesn’t make any sense. Why bother implementing any new standard if IE6 and 7 will never support them.

“Secondly, if the Gears team is planing to support the HTML5 spec and the Chrome will always ship it bundled, why can’t they choose to wait their implementation over to using Webkit right now?” Because right now their implementation doesn’t match the specification. It matches their own API. They had an implementation that completely worked – it was already there, baked in to the engine.

“Let’s await and see if the Gears implementation become popular, may be we could see some changes in the spec, who knows?” Because it’s not going to happen? Unless the W3C decides to add a new “gears” global object and place all pieces of HTML 5 inside of it, it’s just not going to come around.

“They are giving a little push to their Gears comrades for sure.” Shouldn’t they be pushing their “standards comrades” first – Gears second?

[Editorial note: the bare left-angle-bracket you used sort of breaks the post in some readers; in mine, the line reads “The only exception to the above is if a timer delay of Mike Belshe, the developer who implemented timers in Chrome” – which is funny, but probably not intended.]

By the way, one correction. It is a little inaccurate to say that the Gears guys did extra work to disable WebKit’s database support. The work was probably limited to turning off an ifdef, and truly supporting it would have required making the back end work with their process architecture would have required nontrivial work (which they now plan to do).

But I do think it is fair and correct to say that they prioritized the (likely lesser but still nonzero) work to support Gears over the work to support standards. Indeed Gears itself has not done much to move towards the HTML5 standards APIs, which, to their credit, they have been a big part of designing.

The truth is nuanced here. Google isn’t being nasty, but their actions so far do not lend substance to their stated support for standards.

is it possible google chose to go with gears implementation for client side storage rather than web kit implementation of HTML5 because of android? They want app’s ready to run on android?
Could that be a reason?

In my point of view they should bring the standards first and secondly gears. I agree with you. But I’m still not convinced this is the best choice for them.

Once you said yourself, when talking about the jQuery plugin architecture (correct me if I’m wrong) that every new feature was not a meter of time to code and usefulness to the lib user. Every feature is something to maintain, debug, optimize, test and etc.

By disabling the SQL API they didn’t have to look into performance, sendboxes, and many more issues. IMHO this was probably a decision of cost/release date and the time spent to remove it was probably smaller than maintaining it in the first beta.

As Maciej Stachowiak said: they could wish to make de SQL another process so the user can kill it and in this case the UI and host page will have to handle the error flawlessly. If this is so, they will have to patch the SQL API code a lot.

Or even, may they be expecting to make some kind of wrapper/translator to use gears to supply the SQL the HTML5 way? I don’t know, Is this is technically possible?

From developer build revision 1785,
“Try again to begin compiling the files that implemen the HTML5 database API. This time, I added a project dependency from WebCore to sqlite on every solution that includes WebCore.Review URL: http://codereview.chromium.org/466”

I think it was a mistake to only offer an asynchronous DB API. Although it might be good for page responsiveness, most queries in a client scenario are ultra fast and DB development is way easier in a synchronous environment.

running a web page with a while(true){} produces it, as does a javascript:while(true){} in the URL/search box, but only in some circumstances. I can force it to happen if its the first thing I do in the first tab after opening Chrome, however I have no idea what the rules actually are.

Thinking some more : I wonder if its something to do with % of total resource or resource used by the browser. I’m running it on a fairly old (and overloaded; it needs a reinstall) laptop. If I get a chance I’ll give it a try on my decent desktop.

@Dipen: It’s not clear what their reasoning is – we’ll have to ask them, I guess.

@Nosredna: It’s definitely still quite short. I hit it all the time in the performance testing that I do.

@bob, Adhip, Andrew: Thanks for the confirmation, I’ve updated the blog post. Now we just need to figure out what triggers it! I was able to have the while(true){} running in my browser, consuming 100% of the CPU, and not have any dialog appear so I’m not sure what the trick is.

@Iraê: “By disabling the SQL API they didn’t have to look into performance, sandboxes, and many more issues. IMHO this was probably a decision of cost/release date and the time spent to remove it was probably smaller than maintaining it in the first beta.”

I can agree that their motives may have been pure (don’t add it to the release in favor of a simpler overhead) but their actions speak louder than their words. Whatever issues they had with having the SQL API be accessible from a process were fixed in order to make Gears work, but not fixed in order to get the standards-compliant functionality to work. It’s really a matter of prioritization.

@Lucho: Definitely doesn’t look like it’s enabled, only that they’re starting to review the code for addition to the browser.

I think the ecma specification definitely needs to have the property order fixed. This is something I (and I’m sure other developers) depend on for behavior. otherwise, a simple configurable json object now needs ot be wrapped in an array in order to have predictable results…

i’d say chrome should go with the flow in this case and someone get this back to the spec team!

I like the way that Chrome handles view source, opening a new tab with line numbers and hyperlinks. It raises the question, “what would be the ultimate view source”? And the answer is probably Firebug.

So how about replacing Firefox’s View Source with Firebug? Press Ctrl-U to examine source, even change it and debug it, all in a new tab?

@mo: It’s because ActiveX is a proprietary microsoft technology, not a standard. You should only expect that code to work in IE. I have no idea why it works in firefox (mozilla is probably just being nice somehow).

I’m wondering (probably as all you do) how is it possible that instead of cooperation between existing browsers to merge they engines into one standard html/css rendering we now got brand new browser with it’s own standard. I’m not speaking about javascript only, there is problem with layout of some of my web-pages. They were all working great in all browsers (IE, FF, Opera… ) and now with Chrome I’ve got some divs lost all over screen (unwanted)

A timer resolution under 1ms is not feasible on Windows. Win32 timers have a practical resolution of about 20ms. The multimedia timers may provide slightly better resolution, but it’s hard to get under 10-12ms.

Interrupt servicing and queued DPCs, as well as thread scheduling, mean that you simply can’t be guaranteed the kind of precision you’re after on NT-based operating systems.

I accidentally stumble upon this page when I find if anyone in the Internet has the same problem as mine to see if it was my poorly coding or else…

I had the same problem as yours.

I found the Implementation object in Chrome doesn’t work as the same as other Firefox/Mozilla/Seamonkey counterpart. (I would not prefer it’s a bug but I don’t know what has been changed for Chrome’s Implementation object)

Thanks so much. Just tried your example and it worked beautifully in all three browsers. Think using XMLHttpRequest is a better approach anyway as this is the core of AJAX which is expected to be better supported by the ‘good’ browsers:-)

By the way I thought Chrome ran my application quite well. Didn’t see any issues in the CSS handling either.

I think chrome ll be a rival of firefox in future. But if didn’t be, i was be happy more. Because we’r trying to make our sites compatible with IE, Mozilla, Opera, Safari; thats enough brotha. I don’t want to try to compatible my sites for Chrome.

Look, http://www.nsohbet.com/ i did this site in 4 days. Site was simple, but i didn’t compatible it with all browsers.
Anyway, thanks for great article. I think i should add your blog to my feeds.

i agree with your chrome perspective, i found it’s interface like”oh yeah we’re on the comands of a starship”, regarding FF i havent updated to 3 , 2 it’s cool for me and i dont like those icons they added in the adress bar, keep thing simple.

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.