HTML5 Web Workers need access to the DOM. And IE9 support

The reason Web Workers do not have access to the DOM is because that would create a pandoras box of problems to solve, mostly revolving around concurrency and efficiency.

If you have a loop where you are setting and reading dom values, then that loop should be protected from other scripts modifying the dom, and hence there's a good chance one thread will have to halt making the web-workers pointless.

What happens if a DOM object has JavaScript values attached to it (bad practice but can happen), does the web-worker have access to these? If not then each web-worker will need a separate dom representation possibly creating a huge overhead.

The best way to take advantage of multi core processors is to allow each thread to have largely their own local memory and pass messages asynchronously between them, most architectures short of this will suffer greatly.

If this thread was posted to ridicule the OP then I really hope that it doesnt get any more upvotes, thats pretty certainly "unhackernewslike"

If not, having concurrent access to the dom is an extremely hard problem and would mostly likely have developers writing extremely inefficient code as the dom api would then need to manage transactions, whereas its usually best to figure out how to collect you changes into a large single edit.

It could be useful to have exclusive access to portions of the DOM, which would also allow most of the performance boosts which come from having them segmented. That way, a worker could render to a <canvas>, another could render to <audio>, and not have any concurrency issues involving the DOM.

In this setup, the current implementation of workers would simply be that the "main" thread has exclusive access to the entire DOM tree. It could be implemented and dropped in, and existing code would continue to work identically and uninterrupted.

But yes. Access to all DOM? PITA.

I'd disagree with web workers needing to access the DOM. If you're storing application state in the DOM, you should reconsider the design (or lack thereof) of your application.

And sure, I'd like IE9 support too. And a pony.

I also think full concurrency/access from all Workers is the improper implementation.

The most important focus when writing commonly-labeled "HTML5" apps should be performance, for now at least. We are, at long last, overcoming the click-fetch-wait style of interaction with Web data; the dynamic nature of its replacement is a key feature, and the influx of performance-constrained rich-web devices need to support complex dynamic apps too.

So, I think we need to rethink the roles of common Web technologies. The DOM is no place for state; it should be treated more as an interface layer than a representation of data. JavaScript engines are tuned enough, and the basic architecture for extremely rich apps is in place, we just need to use our tools intelligently as implementors.

Having access to the DOM from all your Web Workers would require much more overhead with synchronization on access, which I think might be an undesirable overhead. Threading is hard, and I think this programmer doesn't seem to understand that.

Web Workers are great because they let us break our computation out to something separate from the front end, without incurring the performance penalty of always having the DOM around.

Message passing to a front end that does the drawing is a reasonable design, and I think that this is a correct choice. Of course, if somebody could propose a design where multiple threads have access to the DOM without overhead, then I'd like that along with my unicorn too.

Not going to happen.

Web Workers intentionally can't share state and can only communicate via messages. AFAIK the only JavaScript engine that offers threadsafe access to objects is Rhino.

Insane proposal. Please don't let game developers turn web development into a living hell.