This conversation reminds me Java and Swing (UI Components). Changes in Swing componentes should happen in Swing Thread (usually launched by a user interaction with a button, menu, ...) and when you are going to do a long-taking task and you need a new Thread, to change things on the UI you should put this changes in a "queue" and this will be done by the Swing Thread (somethink like 'do this when you can').
As it's said, we are used to the current model of how JS changes the DOM, and I think that several threads changing it at the same time and launching events, could be a hell for most inexperienced developers and moreover, most times this complexity is not necesary. - Albin, spain On Fri, Dec 17, 2010 at 11:09 AM, Christophe Porteneuve <[email protected]>wrote: > I think Web Workers is very much "threading for JS done right." > > In the sense that (a) actual multi-threading introduces a shitload of > complexity (I should know, I did a ton of multi-threaded code both server- > and desktop-side back in the days) and (b) most of the time all you want is > asynchronous, state-based computing. > > The good thing is, in JS we are already well acquainted with the core > mechanisms of asynchronous computing: message passing in the form of events > and (to a lesser degree) timeouts/intervals. > > I don't think DOM tweaking should occur outside the main JS execution > thread. It would open a Pandora's box of perf/sync issues, making DOM > tweaking even LESS efficient than it is today. So the decision to restrict > Web Workers to self-contained, message-based, non-DOM processing seems sound > to me. > > As for the execution model, I believe all browsers currently implementing > Web Workers use a different thread in the same process, but I may be wrong. > Still, context-switching or memory-mapping with another process would kill > most of the speed benefits of using workers in the first place. > > -- > Christophe Porteneuve > [email protected] > > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected]<jsmentors%[email protected]> > -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
