© Shutterstock / Oceloti
Kolumne: Per Anhalter durch den JavaScript-Dschungel

Asynchronität in JavaScript – ein Werkzeug für jedes Problem


Der Fall bei Asynchronität in JavaScript ist eigentlich klar: Callbacks sind böse und Promises die einzig richtige Lösung. Nein, eigentlich ist ja async/await die Lösung, was aber wiederum auf Promises aufbaut, bei denen wiederum einige Callbacks im Spiel sind. Also ist doch nicht alles so klar, wie es scheint. Warum diese ganze Asynchronität notwendig ist, werden wir im Folgenden klären.

Warum Asynchronität? Egal, ob wir uns im Browser- oder Serverkontext bewegen, der Begriff ist allgegenwärtig. Das hat vor allem mit der grundlegenden Architektur von JavaScript Engines zu tun. Nahezu alle Implementierungen bestehen im Kern aus einem Prozess, der die gesamte Arbeit verrichtet. Natürlich gibt es Worker-Prozesse, sowohl im Browser als auch in Node.js. Dennoch werden die meisten Applikationen in nur einem Prozess ausgeführt und das ist auch gut so, denn dieser langweilt sich die meiste Zeit und wartet, dass er etwas zu tun bekommt. Und genau dieses Warten beziehungsweise die Reaktion auf ein bestimmtes Ereignis wird über die verschiedenen Sprachmittel von JavaScript gelöst.

Da das im ersten Moment zugegebenermaßen etwas abstrakt klingt, sehen wir uns dazu besser ein Beispiel an. Im Frontend unserer Applikation sollen Daten vom Server geladen werden. Wir nutzen das Fetch API des Browsers und formulieren die Anfrage. Der Aufruf des Fetch API führt dazu, dass die Anfrage gesendet wird. Würde der Browser an dieser Stelle synchron arbeiten, wäre es das jetzt, zumindest für kurze Zeit, mit jeglicher Interaktion zwischen dem Benutzer und unserer Applikation gewesen. Kein Button könnte geklickt und keine Eingabe getätigt werden – der Browser wäre eingefroren. Keine sehr schöne Vorstellung. Also doch lieber mit dem asynchronen Ansatz: Wir setzen die Anfrage an den Server ab, aber statt auf die Antwort zu warten, registrieren wir eine Funktion, die aufgerufen werden soll, sobald das Ergebnis vorliegt. In der Zwischenzeit kann der Browser wieder auf die Interaktion des Benutzers reagieren oder beliebige andere Aufgaben erledigen. Sobald die Antwort des Servers vorliegt, was im besten Fall nur Bruchteile einer Sekunde dauert, wird unsere registrierte Funktion ausgeführt und die Behandlung der Antwort läuft ab. Wir haben mit dieser Lösung also eine bessere Responsivität unserer Applikation gewonnen. Für den Benutzer fühlen sich viele Operationen viel flüssiger an, als sie tatsächlich sind. Der Browser verschiebt in diesem Fall nur einen Teil der Arbeit an eine andere Stelle und schafft sich Reaktionsmöglichkeiten.

Wie die Asynchronität jetzt genau umgesetzt ist, ob wie gerade skizziert mit Funktionen, über async/await oder ein Stream API, spielt an dieser Stelle keine Rolle. Für die Beantwortung der nächsten Frage, „Wann nutze ich welche Lösung und wo sind ihre jeweiligen Grenzen?“, müssen wir jedoch einen genaueren Blick auf die ganze Sache werfen.

Callbacks – die Geißel von JavaScript oder doch nicht?

Fangen wir doch mit der unbeliebtesten Variante an: den Callbacks. Wer asynchrone Aufgaben mit Callbacks löst, der isst auch kleine Kinder zum Frühstück. So oder so ähnlich hat es lange Zeit geheißen, wenn es um die Implementierung von asynchronen Lösungen ging. Werfen wir jedoch einen genaueren Blick auf eine beliebige JavaScript-Applikation, finden sich dort zuhauf Callback-Funktionen. Un...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang