JavaScript wird als „Single-Threaded“ bezeichnet. Wie Brian Barbour es ausdrückt
Das bedeutet, es gibt einen Call Stack und einen Memory Heap.
Wir alle spüren regelmäßig die Symptome davon in Form von Performance-Rucklern und mangelnder Interaktivität bei Elementen oder ganzen Websites. Wenn wir JavaScript viele Aufgaben geben und es sehr beschäftigt damit ist, dann tut es *nicht* andere Dinge, wie zum Beispiel schnell unsere Event-Handler zu bearbeiten.
In dieser Hinsicht gab es kürzlich eine interessante Punkt-Gegenpunkt-Kombination.
Das Surma setzt sich dafür ein, so viel JavaScript wie möglich vom Haupt-Thread wegzubewegen. Tatsächlich schlägt er beim Thema Web Workers vor
Du solltest immer Web Worker verwenden.
Web Worker sind der primäre Weg, JavaScript außerhalb des Haupt-Threads auszuführen. Paul Lewis vergleicht das Problem mit Dem 9-Uhr-Berufsverkehr
Die schlimmste Tageszeit zum Reisen. Für viele ist es zu keiner anderen Tageszeit möglich zu reisen, da sie um 9 Uhr morgens zur Arbeit müssen.
Das ist genau das, wie heute viel Web-Code aussieht: Alles läuft auf einem einzigen Thread, dem Haupt-Thread, und der Verkehr ist schlecht. Tatsächlich ist es sogar noch extremer: Es gibt nur eine Spur vom Stadtzentrum zu den Außenbezirken, und buchstäblich jeder ist auf der Straße, auch wenn er nicht um 9 Uhr morgens im Büro sein muss.
Mir gefällt auch, wie Surma andere Sprachen vergleicht, in denen der "Haupt-Thread" oft als "UI-Thread" bezeichnet wird. Wenn das, was du tust, UI-bezogen ist, mache es auf dem Haupt-Thread; wenn nicht, mache es außerhalb des Haupt-Threads. Er geht darauf in einer guten Episode von The Web Platform Podcast ein – 194: Off the Main Thread. Ich könnte mir vorstellen, dass dies eine positive Veränderung in der Einstellung und Denkweise von JavaScript-Entwicklern wäre.
Ein Beispiel dafür, etwas vom UI-Thread wegzubewegen: Zustandsverwaltung.
David Gilbertson muss das gelesen haben und schrieb
Ich habe kürzlich einen Artikel gesehen, der argumentierte, dass die Aktualisierung eines Redux-Stores ein guter Kandidat für Web Worker sei, da es sich nicht um UI-Arbeit handelt (und Nicht-UI-Arbeit nicht auf dem Haupt-Thread stattfinden sollte). Das Wegschleudern der Datenverarbeitung an einen Worker-Thread klingt vernünftig, aber die Idee kam mir ein wenig, ähm, akademisch vor.
Davids Hauptargument ist meiner Meinung nach, dass einige der gewichtigen JavaScript-Aufgaben, die wir erledigen müssen, als Reaktion auf benutzerinitiierte Aktionen stattfinden, bei denen der Benutzer sowieso auf das Ende der Dinge warten muss, sodass eine nicht reagierende Benutzeroberfläche während dieser Zeit in Ordnung ist. Aber für alles, was nicht benutzerinitiiert ist – und länger als sagen wir 100 ms dauert – stimmt er zu, dass ein Web Worker hilfreich ist.
(Wenn man sich diese 100 ms ansieht, ist es erwähnenswert, dass ein wichtiger Punkt, den Surma macht, ist, dass die Welt voller Low-End-Handys ist – und wer weiß, was 100 ms auf einem High-End-Handy bedeuten, wenn sie auf einem Low-End-Handy ankommen.)
Der große Trick, um Dinge in JavaScript vom Haupt-Thread wegzubewegen, ist die Verwendung von Web Workern. Es ist kein Hack oder so etwas, Web Worker sind buchstäblich die native API, um mehrere Hintergrund-Threads zu JavaScript zu bringen. Ähnlich wie bei Service Workern befinden sie sich normalerweise in einer anderen Datei
var myWorker = new Worker('worker.js');Aber das muss nicht sein – du kannst sie inline machen oder eine Bibliothek verwenden. Die API ist nicht schlecht, aber auch nicht großartig. Surma hat eine Bibliothek dafür: Comlink.
Surmas Kreuzzug dafür ist eine ziemlich langfristige Anstrengung. Es war ein Feature beim Chrome Summit 2018 mit A Quest to Guarantee Responsiveness: Scheduling On and Off the Main Thread und wieder 2019 mit The main thread is overworked & underpaid, aber dieses Mal mit fast sechsmal so vielen Aufrufen zum Zeitpunkt dieses Updates
Und er ist nicht allein. Hier ist Alex MacArthur, wie er seine Denkweise über Event-Handler anpasst, um Dinge außerhalb des Threads zu erledigen.