An implausibly illustrated introduction to HTML5 Web Workers

http://wearehugh.com/public/2010/08/html5-web-workers/

by tswicegood • 16 years ago

108 33 16 years ago

wearehugh.com

madair• 16 years ago

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• 16 years ago

You might also enjoy: http://wearehugh.com/public/2010/08/html5-video-accessibilit...

prima-facie• 16 years ago

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

Made me smile.

gcb2• 16 years ago

"Sanity of threads + robustness of web development.

What could possibly go wrong?"

Genius!

samratjp• 16 years ago

Yes, it's all fun and games until someone pokes an async's eye.

bruceboughton2• 16 years ago

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.

gcb2• 16 years ago

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

Groxx• 16 years ago

Suddenly, the Safari Extension model makes a lot more sense.

cubicle673• 16 years ago

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

mike-cardwell4• 16 years ago

This should be trivial to test...?

cubicle673• 16 years ago

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

hasenj• 16 years ago

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• 16 years ago

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.

cubicle673• 16 years ago

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

hoprocker• 16 years ago

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.

alexbosworth• 16 years ago

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• 16 years ago

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• 16 years ago

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

The_Igor2• 16 years ago

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

mike-cardwell4• 16 years ago

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

The_Igor2• 16 years ago

"mike",

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

DougWebb• 16 years ago

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

moron4hire• 16 years ago

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.

anupj• 16 years ago

I agree. Technically speaking there is no native support for Webworkers in IE at the moment. That is about to change with IE9 though.

MarkPilgrim• 16 years ago

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• 16 years ago

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.

thenduks2• 16 years ago

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

mambodog• 16 years ago

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

mike-cardwell4• 16 years ago

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?

An implausibly illustrated introduction to HTML5 Web Workers

Related Stories