 Moin, moin und herzlich willkommen zu einer Sonderausgabe von Aufgeladene Mikrospitze. Aufgeladene Mikrospitze. Bereitet euch offenhaufen Denglish vor. Intro! Worker. Ich rede seit ungefähr drei Jahren von denen und werde auch in Zukunft vermutlich nicht aufhören. Um es gleich vorweg zu nehmen, Webworker, Serviceworker und Worklitz sind unterschiedliche Dinge. Ich rede über Webworker. Die anderen Sachen sind ähnlich, aber nicht dasselbe. Also, was ist ein Worker? Ein Worker ist ein zweiter JavaScript-Kontext, der unabhängig von deinem üblichen Code läuft. Du kannst dir das wie ein Thread vorstellen, wie du ihn vielleicht von Java oder C++ kennst. Der Thread, den du normalerweise benutzt, heißt MainThread und der Worker läuft parallel dazu. Aber weil die Sprache JavaScript single-threaded ist, kann der Worker nicht auf die Variablen des MainThreads zugreifen und auch nicht anders herum. Du kannst nur Nachrichten hin und her schicken und diese Nachrichten können simple JavaScript-Objekte sein. Worker gibt es schon ziemlich lange, dass sogar Internet Explorer 10 sie unterstützt, also kannst du tatsächlich heutzutage sorgenfrei benutzen. Aber wofür? Tja, wir wollen im Allgemeinen, dass der Browser auf UserInput wie scrollen oder tappen schnell reagiert. Damit sich deine App für den Nutzer flüssig und responsiv anfühlt, ist es wichtig, eine konstante Framerate zu halten. Auf vielen Geräten sind es 60 Updates pro Sekunde üblich, aber manche sind schneller. Zum Beispiel das Pixel 5 hat 90 Updates pro Sekunde und das iPad Pro hat 120 Updates pro Sekunde. Desktop-Monitore haben manchmal sogar 144 oder mehr Updates pro Sekunde. Der Browser kann nicht den nächsten Frame auf den Bildschirm bringen, wenn dein JavaScript noch am Laufen ist. Um also die Framerate stabil zu halten, musst du sicherstellen, dass dein JavaScript fertig ist, wenn der nächste Frame auf dem Bildschirm erscheinen soll. Und hier liegt das Problem. Auf Geräten mit 60 Hertz hast du 16 Millisekunden zwischen den einzelnen Frames. Aber auf dem iPad Pro zum Beispiel hast du nur 8 Millisekunden zwischen den Frames. In dieser Zeitspanne muss der Browser nicht nur dein JavaScript ausführen, sondern auch die Aufgaben, die durch das Ausführen von deinem JavaScript überhaupt erst angefallen sind. Layout, Paint, Scrolling und so weiter und so Dazu kommt natürlich, dass es stark vom Prozessor, Arbeitsspeicher und anderen Faktoren abhängt, wie lange ein Stück JavaScript braucht. Und im Web kann auf verschiedensten Geräten gesurft werden. Und das heißt, was sich auf einem Gerät flüssig anfühlt, kann sich extrem stockend auf einem anderen Gerät anfühlen. Und hier kommt der Worker ins Spiel. Jegliche Logik, die nichts mit deinem User-Interface zu tun hat, könntest du in ein Worker packen. Auf diese Weise kann der Browser den nächsten Frame vorbereiten, selbst wenn dein Worker noch JavaScript am Laufen hat. Natürlich haben Worker auch ihre Nachteile. Zum Beispiel haben Worker kein Zugriff auf den DOM. Du kannst also dein Interface nicht von einem Worker aus ändern. Einige an die APIs sind ebenfalls nicht im Worker zu finden. Und was auch immer du im Worker machst, wenn du das Resultat auf dem Mainframe brauchst, musst du es als Nachricht schicken. Und das kann ziemlich schnell eine haarige Angelegenheit werden. Aus diesem Grund habe ich eine Bibliothek namens Comlink geschrieben. Comlink tut so, als ob sowohl Mainframe als auch Worker auf dieselben Objekte zu greifen können. Du kannst eine Funktion im Mainframe aufrufen, aber sie läuft eigentlich tatsächlich im Worker. Der einzige Unterschied ist, dass der Rückgabewertefunktion immer ein Promise sein wird, dass du warten musst. Der Mainframe muss buchstäblich warten, bis der Worker seine Arbeit verrichtet hat. Hier sind zwei echte Beispiele, die Worker benutzen. Squoosh komprimiert Bilder in Workern. Bildkomprimierung kann Sekunden oder sogar Minuten brauchen. Und es wäre absolut nicht akzeptabel, die App so lange eingefroren zu lassen. Ein anderes Beispiel ist Prox. Wir wollten nicht nur, dass das Spiel gut aussieht, sondern dass es das auch auf Low-End-Geräten tut. Und das zwangst den Mainframe so wenig wie möglich zu benutzen, damit der Browser visuelle Updates abarbeiten kann. Die gesamte Spiellogik ist in einem Worker untergebracht. So, ich hoffe, ihr habt dieses Video nützlich gefunden. Es gibt noch viel zu tun auf der Web-Plattform, um Worker und zwei Dinge einfacher zu machen. Und zu dem Thema habe ich ein paar Links in die Videobeschreibung getan, wenn ihr etwas mehr darüber wissen wollt. Danke fürs Zuschauen.