
An implausibly illustrated introduction to HTML5 Web Workers - tswicegood
http://wearehugh.com/public/2010/08/html5-web-workers/
======
madair
I don't really care for threaded Javascript in the browser, but damn can that
dude illustrate a point! Cool!

[Edit] Ooooh, it's Mark Pilgrim, of course! Great stuff!

~~~
ugh
You might also enjoy: [http://wearehugh.com/public/2010/08/html5-video-
accessibilit...](http://wearehugh.com/public/2010/08/html5-video-
accessibility/)

~~~
wooptoo
> Standards suck. It's just that everything else sucks more.

Made me smile.

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

~~~
MarkPilgrim
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."

~~~
ndimopoulos
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.

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

------
mike-cardwell
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?

------
alexbosworth
Web Workers don't work on iOS do they? At least my iPad doesn't seem to
support it - ran into this issue using Web Workers on my project

~~~
sprout
God I hope not. I really don't want webpages serving up multithreaded
JavaScript on anything with fewer than two cores.

Say what you like about Flash, it always confines its evil to a single core.

~~~
mattmillr
Which is a real pain when you're trying to develop a responsive Flex
application. (Something I have to do at work, not because I want to.)

------
Groxx
Suddenly, the Safari Extension model makes a _lot_ more sense.

------
cubicle67
what's not clear from this is scope. Does each worker have its own namespace?

~~~
mike-cardwell
This should be trivial to test...?

~~~
cubicle67
true, but I was at work when I wrote that and was wondering if anyone else out
there had a quick answer for me.

------
gcb
"Sanity of threads + robustness of web development.

What could possibly go wrong?"

Genius!

~~~
bruceboughton
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.

~~~
gcb
Imho It's very analogous to tread in the sense that its very dangerous for
programmers that are clueless.

And have you ever interviewed for a Js opening where 100% of them knew the
most basic implications of events?

That will be fun

~~~
bruceboughton
JavaScript in general is very dangerous for programmers who are clueless...

------
hasenj
I don't really understand how's this different from events.

> and your web app still assumes that my browser can only do one thing at a
> time

Um, no it doesn't. What makes you say that?

~~~
v413
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.

~~~
cubicle67
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

~~~
jws
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.

------
The_Igor
Here is a short write up I did for my company blog after attending the now
famous HTML5:The Future Of The Web mini conference.

[http://blog.mediaplex.com/2010/06/02/html5-why-you-
should%C2...](http://blog.mediaplex.com/2010/06/02/html5-why-you-
should%C2%A0care/)

~~~
mike-cardwell
Content-less article, irrelevant to the discussion. Pure spam.

~~~
The_Igor
"mike",

There is no need to insult my writing. The original post was about HTML 5 and
so was my write up.

