Man muss die Hartnäckigkeit von Surma loben. Er setzt sich seit vielen Jahren für Web Workers als Weg zu besser funktionierenden Websites ein. Er ist wieder dabei, um sicherzustellen, dass wir alle die Landschaft verstehen.
[…] unabhängig davon, wo man hinschaut, wird Multithreading überall eingesetzt. iOS ermöglicht Entwicklern, Code einfach durch Grand Central Dispatch zu parallelisieren, Android tut dies über seinen neuen, einheitlichen Task-Scheduler WorkManager, und Spiele-Engines wie Unity verfügen über Job-Systeme. Der Grund, warum eine dieser Plattformen nicht nur Multithreading unterstützt, sondern es so einfach wie möglich macht, ist immer derselbe: Sicherstellen, dass sich Ihre App großartig anfühlt.
Surma, „The State Of Web Workers In 2021“
Im Grunde hat also jede Plattform ihre eigene Version von Multithreading, einschließlich des Webs. Es ist nur so, dass wir im Web quasi gegen die Single-Threaded-Natur von JavaScript „kämpfen“ müssen, indem wir Web Worker verwenden (die, falls Sie sich das fragen, „universell unterstützt“ sind). Die Frage ist: Wie und wofür? Für Letzteres zeigt Surma ein Beispiel eines Spiels, bei dem „der gesamte App-Zustand und die Spiellogik in einem Worker laufen.“ Für ersteres scheint die Hilfsbibliothek comlink eine große Arbeitserleichterung zu sein.
Persönlich wünsche ich mir, dass beliebte Tools das einfach irgendwie… machen. Ich weiß nicht, wie das genau aussehen würde, aber es fühlt sich irgendwie so an, als ob die Entwicklerkommunikation hier nicht wirklich etwas bewirkt. Was wäre, wenn beliebte Tools wie Apollo – das für viel „App-Zustand“ verantwortlich ist – das alles magisch vom Hauptthread auslagern würden. Macht das Sinn? Ist das möglich?
Um Ihre letzte Frage, „Ist das möglich?“, zu beantworten, würde ich sagen ja, absolut. Letztendlich ist die Verwendung eines Workers wie jeder andere asynchrone Prozess; man startet ihn und wartet auf eine Antwort. Vorausgesetzt, Sie haben eine Möglichkeit, den asynchronen Zustand von z. B.
fetchoderlocalStoragezu handhaben, sollten Sie auch hier nur minimale Probleme bei der Integration von Workern haben.Ich habe sie erfolgreich zur Verarbeitung relativ großer Datensätze verwendet und werde mich in Zukunft bei ähnlichen Projekten wahrscheinlich noch stärker darauf verlassen. Die Verbesserung gegenüber meinem alten Ansatz, „das Datenarray aufzubrechen und es in kleinen Batches zu verarbeiten, wobei dazwischen mit
setTimeoutan den Browser übergeben wird“, ist kaum zu unterschätzen!Wer Multithreading in Web-Frontends ausprobieren möchte, es gibt bereits ein Framework, das das tut. Die Performance ist absolut verrückt.
Bitte probieren Sie es aus und schauen Sie es sich an.
https://github.com/neomjs/neo
Danke, Sebastian!
Zum neo.mjs-Projekt
Das Schlüsselkonzept ist „ein Anwendungs-Worker als Hauptakteur“, was gut zu Surmas Idee eines Actor-Modells passt.
Kurz gesagt: Ihre Apps (einschließlich Komponenten) leben innerhalb eines Anwendungs-Workers, wodurch die Hauptthreads so leer wie möglich bleiben. Sie erstellen die Worker-Struktur, leiten UI-bezogene DOM-Events an den Anwendungs-Worker weiter und wenden Delta-Updates vom Virtual-DOM-Worker an.
Sie können entweder dedizierte Worker für SPAs oder Shared Worker für Multi-Window-Apps verwenden.
Die neueste Ergänzung ist ein Offscreen-Canvas-Worker
https://tobiasuhlig.medium.com/rendering-3d-offscreen-getting-max-performance-using-canvas-workers-88c207cbcdc2?source=friends_link&sk=7ee0851ff6043c4a79248ff5a20a23fc
Mit freundlichen Grüßen,
Tobias