An implausibly illustrated introduction to HTML5 Web Workers | Hacker News Reader

An implausibly illustrated introduction to HTML5 Web Workers

wearehugh.com

108 pointstswicegood33 comments

Open articleView on HN

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!

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

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

Made me smile.

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.

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

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.

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

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

I'm not sure I'm with you here. A lot of offices have really old computers purchased around the time of Windows XP SP1 and the version of flash shipped on those will leave quite a lot to be desired.

So maybe I should have said it's like saying IE (in those types of settings, anyway) doesn't support new flash games because they don't have the right version of the plugin :)

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

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

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?

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

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.

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

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

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

This should be trivial to test...?

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

"Sanity of threads + robustness of web development.

What could possibly go wrong?"

Genius!

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.

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

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

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

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?

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.

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

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.

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.

Nope. There's still only a single thread executing all of the javascript on the DOM at any one time.

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

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

"mike",

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

Reply on news.ycombinator.com