Arbeitstier Browser – Web Workers

Webanwendungen werden immer komplexer: Wenn man sich alleine Software wie Google Reader oder Google Docs anschaut, stellt man fest, dann man fast schon „vollkommene“ Desktop-ähnliche Anwendungen vor sich hat. Platformen wie Adobe AIR machen sich daraus einen Nutzen und bieten ein Framework an, mit dem es möglich ist, Desktopanwendungen mit Hilfe von Webtechnologien zu entwickeln.

Mit dieser Entwicklung einher geht auch die Tatsache, dass die Browser und ihre JavaScript Engines immer komplexere Aufgaben zu lösen haben und folglich auch immer aufwändiger werden. Dem gegenüber stehen aber auch einige Kritikpunkte: das Web kommt immer mehr auf „schwache“ Devices, wie Handy und Netbooks und von Anwendungen, die sich wie eine Desktopanwendung bedienen lassen, erwartet der User auch, dass sie sich anfühle, wie eine Desktopanwendung, also genauso schnell reagieren und Rückmeldung über eine Aktion liefern.

Um diese Entwicklung nicht zu beschränken, unterstützen Mozillas Firefox 3.5 und Safari 4 so genannte „Web Worker„. Der Artikel wird mit Absicht noch ohne Code-Beispiele auskommen, da die Worker-Implementierungen bisher noch sehr am Anfang stehen. Beispiele für die Implementierung in der Gecko-Engine finden sich aber hier und hier.

Was genau sind Web Worker?

Web Worker beschreiben kurz und knapp gesagt die Möglichkeit, seperate Prozesse zur Berechnung von JavaScript Code zu starten. Diese starten zudem auch einen eigenen nativen Thread im Browser, wodurch zusätzlich auch die Nutzung von mehreren Prozessoren im System unterstützt und ermöglicht wird.

Web Worker sind weitestgehend unabängig und losgelöst von der eigentlichen Anwendung. Der Standard-Workflow wäre die Initialisierung eines Workers mit speziellen Daten, die er für seine Berechnung benötigt. Ein Worker hat zudem die Möglichkeit, selber Code nachzuladen, natürlich nur im Kontext der eigenen Domäne. Somit ist des dem Worker auch problemlos möglich, andere Klassen zu laden und mit ihnen zu arbeiten.

Und wofür brauche ich Web Worker?

Wie eingangs schon erwähnt, sind Web Worker besonders hilfreich, um eine Anwendung „responsive“ zu halten, also dafür zu sorgen, dass für den User keine spürbaren Unterbrechungen oder Verzögerungen entstehen, besonders durch irgendwelche Berechnungen im Hintergrund. Worker machen mindestens an allen Stellen Sinn, an denen Berechnungen laufen, die die Chance haben, dass sie auch große Datenmengen verarbeiten müssen und sind vor allem dann auch brauchbar, wenn mir das Ergebnis einer Berechnung eher egal ist.

Ein Beispiel an dem wir das ganze nochmal verinnerlichen können, wäre der anfangs erwähnte Google Reader: wenn ich dort in meiner Liste aller Feed Einträge fleissig herunterscrolle, werden automatisch überflogene Einträge als gelesen markiert. Gerade durch das Scrollen merkt man hier oft ganz gut eine Verzögerung, während der Status gesetzt wird. Dieser Einfluss ist hier natürlich noch eher marginal, aber wir wollen das Beispiel einfach mal so übernehmen. Würde jetzt für die Aktion, einen Eintrag als gelesen zu markieren, ein eigener Worker gestartet, so würde das den Browser weniger beeinflussen, das Scrollen wäre flüssiger.

Ein anderes gutes Beispiel: nehmen wir z.B. einen Twitter Client, der eine lange Timeline mit deutlich mehr als 200 Elementen darstellt. Ich habe in jedem Tweet den Twitter-typischen „gesendet vor n Minuten“ Text stehen und möchte den über einen Interval auch regelmäßig aktualisieren. Selbst wenn ich den Code optimiere und alle Elemente in einem Array vorhalte, ist die gesamte Aktion inkl. ersetzen des bisherigen Textes relativ Rechenaufwändig, noch dazu ist das „merken“ aller Elemente in einem Array ein Speicherfresser. Statt dessen könnte ich diesen Aktualisierungsinterval in einem Worker laufen lassen, der alle Elemente dynamisch über den DOM Tree lädt (was den Speicherverbrauch verringert) und anschließend alle „gesendet vor n Minuten“ Strings mit dem aktuellen Wert ersetzt. Dadurch, dass die ganze Aktion in einem Worker läuft, wird der User hiervon nicht gestört und die Anwendung ist währenddessen in ihrer Leistung und Darstellung überhaupt nicht beeinflusst.

Natürlich ist es auch möglich, besonders lange Prozesse laufen zu lassen, bei denen man nicht in unmittelbarer Zeit mit einer Fertigstellung rechnet, da sich Worker suspenden lassen und bei späterer Rückkehr auf die Website wieder aufgenommen werden können. Zudem besteht auch die Möglichkeit, Shared-Workers zu verwenden. D.h. es wird nicht ein Worker-Prozess pro Fenster gespawnt, sondern es existiert ein gemeinsamer Worker-Prozess, für alle geöffneten Fenster, die die gleiche Seite anzeigen.

Fazit

Kurzum, Web Worker sind also eine tolle Sache, die gerade für immer komplexere Anwendungen im Browser besonders interessant wird. Dass sich dadurch auch noch auf Multi-Prozessor Fähigkeiten optimieren lässt, macht die Sache besonders interessant. Für die Zukunft kann man sich also sicher das ein oder andere davon versprechen. Das Konzept, immer mehr Code beim User auszuführen, also weg vom „web-typischen Thin-Client“ kann man sehen wie man will, aber ganz umher kommen wird man davon in Zukunft wohl nicht mehr, insofern sind die Web Workers nur eine logische Konsequenz dessen, was früher oder später benötigt wird. Ich werde das Thema sicherlich in ein paar Monaten nochmal aufgreifen und dann mal ein paar Beispielimplementierungen vorstellen.