Was von jQuery übrig bleibt, wenn der Browser mitzieht

Selektoren: die NodeList ist weder Array noch jQuery-Objekt

$('.karte') gibt dir ein jQuery-Objekt zurück, das sich wie eine Menge verhält: Jede Methode darauf läuft für alle Treffer gleichzeitig, und bei null Treffern passiert einfach nichts. document.querySelectorAll('.karte') liefert dagegen eine statische NodeList. Sie kennt forEach, aber weder map noch filter noch reduce. Für diese Methoden schreibst du Array.from(document.querySelectorAll('.karte')) oder nimmst den Spread-Operator. Für genau einen Treffer gibt es document.querySelector, das das erste passende Element oder null zurückgibt.

Aus diesem null entsteht der häufigste neue Fehler beim Umbau. Der optionale Verkettungsoperator hilft beim Lesen, aber nicht beim Schreiben: document.querySelector('#preis')?.textContent = '0' ist kein gültiges JavaScript, weil links vom Gleichheitszeichen kein optionaler Zugriff stehen darf. Du brauchst also entweder ein const-Zwischenergebnis mit anschließendem if, oder du ziehst dir eine kleine eigene Hilfsfunktion, die eine NodeList entgegennimmt und bei null Treffern nichts tut. Letzteres bildet das alte Verhalten am nächsten nach und macht den Umbau der Aufrufe zu reiner Suchen-und-Ersetzen-Arbeit.

Ein Detail, das nur beim Entfernen von Elementen auffällt: getElementsByClassName und getElementsByTagName liefern eine lebende Sammlung, die sich beim Ändern des DOM sofort mitverändert. Wer in einer klassischen for-Schleife darüber läuft und dabei Elemente entfernt, überspringt jedes zweite. querySelectorAll gibt eine Momentaufnahme zurück und hat dieses Problem nicht, weshalb es beim Umbau die richtige Wahl ist, auch wenn die alten Aufrufe schneller getippt sind.

Events: die Delegation ist die eigentliche Arbeit

Aus $el.on('click', fn) wird el.addEventListener('click', fn), das ist der einfache Teil. Interessant wird die Delegation. $(liste).on('click', '.loeschen', fn) hängt einen Handler an die Liste, der auch für später eingefügte Zeilen gilt. Nativ schreibst du den Handler an den Container und suchst dir das eigentliche Ziel: const knopf = event.target.closest('.loeschen'); if (!knopf || !liste.contains(knopf)) return;. Die zweite Prüfung ist kein Zierrat. closest klettert im Baum nach oben, bis es fündig wird, und findet dabei auch Treffer außerhalb deines Containers, sobald der Handler weiter oben hängt.

Beim Entfernen von Handlern fehlt eine Bequemlichkeit, die viele Projekte stark genutzt haben: Namensräume. $el.off('.meinModul') warf alle Handler eines Moduls in einer Zeile weg. Nativ brauchst du dafür entweder dieselbe Funktionsreferenz wie beim Registrieren, oder du gibst allen Handlern eines Moduls ein gemeinsames signal aus einem AbortController mit, also el.addEventListener('click', fn, { signal: controller.signal }). Ein einziges controller.abort() entfernt danach alle davon. Für Handler, die genau einmal laufen sollen, gibt es außerdem { once: true }, und für Scroll- und Touch-Handler { passive: true }.

Die unangenehmste Stelle im Übergang sind eigene Ereignisse. $el.trigger('meinEvent') erzeugt kein echtes DOM-Ereignis, sondern ruft die von jQuery verwalteten Handler auf. Ein natives addEventListener('meinEvent', ...) sieht davon nichts. Umgekehrt sehen jQuery-Handler native Ereignisse sehr wohl, weil jQuery sie ganz normal registriert. Diese Asymmetrie ist der Grund, warum in der Übergangsphase einzelne Handler scheinbar grundlos nicht mehr feuern. Nativ baust du das Ereignis mit new CustomEvent('meinEvent', { detail: nutzlast, bubbles: true }) und schickst es mit el.dispatchEvent los. Solange beide Welten nebeneinander laufen, lohnt es sich, jedes eigene Ereignis auf einmal umzustellen statt Sender und Empfänger getrennt.

Netzwerk: fetch ist kein Ersatz eins zu eins

$.ajax hat einen Aufruf abgewiesen, sobald der Server mit einem Fehlerstatus geantwortet hat. fetch tut das nicht. Ein 404 oder ein 500 ist für fetch eine ganz normale Antwort, das erfüllte Promise enthält dann eben ein Response-Objekt mit ok gleich false. Nur Netzwerkfehler, ein abgebrochener Aufruf oder eine blockierte Anfrage führen zu einer Abweisung. Wenn du den Fehlerzweig aus dem alten Code übernehmen willst, gehört deshalb ein if (!response.ok) throw new Error(...) an den Anfang jeder Auswertung, sonst versucht der nachfolgende Code, eine Fehlerseite als JSON zu lesen.

Ein zweiter Unterschied betrifft den Server und wird beim Umbau regelmäßig übersehen. jQuery setzt bei Anfragen an dieselbe Herkunft den Kopfzeileneintrag X-Requested-With mit dem Wert XMLHttpRequest. Manche Backends entscheiden genau daran, ob sie JSON oder eine vollständige HTML-Seite zurückgeben, und manche Sicherheitsprüfungen hängen ebenfalls daran. fetch schickt diese Kopfzeile nicht. Wenn nach dem Umbau plötzlich HTML statt Daten ankommt oder eine Prüfung anschlägt, ist das fast immer die Ursache. Du setzt den Eintrag entweder von Hand oder passt die Erkennung auf der Serverseite an, etwa auf den Accept-Wert.

Für die restlichen Einstellungen gibt es direkte Entsprechungen. Die Zeitgrenze aus $.ajax({ timeout: 8000 }) baust du mit signal: AbortSignal.timeout(8000) nach, denselben Weg nutzt du für ein manuelles Abbrechen über einen eigenen AbortController. Cookies schickt fetch bei gleicher Herkunft mit, für andere Herkünfte brauchst du credentials: 'include'. Und die Umwandlung passiert nicht mehr automatisch anhand eines dataType, sondern ausdrücklich über await response.json() oder await response.text().

Die Plugins bestimmen den Zeitplan, nicht der eigene Code

Bootstrap in Version 4 setzt jQuery voraus, Version 5 nicht mehr. Genau diese Art von Abhängigkeit entscheidet, ob dein Ausstieg eine Woche oder ein Quartal dauert. Bei Datentabellen, durchsuchbaren Auswahlfeldern, Karussells und Bildergalerien gibt es fast immer eine Alternative ohne Abhängigkeit, aber sie hat eine andere Programmierschnittstelle, eigene Marken im HTML und ein anderes Aussehen. Der Aufwand steckt also nicht im Austausch der Bibliothek, sondern in Markup, Styling und den Stellen, an denen euer Code die Erweiterung steuert.

In der Zwischenzeit hilft eine Isolierung. Lad jQuery nur noch dort nach, wo eine dieser Erweiterungen tatsächlich läuft, statt es global im Grundbündel zu halten. Mit jQuery.noConflict(true) gibst du $ und jQuery an ihre vorherigen Besitzer zurück und behältst die Referenz nur in dem Modul, das sie noch braucht. Der Rest der Anwendung ist damit früher frei, auch wenn eine einzelne Seite noch eine Weile mitzieht.

Damit der Bestand nicht nachwächst, gehört eine Regel in die Linter-Konfiguration. Mit no-restricted-globals auf $ und jQuery meldet der Linter jede neue Verwendung, während die bereits vorhandenen Dateien über eine Ausnahmeliste stillbleiben. Ohne diese Bremse fügt die nächste schnelle Fehlerbehebung in einer alten Datei wieder drei Aufrufe hinzu, weil dort ja ohnehin schon welche stehen.

Wann du die Bibliothek bewusst liegen lässt

Eine Anwendung, an der nur noch Fehler behoben werden und die keine neuen Funktionen mehr bekommt, gewinnt durch den Umbau wenig. Der Gewinn liegt nicht in erster Linie in der eingesparten Dateigröße, sondern darin, dass neue Leute im Team eine Sprache lesen, die sie ohnehin kennen, und dass eine Abhängigkeit weniger gepflegt und aktualisiert werden muss. Wo beides nicht zieht, ist der Umbau eine Änderung ohne Nutzen und mit Risiko.

Der wirklich schlechte Zustand ist der halbe Ausstieg ohne Enddatum. Dann laufen zwei Denkweisen nebeneinander, die Asymmetrie bei eigenen Ereignissen bleibt bestehen, und niemand weiß beim Lesen einer Datei mehr, welche Regeln gerade gelten. Wenn du anfängst, leg vorher fest, welche Plugins ersetzt werden und welche bleiben dürfen, und schreib beides auf. Ein bewusst stehen gelassenes Plugin mit jQuery daneben ist ein sauberer Zustand, ein vergessenes ist es nicht.