有没有办法在Web Worker中创建DOM元素？

假设没有任何DOM实现代码使用任何非$ DOM $ b的非DOM对象，或者如果它那些对象是完全线程安全吗？情况并非如此，至少在Gecko。

在这种情况下，问题与在多个线程中触及的DOM对象不同。问题是不同线程上的两个DOM对象都触及了一些全局第三个对象。例如，XML解析器必须做一些事情，在Gecko中只能在主线程上完成（DTD加载，非正式的;有一个以前见过的其他人，但不记得以前）。

然而，还有一个解决方法提到，它使用解析器的第三方实现，其中 jsdom 就是一个例子。有了这个，您甚至可以访问自己的单独文档。

Context: I have a web application that processes and shows huge log files. They're usually only about 100k lines long, but it can be up to 4 million lines or more. To be able to scroll through that log file (both user initiated and via JavaScript) and filter the lines with decent performance I create a DOM element for each line as soon as the data arrives (in JSON via ajax). I found this better for performance then constructing the HTML at the back-end. Afterwards I save the elements in an array and I only show the lines that are visible.

For max 100k lines this takes only about a few seconds, but anything more takes up to one minute for 500k lines (not including the download). I wanted to improve the performance even more, so I tried using HTML5 Web Workers. The problem now is that I can't create elements in a Web Worker, not even outside the DOM. So I ended up doing only the json to HTML conversion in the Web Workers and send the result to the main thread. There it is created and stored in an array. Unfortunately this worsened the performance and now it takes at least 30 seconds more.

Question: So is there any way, that I'm not aware of, to create DOM elements, outside the DOM tree, in a Web Worker? If not, why not? It seems to me that this can't create concurrency problems, as creating the elements could happen in parallel without problems.

Alright, I did some more research with the information @Bergi provided and found the following discussion on W3C mailing list:

w3-org.9356.n7.nabble/Limited-DOM-in-Web-Workers-td44284.html

And the excerpt that answers why there is no access to the XML parser or DOM parser in the Web Worker:

You're assuming that none of the DOM implementation code uses any sort of non-DOM objects, ever, or that if it does those objects are fully threadsafe. That's just not not the case, at least in Gecko.

The issue in this case is not the same DOM object being touched on multiple threads. The issue is two DOM objects on different threads both touching some global third object.

For example, the XML parser has to do some things that in Gecko can only be done on the main thread (DTD loading, offhand; there are a few others that I've seen before but don't recall offhand).

There is however also a workaround mentioned, which is using a third-party implementation of the parsers, of which jsdom is an example. With this you even have access to your own separate Document.