Wirklich keine Möglichkeit für separaten DOM thread?

[Rolf B]

Hallo Michael,

okay, wenn Du eine Libary mit im Vordergrund laufen lassen willst, dann sind meine Ideen komplett hinfällig. Das ist fertiger Code und der muss laufen, wie er ist.

Ich verstehe einfach nicht, warum es keinen "Dom Worker" gibt, der für so etwas genutzt werden könnte.

Tja, was soll ich dazu jetzt sagen?

Der UI-Thread ist für die Interaktion mit dem Benutzer da. PUNKT. Window-Systeme schicken an ihre Anwendungen Messages, teils mit hoher Frequenz, und sie erwarten, dass diese Messages kurzfristig verarbeitet werden. Die Anwendungen betreiben dafür eine Message Loop:

Ganz grob so:

while (true) {
   msg = getmessage();
   if (msg.abort) {
      break;
   }
   translateMessage(msg);
   dispatchMessage(msg);
}

Wenn zwischen zwei getMessage-Aufrufen zu viel Zeit vergeht (100ms), läuft die Nachrichtenwarteschlange über und es gehen Nachrichten verloren. JavaScript betreibt eine sogenannte Event Loop, die ähnlich abläuft. Während ein Event verarbeitet wird, ist garantiert, dass niemand anderes auf das DOM zugreift. Deshalb und nur deshalb ist es problemlös möglich, in einer Schleife über das Ergebnis von querySelectorAll() oder ähnlichem zu iterieren. Würde ein Hintergrundthread am DOM Änderungen vornehmen, während man eine NodeList oder HTMLCollection durchläuft, würde sie ungültig werden oder sogar zerstört.

Ein Workerthread, der parallel zum Benutzer und den von ihm getriggerten Events auf dem UI herumturnt, ist ein Unfall, der darauf wartet, zu passieren. Einen solchen Thread zu betreiben würde verlangen, dass sowohl UI wie auch Worker jeden DOM Zugriff durch Zugriffsperren serialisieren. Kann man machen, ist aber (a) fehlerträchtig und (b) langsam, wenn man es für jeden einzelnen Zugriff macht. Insbesondere könnte dadurch die Layoutphase des Browsers gruselig blockiert werden.

Ein iframe könnte einen eigenen Thread und eine eigene Message Loop bekommen, um sich vom UI-Thread des einbettenden DOM zu entkoppeln. Aber das ist auch nicht so einfach, weil das DOM eines iframe, der vom gleichen Origin kommt, vom Host-DOM aus erreichbar ist.

Rolf