HTML and CSS Reference
In-Depth Information
Why use a worker?
If you've ever written any dodgy JavaScript that goes haywire,
causing your browser to start fuming like it's about to explode,
then you have experienced the single-threadedness of brows-
ers. Eventually, if the browser's smart, it'll give you the option to
terminate the dodgy code, something like
Figure 10.1
.
FIGURE 10.1
Some browsers will
interrupt JavaScript that's gone
wild, and give you the option to
nuke it into space.
More worrying is the much more subtle issues. Say you've writ-
ten the latest and greatest web application that does the most
amazing photo manipulation. You're using all the l33t skills you
learnt from this topic—canvas, storage, oline applications—but
when it comes to adding a photo fi lter, it takes 30 seconds. It's
not the 30 seconds that's the problem; it's the fact they can't do
anything in the browser for those 30 seconds. What if your user
changed her mind and wanted to cancel the fi lter? Obviously a
situation you want to avoid.
This scenario is perfect for a Web Worker because the entire
fi fi t e r p r o c e s s fi in g c a in h a p p e in fi in t h e b a c k g r o u in d , a in d t h e m a fi in
browsing window is left alone to continue to be responsive to
your visitor's requests.
Creating and working with workers
Yo u c a n t e s t f o r W e b W o r k e r s u p p o r t b y c h e c k i n g w h e t h e r t h e
object is undefi ned:
if (typeof Worker != “undefined”) {
// do the jazzy stuff
}
