5 ms·
An implausibly illustrated introduction to HTML5 Web Workers
- madair 16y agoI 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!
- gcb 16y ago"Sanity of threads + robustness of web development. What could possibly go wrong?" Genius!
- samratjp 16y agoYes, it's all fun and games until someone pokes an async's eye.
- bruceboughton 16y agoThis 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 16y agoImho 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 16y agoJavaScript in general is very dangerous for programmers who are clueless...
- Groxx 16y agoSuddenly, the Safari Extension model makes a lot more sense.
- cubicle67 16y agowhat's not clear from this is scope. Does each worker have its own namespace?
- mike-cardwell 16y agoThis should be trivial to test...?
- cubicle67 16y agotrue, but I was at work when I wrote that and was wondering if anyone else out there had a quick answer for me.
- hasenj 16y agoI 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 16y agoIn 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 16y agoI'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 16y agoThis 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.
- hoprocker 16y agoAFAIK, 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.
- mike-cardwell 16y agoNope. There's still only a single thread executing all of the javascript on the DOM at any one time.
- alexbosworth 16y agoWeb 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 16y agoGod 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 16y agoWhich 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_Igor 16y agoHere 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%A0care/ http://blog.mediaplex.com/2010/06/02/html5-why-you-should%C2...
- mike-cardwell 16y agoContent-less article, irrelevant to the discussion. Pure spam.
- The_Igor 16y ago"mike", There is no need to insult my writing. The original post was about HTML 5 and so was my write up.
- moron4hire 16y agoI 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 16y agoI (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 16y agoStrangely 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.
- anupj 16y agoI agree. Technically speaking there is no native support for Webworkers in IE at the moment. That is about to change with IE9 though.
- thenduks 16y agoWell 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 16y agoFlash 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).
- DougWebb 16y agoThis 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 16y agoWhat 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?