[whatwg] WebWorkers vs. Threads
shannon at arc.net.au
Sat Aug 9 22:42:42 PDT 2008
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:
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
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
language, and in many ways that is true. However HTML5 calls itself a
"WebApplications" language and we are indeed entering a time where many
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.
More information about the whatwg