07. Sept. 2025·7 Min
Was ist jQuery — und warum sagen manche, es sei vergessen?
jQuery machte JavaScript mit einfachem DOM, Events und AJAX leichter. Erfahre, was es ist, warum es an Bedeutung verlor und wann es heute noch sinnvoll ist.
jQuery machte JavaScript mit einfachem DOM, Events und AJAX leichter. Erfahre, was es ist, warum es an Bedeutung verlor und wann es heute noch sinnvoll ist.
jQuery ist eine kleine JavaScript‑Bibliothek, die gebräuchliche Aufgaben auf einer Webseite einfacher macht—Dinge wie Elemente auswählen, auf Klicks reagieren, Text ändern, Bereiche anzeigen/ausblenden und Anfragen an einen Server senden.
Wenn du schon einmal Code wie $("button").click(...) gesehen hast, ist das jQuery. Das $ ist einfach eine Abkürzung für „finde etwas auf der Seite und mache etwas damit.“
Dieser Leitfaden ist praktisch und nicht zu technisch: was jQuery ist, warum es beliebt wurde, warum neuere Projekte seltener darauf zurückgreifen und wie du damit umgehst, wenn deine Seite es noch nutzt. Er ist bewusst länger, damit wir klare Beispiele und Praxis‑Tipps statt schneller Meinungen liefern können.
Wenn Leute sagen, jQuery sei „vergessen“, meinen sie normalerweise nicht, dass es verschwunden ist. Sie meinen:
Die Geschichte ist also nicht „jQuery ist tot“. Eher: jQuery ist vom Standard‑Tool für Frontend‑Arbeit zu einer Legacy‑Abhängigkeit geworden, die du erben kannst — und gelegentlich bewusst weiter nutzt.
Vor jQuery bedeutete Frontend‑Arbeit oft, die gleichen kleinen, nervigen Code‑Stücke immer wieder zu schreiben—und sie in mehreren Browsern zu testen, die sich unterschiedlich verhielten. Selbst einfache Aufgaben wie „dieses Element finden“, „einen Klick‑Handler anhängen“ oder „eine Anfrage senden“ konnten zu vielen Spezialfällen werden.
Ein Großteil früher JavaScript‑Arbeit drehte sich weniger um Features und mehr darum, mit der Umgebung zu kämpfen. Du schriebst Code, der in einem Browser funktionierte, und fügtest dann Verzweigungen hinzu, damit er in einem anderen Browser ebenfalls lief. Teams hielten oft ihre eigenen „Mini‑Bibliotheken“ mit Helferfunktionen, nur um die täglichen UI‑Änderungen zu überstehen.
Das Ergebnis: langsamere Entwicklung, mehr Bugs und die ständige Angst, dass eine kleine Änderung einen älteren Browser bricht, auf den deine Nutzer noch angewiesen waren.
Browser waren sich bei wichtigen Details nicht einig. DOM‑Selection‑Methoden, Event‑Handling und sogar das Ermitteln von Elementgrößen konnten variieren. Internet Explorer hatte besonders andere APIs für Events und XMLHTTP‑Requests, sodass „Standard“ nicht immer portabel war.
Das war relevant, weil Webseiten nicht nur für einen Browser gebaut wurden. Wenn dein Checkout‑Formular, Menü oder Modal in einem verbreiteten Browser versagte, hatte das echte geschäftliche Folgen.
jQuery wurde wichtig, weil es eine konsistente, benutzerfreundliche API bot, die diese Unterschiede glättete.
Es machte gängige Aufgaben deutlich einfacher:
Noch wichtiger: jQuerys „write less, do more“‑Stil half Teams, schneller zu liefern und weniger browser‑spezifische Überraschungen zu erleben—besonders in einer Zeit, in der „moderne DOM‑APIs“ nicht so leistungsfähig oder weit verbreitet waren wie heute.
jQuerys echte Stärke war nicht, völlig neue Ideen einzuführen—sondern gängige Browseraufgaben konsistent und einfach zu machen. Wenn du älteren Frontend‑Code liest, siehst du jQuery typischerweise bei vier alltäglichen Jobs.
$()‑Funktion)Die $()‑Funktion erlaubte es, Elemente mit CSS‑ähnlichen Selektoren „zu greifen“ und dann als Gruppe zu bearbeiten.
Statt sich mit Browser‑Eigenheiten und umständlichen APIs herumzuschlagen, konnte man alle Items auswählen, ein Kindelement finden oder zum Elternteil hochgehen—mit kurzen, kettelbaren Aufrufen.
jQuery machte es einfach, auf Nutzeraktionen zu reagieren:
click für Buttons und Linkssubmit für Formulareready, um Code auszuführen, wenn die Seite geladen istEs glättete auch Unterschiede in der Handhabung von Event‑Objekten und dem Binden, was wichtig war, wenn die Browserunterstützung uneinheitlich war.
Bevor fetch() Standard wurde, waren $.ajax(), $.get() und $.post() einfache Wege, Daten vom Server anzufordern und die Seite ohne Reload zu aktualisieren.
Das ermöglichte Muster, die heute normal erscheinen—Live‑Suche, „mehr laden“‑Buttons, partielle Seitenaktualisierungen—mit einer einzigen, vertrauten API.
jQuery machte schnelle UI‑Feinheiten wie hide(), show(), fadeIn(), slideToggle() und animate() populär. Sie waren praktisch für Menüs, Benachrichtigungen und einfache Übergänge—vor allem, als CSS‑Support noch weniger verlässlich war.
Zusammen erklären diese Bequemlichkeiten, warum Legacy‑JavaScript‑Code oft mit $( beginnt und warum jQuery so lange das Standard‑Tool war.
Viel von jQuerys Ruf kommt daher, wie wenig Code nötig war, um übliche UI‑Aufgaben zu erledigen—vor allem, als Browserunterschiede noch schmerzhaft waren. Ein direkter Vergleich macht das deutlich.
jQuery
// Select a button and run code when it's clicked
$('#save').on('click', function (e) {
e.preventDefault();
$('.status').text('Saved!');
});
Modernes (vanilla) JavaScript
// Select a button and run code when it's clicked
const saveButton = document.querySelector('#save');
const status = document.querySelector('.status');
saveButton?.addEventListener('click', (e) => {
e.preventDefault();
if (status) status.textContent = 'Saved!';
});
Auf den ersten Blick wirkt die jQuery‑Variante „sauberer“: eine Kette wählt das Element, hängt den Handler an und aktualisiert den Text. Diese Kompaktheit war ein großes Verkaufsargument.
Modernes JavaScript ist etwas ausführlicher, aber auch expliziter:
querySelector und addEventListener sagen genau, was passiert.textContent ist eine Standard‑DOM‑Eigenschaft (kein Bibliotheks‑Wrapper).?.) und Nullprüfungen machen klar, was passiert, wenn Elemente fehlen.Das hängt vom Kontext ab. Wenn du eine ältere Codebasis pflegst, die überall jQuery nutzt, ist die jQuery‑Variante vielleicht konsistenter und schneller zu bearbeiten. Für neuen Code sind moderne DOM‑APIs jedoch breit unterstützt, reduzieren Abhängigkeiten und lassen sich leichter in heutige Tools und Frameworks integrieren.
Lange Zeit war jQuerys größter Vorteil Vorhersehbarkeit. Du konntest auf eine Weise schreiben, um Elemente auszuwählen, Events anzuhängen oder Ajax‑Anfragen zu machen—und es funktionierte meist überall.
Im Laufe der Jahre haben Browser standardisiert und sich verbessert. Viele der „must‑have“‑Bequemlichkeiten, die jQuery bündelte, sind jetzt in JavaScript selbst verfügbar, sodass man häufig keine zusätzliche Bibliothek mehr für die Basics braucht.
Moderne DOM‑Methoden decken viele jQuery‑Muster ab:
document.querySelector() / document.querySelectorAll() ersetzen $(...) in vielen Fällen.element.classList.add() / .remove() / .toggle() übernehmen Klassenmanipulationen.element.addEventListener() ersetzt jQuerys Event‑Wrapper für die meisten Fälle.Statt jQuery‑spezifische Helfer zu merken, verlässt du dich auf Standard‑APIs, die in modernen Browsern funktionieren.
Wo früher $.ajax() gängig war, übernimmt fetch() viele Alltagsanfragen mit weniger Zeremonie, besonders in Kombination mit JSON:
const res = await fetch('/api/items');
const data = await res.json();
Du musst weiterhin Fehler und Timeouts explizit behandeln, aber die Kernidee—Anfragen ohne Plugin—ist nun nativ.
jQuery brachte viele Menschen mit Callbacks und $.Deferred an asynchronen Code heran. Heute machen Promises und async/await asynchrone Abläufe lesbarer, und ES‑Module klären die Organisation des Codes.
Diese Kombination—moderne DOM‑APIs + fetch + moderne Sprachfeatures—hat viele der ursprünglichen Gründe reduziert, warum Teams standardmäßig zu jQuery griffen.
jQuery wuchs in einer „Multi‑Page‑Website“‑Ära: der Server rendert HTML, der Browser lädt eine Seite und du fügst Verhalten hinzu—Klick‑Handler, Animationen, Ajax—auf bestehendem Markup.
Moderne Frontend‑Frameworks kehrten dieses Modell um. Statt Seiten zu erweitern, erzeugen Apps heute oft den Großteil der UI im Browser und halten sie synchron mit Daten.
React, Vue und Angular machten das Bauen von Interfaces aus Komponenten populär—kleine, wiederverwendbare Teile, die ihr Markup, Verhalten und ihren State verwalten.
In diesem Setup möchte das Framework die Quelle der Wahrheit für den Bildschirminhalt sein. Es verfolgt den State, rendert Teile der UI neu, wenn sich State ändert, und erwartet deklaratives Beschreiben von Änderungen („wenn X wahr ist, zeige Y“).
jQuery hingegen fördert imperatives DOM‑Manipulieren („finde dieses Element, ändere seinen Text, verstecke es“). Das kann mit dem Rendering‑Zyklus eines Frameworks konfligieren. Wenn du DOM‑Nodes manuell änderst, die eine Komponente „besitzt“, kann der nächste Re‑Render deine Änderungen überschreiben—oder du bekommst schwer zu findende Inkonsistenzen.
Als SPAs verbreitet wurden, setzten Teams Build‑Tools und Bundler (Webpack, Rollup, Vite) ein. Statt ein paar Script‑Tags zu verwenden, importierst du Module, bundlest nur, was du brauchst, und optimierst für Performance.
Dieser Wandel machte Entwickler auch sensibler gegenüber Abhängigkeiten und Bundle‑Größe. jQuery „nur für den Fall“ einzubinden fühlte sich weniger natürlich an, wenn jedes Kilobyte und jedes Drittanbieter‑Update Teil der Pipeline war.
Man kann jQuery in einem Framework nutzen, aber oft wird es dann zu einer Insel—schwerer zu testen, schwieriger zu verstehen und anfälliger bei Refactorings. Daher wählten viele Teams framework‑eigene Muster statt jQuery‑basierter DOM‑Skripte.
jQuery selbst ist nicht „riesig“, aber es kommt oft mit Ballast. Viele Projekte, die jQuery nutzen, sammeln Plugins (Slider, Datepicker, Modal‑Libraries, Validierungs‑Helfer), die jeweils zusätzlichen Drittanbieter‑Code laden. Im Laufe der Zeit kann eine Seite so mehrere überlappende Utilities ausliefern—besonders wenn Features schnell hinzugefügt und nie überarbeitet wurden.
Mehr JavaScript bedeutet für den Browser mehr zu laden, zu parsen und auszuführen, bevor die Seite sich reaktionsfähig anfühlt. Das ist auf mobilen Geräten, langsamen Netzen und älterer Hardware deutlicher spürbar. Selbst wenn Nutzer schließlich eine flüssige Erfahrung haben, kann die „time to usable“ leiden, wenn die Seite auf zusätzliche Skripte und deren Abhängigkeiten wartet.
Ein häufiges Muster in lang laufenden Seiten ist eine „hybride“ Codebasis: einige Features mit jQuery, neuere Teile mit einem Framework (React, Vue, Angular) und ein paar vanilla‑JS‑Schnipsel dazwischen. Diese Mischung kann verwirrend werden:
Wenn mehrere Stile koexistieren, werden kleine Änderungen riskanter. Ein Entwickler ändert eine Komponente, aber ein alter jQuery‑Script greift noch in dasselbe Markup ein und verursacht schwer reproduzierbare Bugs.
Teams entfernen sich schrittweise von jQuery nicht, weil es „nicht mehr funktioniert“, sondern weil moderne Projekte auf kleinere Bundles und klarere Verantwortlichkeiten optimiert sind. Mit wachsender Site macht das Reduzieren von Dritt‑Code und das Standardisieren auf einen Ansatz Performance‑Tuning, Debugging und Onboarding wesentlich einfacher.
jQuery war nicht nur beliebt—es wurde Default. Jahrelang war es der einfachste Weg, interaktive Seiten zuverlässig browserübergreifend zum Laufen zu bringen, also landete es in zahllosen Templates, Snippets, Tutorials und Copy‑Paste‑Lösungen.
Ist das einmal passiert, wurde jQuery schwer zu vermeiden: Selbst wenn eine Seite nur eine kleine Funktion nutzte, lud sie oft die ganze Bibliothek, weil alles andere davon ausging, dass sie vorhanden ist.
Ein großer Grund, warum jQuery weiterhin auftaucht, ist einfach: sein Erfolg machte es in Drittanbieter‑Code „überall vorhanden“. Ältere UI‑Widgets, Slider, Lightboxes, Formularvalidatoren und Theme‑Skripte wurden häufig als jQuery‑Plugins geschrieben. Wenn eine Seite von einem solchen Baustein abhängt, kann das Entfernen von jQuery bedeuten, diese Abhängigkeit neu zu schreiben oder zu ersetzen—nicht nur ein paar Zeilen ändern.
WordPress ist eine große Quelle für „Legacy‑jQuery“. Viele Themes und Plugins—vor allem ältere—nutzen jQuery für Frontend‑Verhalten, und historisch basierten auch Admin‑Screens oft darauf. Selbst wenn neuere Versionen moderneres JavaScript nutzen, hält die lange Spur existierender Erweiterungen jQuery an vielen Installationen präsent.
Ältere Seiten priorisieren häufig „brich nicht, was funktioniert“. jQuery beizubehalten ist oft die sicherste Option, wenn:
Kurz: jQuery ist nicht unbedingt „vergessen“—es ist oft Bestandteil des Fundaments, auf dem eine Seite gebaut wurde, und Fundamente ersetzt man nicht leicht.
jQuery ist keine „schlechte“ Software—es ist nur weniger nötig als früher. Es gibt realistische Situationen, in denen das Beibehalten (oder sogar Hinzufügen) von ein wenig jQuery die praktischste Wahl ist, besonders wenn Zeit, Kompatibilität oder Stabilität wichtiger sind als architektonische Reinheit.
Wenn du Anforderungen hast, die ältere Browser (insbesondere alte Internet‑Explorer‑Versionen) einschließen, kann jQuery DOM‑Auswahl, Event‑Handling und AJAX in einer Weise vereinfachen, die native APIs ohne zusätzliche Polyfills nicht direkt bieten.
Die Kernfrage ist Kosten: Das Unterstützen von Legacy‑Browsern bedeutet meist, ohnehin mehr Code auszuliefern. In diesem Kontext kann jQuery ein akzeptabler Teil des Kompatibilitätspakets sein.
Wenn eine Seite bereits rund um jQuery gebaut ist, sind kleine UI‑Änderungen oft schneller und sicherer, wenn sie in demselben Stil umgesetzt werden. Ansätze zu mischen erzeugt Verwirrung (zwei Muster für Events, zwei Wege, das DOM zu manipulieren) und erschwert die Wartung.
Eine praktische Regel: Wenn du nur ein oder zwei Seiten bearbeitest und die App ansonsten stabil ist, ist Patchen mit jQuery in Ordnung—vermeide es jedoch, jQuery in neue „Systeme“ zu übernehmen, die du später wieder auflösen musst.
Für eine einfache Marketing‑Seite oder ein internes Tool—kein Bundler, kein Transpiler, kein Komponenten‑Framework—kann jQuery immer noch ein praktischer „Single Script Tag“‑Helfer sein. Besonders wenn du ein paar Interaktionen (Toggle‑Menüs, einfache Formularverhalten) brauchst und keinen Build‑Pipeline einführen willst.
Viele ausgereifte Plugins (Datepicker, Tabellen, Lightboxes) basieren auf jQuery. Wenn ein älteres Plugin geschäftskritisch und stabil ist, kann das Beibehalten von jQuery die geringste Risikooption sein.
Prüfe vorher, ob es eine gepflegte, nicht‑jQuery‑Alternative gibt—oder ob ein Upgrade des Plugins eine größere Neuentwicklung erzwingen würde, die das Projekt aktuell nicht leisten kann.
Der Weg weg von jQuery ist weniger ein großer Rewrite als das schrittweise Reduzieren einer Abhängigkeit, ohne funktionierendes Verhalten zu brechen. Der sicherste Ansatz ist inkrementell: Seiten funktionsfähig lassen, während du Stück für Stück austauschst.
Beantworte praktisch drei Fragen:
Dieses Audit verhindert, dass du Dinge ersetzt, die du nicht brauchst, und zeigt „versteckte“ Abhängigkeiten wie ein Plugin, das still $.ajax() verwendet.
Die meisten Teams erzielen schnelle Erfolge, indem sie die simpelsten Muster tauschen:
$(".card") → document.querySelectorAll(".card").addClass() / .removeClass() → classList.add() / classList.remove().on("click", ...) → addEventListener("click", ...)Mach das in kleinen PRs, damit Reviews und Rollbacks einfach sind.
Wenn du $.ajax() nutzt, migriere diese Aufrufe zu fetch() (oder einem kleinen HTTP‑Helper) Endpunkt für Endpunkt. Halte die Response‑Shapes gleich, damit sich der Rest der UI nicht sofort ändern muss.
// jQuery
$.ajax({ url: "/api/items", method: "GET" }).done(renderItems);
// Modern JS
fetch("/api/items")
.then(r => r.json())
.then(renderItems);
Bevor du jQuery entfernst, erweitere die Abdeckung dort, wo es wichtig ist: kritische Nutzerflüsse, Formularabsendungen und dynamische UIs. Selbst leichte Checks (Cypress‑Smoke‑Tests oder eine QA‑Checkliste) fangen Regressionen früh.
Rolle Änderungen hinter Feature‑Flags aus, wenn möglich, und überprüfe Analytics/Fehlerraten. Teams, die Legacy‑Frontends modernisieren, prototypen manchmal Ersatzlösungen in Tools (z. B. Koder.ai) und nutzen Snapshots/Rollback‑Workflows, um iterativ zu arbeiten, ohne eine „bekannt gute“ Version zu verlieren.
Wenn du Hilfe bei der Planung brauchst, siehe /blog/jquery-vs-vanilla-js für einen Vergleich, den du während Refactors verwenden kannst.
Das Entfernen von jQuery ist oft weniger „Syntax ersetzen“ als das Entwirren jahrelanger Annahmen. Hier Fallen, die Teams verlangsamen—und wie du sie vermeidest.
Ein Komplett‑Rewrite klingt sauber, erzeugt aber oft einen langen Branch, viele Regressionen und Druck, unfertige Arbeit auszuliefern. Sicherer ist der inkrementelle Weg: ein Feature oder eine Seite nach der anderen ersetzen, Verhalten identisch halten und Tests um die betroffenen Teile ergänzen.
Wenn du React/Vue/Svelte (oder ein leichtes Komponenten‑System) einführst, während jQuery noch dieselben DOM‑Nodes manipuliert, bekommst du leicht einen „UI‑Tauziehen“: das Framework rendert neu und überschreibt jQuery‑Änderungen, während jQuery Elemente ändert, die das Framework kontrolliert.
Faustregel: Ziehe klare Grenzen.
Viel älterer Code setzt auf delegierte Events wie:
$(document).on('click', '.btn', handler)
Natives DOM kann das auch, aber Matching und Erwartungen an this/event.target können anders sein. Häufige Bugs: Handler feuern für das falsche Element (wegen verschachtelter Icons/Spans) oder sie feuern nicht für dynamisch hinzugefügte Items, weil der Listener am falschen Vorfahren hing.
Beim Ersetzen delegierter Events bestätige:
closest() wird oft benötigt)jQuery UI‑Effekte und eigene Animationen haben manchmal Accessibility‑Probleme verdeckt oder eingeführt. Beim Ersetzen von Fades, Slides und Toggles prüfe:
aria-expanded bei Disclosure‑Buttons)prefers-reduced-motion‑EinstellungenDiese Fallstricke früh anzugehen beschleunigt die Migration und macht die UI zuverlässiger—noch bevor das letzte $() verschwindet.
jQuery ist nicht „schlecht“. Es löste echte Probleme—vor allem, als Browser unterschiedlich waren und interaktive Seiten viel repetitiven DOM‑Code erforderten. Was sich geändert hat: Für neue Projekte brauchst du es meist nicht mehr.
Einige Kräfte verschoben es vom Default zur Legacy‑Abhängigkeit:
Wenn du eine ältere Seite wartest, kann jQuery weiterhin eine vernünftige Lösung sein—besonders für kleine Fixes, stabile Plugins oder Seiten, die kein komplettes Rebuild rechtfertigen. Beim Erstellen neuer Features: Zuerst native JavaScript bevorzugen und jQuery nur dann behalten, wenn es klar Zeit spart.
Zum Weiterlesen, praxisnah:
Wenn du schneller modernisieren willst, denk an Tools, die inkrementelles Prototyping und Shipping unterstützen. Koder.ai kann hier hilfreich sein: Du beschreibst gewünschtes Verhalten im Chat, erzeugst eine React‑basierte UI und bei Bedarf ein Go/PostgreSQL‑Backend und exportierst den Quellcode, wenn du ihn in eine bestehende Codebasis integrieren willst.
Wenn du Tools oder Support‑Optionen evaluierst, kannst du auch diese Optionen prüfen: /pricing
jQuery ist eine JavaScript‑Bibliothek, die häufige Browseraufgaben vereinfacht: Elemente auswählen, Ereignisse behandeln, Ajax‑Anfragen machen und einfache Effekte (anzeigen/ausblenden, fades, slides) ausführen. Ihr typisches Muster ist die Verwendung von () (dem $), um Elemente auszuwählen und darauf Methoden zu ketten.
$ ist einfach eine Kurzfunktion (normalerweise von jQuery bereitgestellt), die Elemente auf der Seite findet—ähnlich wie document.querySelectorAll()—und ein jQuery‑Objekt zurückgibt, auf dem du Methoden ketten kannst.
Wenn du () in älterem Code siehst, bedeutet das oft: „wähle etwas aus und mache etwas damit.“
jQuery war historisch wichtig, weil es uneinheitliches Browserverhalten vereinheitlichte. Früher erforderten einfache Dinge wie Events, DOM‑Traversierung und Ajax oft browserspezifische Workarounds.
jQuery bot eine verlässliche API, mit der Teams schneller liefern konnten, ohne sich ständig um Cross‑Browser‑Probleme kümmern zu müssen.
Weil moderne Browser und JavaScript aufgeholt haben. Heute lassen sich klassische jQuery‑Aufgaben oft durch eingebaute Features ersetzen:
querySelector / querySelectorAll für AuswahlNein. Viele bestehende Seiten nutzen jQuery weiterhin und es funktioniert nach wie vor. „Legacy“ bedeutet meist, dass es in älteren Codebasen verbreiteter ist als in neuen Projekten.
Die praktische Frage ist, ob sich das Beibehalten angesichts Performance, Wartung und vorhandener Abhängigkeiten (insbesondere Plugins) lohnt.
Weil es in älteren Ökosystemen tief verwurzelt ist—insbesondere in Themes und Plugins. Ein häufiges Beispiel ist WordPress: viele Erweiterungen gingen davon aus, dass jQuery vorhanden ist.
Wenn deine Seite von einem jQuery‑Plugin (Slider, Datepicker, Lightbox, Validator) abhängt, bedeutet das Entfernen von jQuery oft, dass du dieses Plugin ersetzen oder neu schreiben musst, nicht nur ein paar Zeilen anpassen.
Ja — in einigen praktischen Situationen:
In diesen Fällen können Stabilität und Geschwindigkeit wichtiger sein als das Reduzieren von Abhängigkeiten.
Schrittweise und mit Messung:
Event‑Delegation ist ein häufiges Problem. jQuery‑Code wie:
$(document).on('click', '.btn', handler)
funktioniert anders im nativen DOM. Beim Ersetzen solltest du sicherstellen:
Ja — Effekte und DOM‑Änderungen können versehentlich Accessibility‑Probleme verursachen. Beim Ersetzen von hide()/show() oder slide/fade solltest du prüfen:
aria-expandedprefers-reduced-motionDass das Verhalten visuell gleich bleibt reicht nicht; Interaktion und Tastaturfluss müssen stimmen.
classListaddEventListener für Ereignissefetch + async/await für AnfragenDeshalb benötigen neue Projekte seltener eine Kompatibilitätsschicht für die Basics.
$.ajax() sukzessive auf fetch() umstellen—Endpunkt für Endpunkt.Kleine PRs und gestaffelte Rollouts reduzieren das Regressionsrisiko.
closest() ist oft nötig)Teste Fälle mit dynamisch hinzugefügten Elementen.