© hxdbzxy, 123RF

Fast jeder Webentwickler kennt die Javascript-Bibliothek Jquery, weil deren Funktionen und Objekte seine Arbeit sehr erleichtern. Zwar bleibt die nun angebotene Jquery 3 weitgehend kompatibel zur Version 2, dennoch könnten einige der implementierten Änderungen den Einsatz sogar verhindern.

Mit der Javascript-Bibliothek Jquery [1] greifen Entwickler besonders einfach auf die Elemente einer Webseite zu, manipulieren diese im Nachhinein, verarbeiten Ereignisse komfortabel und kommunizieren mit wenigen Handgriffen per Ajax mit dem Server. Auf diese Weise hilft Jquery dabei, komplexe dynamische Webanwendungen zu bauen. Seine Verbreitung fördern zudem große CMS wie Joomla oder WordPress, die Jquery mitliefern oder selbst einsetzen. Eine Statistik von W3techs [2] legt gar nahe, dass Jquery heute auf zwei Dritteln aller Websites zum Einsatz kommt.

Rückbau

Am 9. Juni 2016 gaben die Entwickler Version 3.0 von Jquery frei [3], Anfang Juli folgte bereits ein Update auf Version 3.1 [4]. Anders als einst bei Jquery 2 verzichten sie diesmal auf grundlegende Umbauten an der Bibliothek. Vielmehr schneidet die neue Version ein paar alte Zöpfe ab und ändert das Verhalten einiger Schnittstellen. Die Entwickler wollten Jquery 3 vor allem schlanker und schneller machen – als Reaktion auf zwei häufig genannte Kritikpunkte.

Zunächst haben sie einige Workarounds für den Internet Explorer entfernt. Anders als viele Internetseiten und Meldungen suggerieren, unterstützt Jquery 3 weiterhin offiziell den Internet Explorer ab Version 9. Wer seine Webseiten auf ältere Microsoft-Browser zuschneiden möchte, sollte bei Jquery 2 beziehungsweise Jquery 1.12 bleiben – beide Versionszweige erhalten auch weiterhin Fehlerkorrekturen.

Über die Methoden ».load()« , ».unload()« und ».error()« ließen sich bislang Eventhandler registrieren. Die Methoden galten allerdings bereits in Jquery 1.8 als veraltet und fallen mit Jquery 3 endgültig weg. Wer Eventhandler registrieren möchte, sollte nun zu ».on()« greifen.

Die Position eines Elements auf der Webseite ermittelt die Funktion »offset()« . Das klappt jedoch recht sinnfrei auch für den Offset eines Fensters, die Antwort lautet dann etwa »{ top: 0, left: 0 }« . Es gibt weitere Situationen, in denen Jquery keinen sinnvollen Wert zurückliefert. Jquery 3 wirft in solchen Fällen eine Ausnahme und ignoriert damit nicht mehr stillschweigend derartige “verrückte Anfragen” der Programmierer.

Gaspedal

Animationen nutzen jetzt die vom Browser bereitgestellte »requestAnimationFrame« -Schnittstelle. Sie laufen damit künftig nicht nur weicher ab, sondern belasten auch den Prozessor weniger. Das »requestAnimationFrame« -API enthalten alle aktuellen Browser mit Ausnahme des Internet Explorer bis einschließlich Version 9 sowie Android vor Version 4.4. Die Jquery-Entwickler experimentieren bereits seit einigen Jahren mit der Schnittstelle, stießen dabei aber immer wieder auf zahlreiche Kompatibilitätsprobleme. Die sehen sie jetzt zwar als weitgehend behoben, aus dem Tritt kommt Programmcode womöglich dennoch, wenn er von in nahezu Echtzeit ablaufenden Animationen abhängt.

Jquery erleichtert mit ein paar eigenen (CSS-)Selektoren die Arbeit. Beispielsweise liefert »$(“:visible”)« alle Elemente, die derzeit auf einer Seite sichtbar sind. Diese speziellen Selektoren auswerten dauert allerdings länger als bei nativen CSS-Selektoren. Um etwa alle sichtbaren Elemente zu bestimmen, muss der Browser im schlimmsten Fall die Seite komplett neu rendern. Dank Google-Entwickler Paul Irish arbeitet Jquery jetzt zumindest dann deutlich flotter, wenn solche Selektoren häufig in einem Dokument vorkommen.

Im Fall von »:visible« bietet Jquery 3 laut Angaben der Entwickler eine Beschleunigung um den Faktor 17. Zugleich warnen sie, dass der Einsatz der speziellen Selektoren nach wie vor relativ viel Zeit schluckt. Programmierer sollten besser mit normalen CSS-Selektoren einige Elemente auswählen und dann nur auf diese »:visible« , »:hidden« & Co. anwenden.

Neue Verzögerungen

Die größten Umbauten stecken in den Deferred-Objekten. Sie helfen dabei, mehrere asynchrone Aufgaben zu verwalten, zu überwachen und abzuarbeiten, und erleichtern vor allem die Kommunikation mit Servern via Ajax. In Jquery 3 sind die »Jquery.Deferred« -Objekte kompatibel zur Promises/A+-Spezifikation beziehungsweise den Promises aus Ecmascript 2015. Die Deferred-Schnittstelle besteht zudem die Tests der Promises/A+ Compliance Test Suite [5].

Unter der Haube verhalten sich die Deferred-Objekte in gleich mehreren Situationen anders: Trat in Jquery 2 eine Exception auf, wanderte diese immer weiter nach oben, bis sie irgendwann »window.onerror« erreichte und somit meist das komplette Programm anhielt. Jquery 3 wandelt die Exception in eine Rejection um und ruft dann eine für solche Fälle hinterlegte Callback-Funktion auf.

Listing 1 veranschaulicht dies an einem simplen Beispiel: Es erstellt ein »Deferred« -Objekt und registriert dann per ».then()« ein paar Callback-Funktionen. Die im ersten Parameter von ».then()« übergebene Funktion führt der Code später aus, falls ein Deferred-Objekt den Zustand Resolved annimmt und somit alles glattgelaufen ist. Die im zweiten Parameter von ».then()« übergebene Funktion greift indes immer dann, wenn das Deferred-Objekt in den Zustand Rejected gelangt.

01 var deferred = $.Deferred();
02
03 deferred.then(function() {
04         console.log("Erste Callback-Funktion");
05         throw new Error("Fehler aufgetreten");
06 })
07 .then(
08         function() {console.log("Zweite Callback-Funktion"); },
09         function(e) {console.log(e.message);}
10 );
11
12 deferred.resolve();

Hat Listing 1 die Callback-Funktionen registriert, versetzt es das Objekt »deferred« sofort in den Zustand Resolved. Damit nimmt die Callback-Funktion im ersten ».then()« die Arbeit auf und wirft umgehend einen Fehler. In Jquery 2 wäre hier bereits Schluss, in der Konsole erschiene nur die Ausgabe »Erste Callback-Funktion« . Jquery 3 wandelt hingegen die Exception in eine Rejection um, das Programm läuft somit erst einmal weiter. Da eine Rejection vorliegt, ruft Jquery beim zweiten ».then()« die als zweiten Parameter hinterlegte Callback-Funktion auf und schanzt ihr den zuvor geworfenen Fehler zu. Unter Jquery 3 erscheinen folglich auf der Konsole die Meldungen aus Abbildung 1.

Abbildung 1: In Jquery 3 führen Ausnahmen beim Einsatz von Deferred-Objekten nicht mehr zum Programmabbruch.

Eine weitere Neuerung demonstriert Listing 2: Die Callback-Funktionen bestimmen ab sofort selbst den Zustand des Deferred-Objekts. Dabei führt ein Rückgabewert, der keine ».then()« -Funktion besitzt, zum Vollzug. Unter Jquery 2 liefert Listing 2 die Ausgabe »Nicht erfolgreich ausgeführt« , unter Jquery 3 hingegen »Erfolgreich ausgeführt« .

01 var deferred = $.Deferred();
02
03 deferred.then(
04         null,
05         function() { return "ausgeführt"; }
06 )
07 .then(
08         function(wert) { console.log("Erfolgreich", wert); },
09         function(wert) { console.log("Nicht erfolgreich", wert); }
10 );
11
12 deferred.reject();

Callbacks laufen jetzt zudem stets asynchron ab, auch wenn sich ein Deferred-Objekt im Zustand Resolved befindet. Abbildung 2 verdeutlicht dies: Unter Jquery 2 hätte es erst »Hallo Welt!« und dann »Programmende« ausgegeben, da die Callbacks dort abhängig von ihrer Bindung synchron ablaufen. Bei Jquery 3 dreht sich die Ausgabe um, es führt die Callback-Funktion asynchron aus.

Abbildung 2: Der Javascript-Beispielcode im Atom-Editor mit hellem Theme.

Die Funktion ».then()« verhält sich also in Jquery 3 in gleich mehreren Situationen anders als früher. Wer das alte Verhalten braucht, muss ».then()« in seinem Code gegen die ».pipe()« -Methode tauschen. Die stellt das alte Verhalten bereit und weist die gleiche Signatur wie die ».then()« -Methode auf. Ergänzend bieten Promise-Objekte die neue Methode ».catch()« an, die lediglich als Alias für ».then(null, Funktion)« fungiert.

Ein neues Plugin hilft beim Debuggen der Deferred-Objekte: Jquery Deferred Reporter [6] liefert auf der Konsole Informationen, mit denen Entwickler ihre Fehler zur Quelle verfolgen.

Punkt eins

Nicht einmal einen Monat nach Veröffentlichung der 3.0 folgte am 7. Juli 2016 bereits die Version 3.1. Die arbeitet nur in einer Sache anders: Für die Version 3.0 hatten die Jquery-Entwickler »jQuery.ready()« und »jQuery.fn.ready()« intern auf die neuen Deferred-Objekte umgestellt. Auch sie reichen folglich Fehler intern an die Rejection-Handler weiter.

Das führte zu einem Problem: Ergänzte ein Programmierer auf dem herkömmlichen Weg einen »ready« -Handler (etwa via »jQuery(function() { … })« oder »jQuery(document).ready(function() { … })« ), konnte er keinen Deferred-Handler anmelden. Folglich erfuhr er nichts von einem Fehler (Silent Errors). Erschwerend kam hinzu, dass Programmierer vor Version 3.1 nicht eindeutig erkennen konnten, wenn unter der Haube plötzlich die neuen Deferreds werkelten.

Jquery 3.1 meldet hingegen auftretende Fehler standardmäßig auf der Konsole. Über die neue Methode »jQuery.readyException()« steuern Programmierer das Verhalten. Alle Fehler, die in einem »ready« -Handler auftreten, leitet Jquery an diese Methode weiter:

jQuery.readyException = function(error) {
  // jeder ready-Handler wirft Fehler
};

Um das Ausführen einer Anwendung nicht zu blockieren, wirft »jQuery.readyException()« den Fehler asynchron und schreibt ihn auf die Konsole.

Schlankheitskur

Seit der Version 3.0 bieten die Entwickler erstmals eine Slim getaufte Variante von Jquery an. In ihr fehlen die Ajax-Funktionen, das Effekte-Modul sowie der als veraltet (deprecated) gekennzeichnete Code. Die Slim-Variante ist damit in der minifizierten Fassung (»jQuery-3.1.0.slim.min.js« ) rund 17 KByte kleiner als das minifizierte normale Jquery 3 (»jQuery-3.1.0.min.js« ), das immer noch mit rund 84,3 KByte ins Gewicht fällt.

Wer von Jquery 2 auf Jquery 3 umsteigen möchte, sollte im Vorfeld unbedingt den Jquery Core 3.0 Upgrade Guide [7] lesen. Die Jquery-Entwickler stellen auf Github zudem ein Migrate-Plugin [8] bereit. Es warnt zum einen, wenn ein Entwickler zu Funktionen greift, die in Jquery 3 nicht mehr existieren oder als veraltet gelten. Zum anderen simuliert es das Verhalten von Jquery 2, was es ermöglicht, Webanwendungen sukzessive zu überarbeiten.

Aufpassen muss auch, wer ein Framework wie Bootstrap [9] oder ein Contentmanagement-System wie Joomla [10] einsetzt. Diese verwenden mitunter Jquery-Versionen, die sich nicht ohne Weiteres austauschen lassen.

Fazit

Jquery 3 ist eine konsequente Weiterentwicklung der Version 2. Die Änderungen sind überschaubar, einigen schon länger als veraltet geltenden Code haben die Entwickler entsorgt. Eine Webanwendung auf Jquery 3 zu hieven, dürfte somit nur wenig Arbeit erfordern. Mit fast 85 KByte in der minifizierten Fassung ist Jquery 3 aber noch immer ein großer Brocken. Das Jquery-Team konzentriert sich ab sofort darauf, Jquery 3 weiterzuentwickeln. Da die alten Versionen 1.12 und 2.2 aber noch Fehlerkorrekturen erhalten, können Entwickler die Migration in aller Ruhe angehen.