[whatwg] WebWorkers vs. Threads

[Shannon]

I've been following the WebWorkers discussion for some time trying to 
make sense of the problems it is trying to solve. I am starting to come 
to the conclusion that it provides little not already provided by:

setTimeout(mainThreadFunc,1)
setTimeout(workThreadFunc,2)
setTimeout(workThreadFunc,2)
....

This is especially true if our main function sets up a "thread-safe" 
communication channel of some sort.

Obviously WebWorkers would make all this clearer and possibly easier but 
surely any number of free JS libraries could do that too. The only 
feature of WebWorkers that Javascript can't emulate is the ability for 
the worker to hang around after a page is closed; but I think this 
clearly falls into the category of a "web annoyance". When I close a 
page I want it gone - immediately. Passing workers around between pages 
sounds like something that would be good for advertising banner network 
trackers to avoid privacy settings.

I believe that babysitting developers (through feature elimination) is a 
bad idea. While WebWorkers aims to protect developers from common 
mistakes it will probalt force them into adopting worse hacks and 
workarounds. There is still a common conception of Javascript as a toy 
language, and in many ways that is true. However HTML5 calls itself a 
"WebApplications" language and we are indeed entering a time where many 
sophisticated desktop applications are being ported to Javascript. This 
raises a new issue, which is how do you port a threaded application to a 
language with no real threads or mutexes? With great difficulty I imagine.

One of the Mozilla JS developers has come out gunning against 
traditional threading in JS so it may be we never see an official thread 
object anytime soon ("over his dead body", in his own words). I realise 
WebWorkers tries to solve his concerns (mainly race conditions) by 
preventing  direct shared access to global variables but again this is 
something a threading library or good programming style should be able 
to solve. The workaround for webworker limitations is settimeout hacks 
so I wonder whether this is going to create horrible hybrid 
webworker+setimeout code that is generally unreadable.

Another issue with eliminating threads is that they are very desirable 
to developers. Because they are desirable it's likely that one of more 
browser vendors may go ahead and implement them anyway, essentially 
"embracing and extending" HTML5 and ECMAScript. If this happens then its 
likely a large number of popular multithreaded desktop applications will 
only be ported to those browsers. History has already shown us the 
problems this causes.

I am aware that the use cases and feature set of Web Workers has not 
been agreed on yet and there may be things I've overlooked. However I 
would much rather see an API that gives the developer more options and 
allows them to use or abuse them as required than a crippled API that 
pushes them into proprietary extensions, plugins and hacks to achieve 
something that every other major language already provides.

Shannon