I really don't count Chrome Frame as "works in IE." When you say, "works in IE", it has to mean, "works in the standard install of IE." Because that is the case that most people care about. We deal with IE primarily because we can't convince corporate clients to install anything. If I could get them to install Google Chrome Frame, I'd get them to install Google Chrome, period.
I (the author) would agree with this statement, except for the baffling fact that Google Chrome Frame has a non-zero number of users. So obviously some people thought "I don't want a new browser, but I'd be OK with installing this plugin."
Strangely enough this was the sentiment at Google. I was talking to a Googler in a recent GTUG meeting and they told me exactly that: Some people won't change browsers but they are OK with installing a plugin.
Well he didn't exactly say it 'works in IE', just that it works in IE with a plugin.
It's like saying no browser can run flash games... because, they can't... unless you've got the plugin.
Your point about the corporate clients is definitely true, you can't install Chrome Frame in places where you can't install a new browser (at least, most of the time). But that's not the only place people use IE*.
Flash is a poor example because the majority of consumer PCs sold already include a reasonably recent version of Flash. This is why I'm still building adgames in Flash when I'd much rather use Unity3d. Unity adds the friction of a plugin install, whereas Flash is likely already installed.
Similarly, getting people to install Chrome Frame adds some friction (though how much depends on how the install is streamlined).
I'm not sure I'm with you here. A lot of offices have really old computers purchased around the time of Windows XP SP1 and the version of flash shipped on those will leave quite a lot to be desired.
So maybe I should have said it's like saying IE (in those types of settings, anyway) doesn't support new flash games because they don't have the right version of the plugin :)
This sounds great, but if all you're going is sending an AJAX request in the worker and stuffing the response into some element, I don't see much benefit. Most of the time you use an event handler to deal with the response so you're not blocking the main thread anyway. However, if there is any computation, DOM walking, or markup generation, I would definitely use a worker for that.
Unfortunately, this doesn't help the 60% of my users who really need it: the IE users with slow JS engines. I've measured 1-2 order of magnitude differences in performance between IE and Firefox/Chrome/Safari in my codebase, and there's just not much I can do for the IE users without withdrawing functionality I'm required to give them. (I wish Chrome Frame was an option, but I suspect that if they had the ability to use that, they'd have the ability to change browsers too, and they don't.)
What are some use cases for worker threads? Initially I thought there must be loads, but when I considered that XHR is asynchronous anyway, and that Worker threads don't have access to the DOM...
I guess it would be good if you wanted to use your visitors CPU in the background for password cracking or for the various distributed network stuff like SETI.
But what practical benefits do web workers provide for normal web development?
This has absolutely nothing to do with threads, though, does it? It's messaging, plain and simple.
Presumably the browsers will implement it using threads, but they could just as well pass the messages off to another PC for all your JavaScript can tell.
In the browser, all DOM events and timers are executed in the main thread along with the html parser, dom layout and rendering, css parsing etc. So if the javascript handling an event takes too long it will block everything else and hence UI responsiveness suffers. With web workers, browser starts a real seperate thread, that will not interrupt the main page thread, hence responsiveness doesn's suffer because of long javascript execution.
I've got into the (probably bad) habit of using setTimeout(returnMethod,1) as a means of overcoming this. It's especially useful for long scripts that fire in the body onLoad event
This works, but the immediate danger I see is that the user can be interacting and triggering other events while you are still acting on the original request. Results will vary from "that's better for them" to "insanity!" depending on what you are doing.
AFAIK, you can also get async JS performance by storing your javascript in an external file, then creating a <script> DOM node, setting the 'src' attribute, and appending it to the head/body.
[Edit] Ooooh, it's Mark Pilgrim, of course! Great stuff!