jQuery v4.0 Beta-Version

• Unterstützung für IE 10 und älter wurde entfernt; auch die Unterstützung für Edge Legacy, iOS <11, Firefox <65 und Android Browser wurde eingestellt
• APIs, die über mehrere Versionen hinweg als deprecated markiert waren, wurden entfernt: jQuery.cssNumber, jQuery.cssProps, jQuery.isArray, jQuery.parseJSON, jQuery.nodeName, jQuery.isFunction, jQuery.isWindow, jQuery.camelCase, jQuery.type, jQuery.now, jQuery.isNumeric, jQuery.trim, jQuery.fx.interval
• Die internen Array-Methoden push, sort, splice des jQuery-Prototyps wurden entfernt, was Plugins betreffen kann, die von diesen Methoden abhängen
• Bei der Event-Reihenfolge rund um focusout, blur, focusin, focus wurde jQuerys bisheriger Override entfernt; Browser außer IE folgen nun der aktuellen W3C-Reihenfolge blur → focusout → focus → focusin
• jQuery.ajax unterstützt binäre Daten und FormData; das frühere Verhalten, unbekannte Datentypen als solche zu behandeln und in Strings umzuwandeln, wurde auf automatische Verarbeitung umgestellt
• Das Verhalten von jQuery.ajax, bei gemeinsam angegebenem dataType: "json" und Callback automatisch auf eine JSONP-Anfrage hochzustufen, wurde entfernt
• Der jQuery-Quellcode wurde von AMD auf ES modules migriert, und das Packaging-Tool wurde von RequireJS auf Rollup umgestellt
• Unterstützung für Trusted Types wurde hinzugefügt, sodass in TrustedHTML gekapseltes HTML als Eingabe für jQuery-Manipulationsmethoden verwendet werden kann, ohne gegen die CSP-Direktive require-trusted-types-for zu verstoßen
• Die meisten asynchronen Script-Anfragen wurden so geändert, dass sie <script>-Tags verwenden, um CSP-Fehler durch die Nutzung von Inline-Skripten zu vermeiden
• Im slim Build wurden Deferreds und Callbacks entfernt, wodurch er gzip-komprimiert unter 20 kB liegt und etwa 8 kB gzipped bytes kleiner ist als der reguläre Build
• Wenn IE11-Unterstützung erforderlich ist, wird empfohlen, statt des slim Builds den main Build zu verwenden oder eine Polyfill-Konfiguration für native Promises hinzuzufügen
• Vor dem finalen Release soll ein umfassender Upgrade-Guide veröffentlicht werden; das jQuery Migrate plugin soll als Unterstützung für die Migration bereitstehen
• Das Beta-Release ist über das jQuery CDN und npm verfügbar; Drittanbieter-CDNs hosten die Beta nicht und werden später das finale Release 4.0.0 hosten

[GN⁺]

Meinungen auf Hacker News

• Wenn man sich fragt, was jQuery auch nach 2024 noch antreibt, sollte man bedenken, dass WordPress immer noch mehr als ein Drittel des Webs ausmacht und die meisten Installationen sowie zahllose Plugins stark von jQuery abhängen.
  Es ist gut, dass das Entfernen veralteter APIs oder Funktionen vorankommt, und jQuery dürfte im Web noch viele Jahre dominierend bleiben.

  • Außerdem ist jQuery großartig.
    In den letzten etwa 15 Jahren war die Branche viel zu sehr in überkomplexe, schillernde JavaScript-Frameworks verliebt, aber dynamisches Binding für dynamisch erzeugte Formulare, Fehlerzustände behandeln und ein paar Ajax-Aufrufe – das ist bei 99 % der Webseiten im Grunde alles, was an JavaScript nötig ist; der Rest ist oft übertrieben.
    Ich glaube, die Branche wird sich von der Komplexität von React wegbewegen, hin zu der Einfachheit von htmx, Phoenix LiveView, Ruby on Rails Turbo und schlicht jQuery.
  • Was auch immer man sagt: jQuery ist weiterhin mächtig, wichtig und einflussreich.
    Würde man jQuery aus aller Software entfernen, käme ein beträchtlicher Teil der Websites im Internet zum Stillstand.
  • Das ist nicht nur ein WordPress-Thema.
    Eine frühere Firma, bei der ich gearbeitet habe, betrieb ein Enterprise-SaaS-Produkt mit Zehntausenden Zeilen jQuery-Code.
    Solange es nicht zwingend nötig wird, wird das nicht in einem modernen JS-Framework neu geschrieben werden. Der meiste Code wurde vor mehr als zehn Jahren für spezifische Kundenanforderungen geschrieben, und das Argument, ein modernes Framework helfe beim Recruiting, zieht dort auch nicht. Die Firma zahlt Frontend-Engineers nur 75.000 bis 90.000 Dollar, die Fluktuation ist niedrig, und die meisten aktuellen Engineers sind seit über fünf Jahren dabei.
    Vor allem funktioniert der aktuelle Stack gut, und auch die langjährigen Kunden sind zufrieden. Ein großer Teil des Software Engineerings findet in solchen langweiligen Businesses in Städten statt, in denen die Lebenshaltungskosten deutlich niedriger sind als in Big-Tech-Hubs wie der Bay Area oder Seattle.
  • WordPress-Entwickler sind so etwas wie die Klempner der Tech-Branche.
    Nicht glamourös, aber so viele Menschen brauchen sie, dass man damit viel Geld verdienen kann.
    Wenn ich mich irgendwann aus der Welt der Big-Tech-Startups zurückziehe, die jedem neuen Hype hinterherläuft, würde ich gern ehrlich mein Geld verdienen, WordPress-Seiten bauen und jeden Tag um 15 Uhr Feierabend machen.
  • Ich wollte das vor Kurzem auf HN posten und habe es dann gelassen, aber ich finde immer noch kein gutes Event-Chaining-/Bubbling-Modell, mit dem DOM-Member und Instanzen abstrakter Klassen Events auslösen können, die austauschbar verwendbar sind.
    Ich habe an verschiedenen Stellen eigene Event-Dispatcher gebaut, aber jQuery macht diesen Teil richtig. Ich nutze jQuery auch heute fast nur noch für Event-Handling, aber es ist so nützlich, dass ich es in fast jedes clientseitige Projekt einbinde.
    Was ich fragen wollte: Kennt jemand eine leichtgewichtige Bibliothek, die $(window).trigger('click') und $(myClassInstance).trigger('myCustomEvent',{data}) über dieselbe API inklusive asynchronem Listening abhandeln kann?
    Durch den Aufstieg von fetch() und CSS-Selektoren kann man auf den Rest von jQuery inzwischen wohl verzichten, aber ich frage mich, ob man das Rad wirklich neu erfinden muss. Bevor jemand sagt, dass es nach Code Smell riecht, wenn Klasseninstanzen Events dispatchen: Wenn man ein reaktives Framework von Grund auf baut, braucht man das zwingend.
    Meine Basiskomponentenklasse hört zum Beispiel auf bestimmte Custom-Resize-Events, die auf dem Screen auftreten, der sie enthält; dieser Screen sendet das Event nur an Komponenten, die nicht scrollen, aber ihr Inneres neu anordnen müssen. Die Screen-Klasse hört auf window.resize, dispatcht aber nur, wenn das Layout problematisch wird. Für jede Komponente einen eigenen DOM-Resize-Listener an window zu hängen, ergibt keinen Sinn.

• Ich bin überrascht, dass es auf HN immer wieder Leute gibt, die jQuery für eine bloße DOM-Selektionsbibliothek halten.
  Tatsächlich ist es eine breit unterstützte und sehr stabile Werkzeugsammlung, die nicht nur DOM-Selektion bietet, sondern auch Attributmanipulation, Ajax-Requests, Event-Handling, Animationen und allgemeine Utility-Funktionen.
  Außerdem sind die APIs nativer Funktionen, selbst wenn es native Alternativen zu jQuery gibt, nicht annähernd so elegant.
  Wenn man auf serverseitigem HTML nur ein wenig Funktionalität ergänzen muss und kein vollwertiges JS-UI-Framework braucht, ist jQuery als stabile, verlässliche und browserübergreifend kompatible Abhängigkeit nur ein kleiner Preis.

  • Ich habe jQuery vor ein paar Jahren aufgegeben und bin auf reines JavaScript umgestiegen; ich habe nie zurückgeblickt.
    Natives JS hat alles, was jQuery hat – nur ohne den meist schlecht gepflegten, halb fertigen Plugin-Haufen. Solche Plugins tun normalerweise nur genau das, was sie selbst vorhaben, und darüber hinaus nicht viel.
    Reine Selektoren sind zwar ausführlicher, aber jeder halbwegs brauchbare Code-Editor gleicht die Tippgeschwindigkeit aus. Ich will nicht streiten, aber ich verstehe nicht wirklich, warum noch immer so viele Leute jQuery verwenden.
    https://youmightnotneedjquery.com/
  • Wenn man sich die Autorenschaft auf HN anschaut, ist das gar nicht so überraschend.
    Viele greifen, sobald sie mehr als ein bisschen DOM-Selektion brauchen, sofort zu dem gerade angesagten großen JS-Framework – und so war es schon immer.
  • Erst heißt es „Leute, die jQuery einfach für eine DOM-Selektionsbibliothek halten“, und dann werden im Anschluss Selektion und native Funktionen aufgezählt.
  • Es ist viel einfacher, jQuery in ein Projekt aufzunehmen.
    Man braucht keine Build-Tools und den damit verbundenen Ärger. Mit React geht das zwar auch, aber der Funktionsumfang ist nicht vergleichbar.

• In einer Welt, in der viele Menschen aktiv versuchen, die letzten Spuren von jQuery zu entfernen, frage ich mich wirklich, wer heute noch aktiv mit jQuery entwickelt.
  Das meiste, was man früher mit jQuery gemacht hat, ist inzwischen im Browser eingebaut; querySelectorAll ist dafür meiner Meinung nach das stärkste Beispiel

  • Ich bin älter geworden und neue Technologien begeistern mich weniger; deshalb fühlt sich $.ajax() für mich viel einfacher an als Promises, await und async in nativem JS.
    Ich habe in ein paar kleinen persönlichen Projekten auch reines JS verwendet, um mich daran zu gewöhnen, aber für mich ist die Umsetzung mit $.ajax() etwas, das wie Muskelgedächtnis sofort funktioniert.
    Außerdem werden den Code, den ich für DOM-Manipulationen schreibe, tatsächlich wohl nur etwa 20 Leute nutzen. Ich bin nicht für UI zuständig, sondern Backend-Entwickler; ich schreibe nur deshalb auch Frontend, weil es sonst niemanden gibt
  • Laut der Stack-Overflow-Umfrage vom letzten Jahr war jQuery die drittbeliebteste Technologie.
    https://survey.stackoverflow.co/2023/#section-most-popular-t...
  • Ich habe gerade bei einer Firma daran gearbeitet, die letzten Spuren von React zu entfernen und auf HTMX umzustellen.
    Persönlich sehe ich HTMX in gewisser Weise als geistigen Nachfolger von jQuery
  • Ich arbeite ebenfalls aktiv daran, jQuery loszuwerden, aber die Leute sind an das Tool gewöhnt, und eine Umstellung kostet Geld; daher scheint es nicht genug Willen oder geschäftliche Gründe zu geben, es wirklich zu entfernen.
    Neue Projekte mit jQuery zu starten, halte ich für fragwürdig, aber es gibt definitiv Entwickler, die mit der jQuery-Art, Dinge zu erledigen, deutlich vertrauter sind als mit reinem JavaScript
  • Es wird von Solo-Entwicklern oder kleinen Teams genutzt, die moderne Toolchains nicht mögen.
    Ein gutes Beispiel ist levelsio: https://twitter.com/levelsio/status/1750175827197567165
    Ich gehöre auch dazu und nutze weiterhin jQuery.
    Mein aktuelles SaaS ist die Erweiterung https://www.snipcss.com mit wenig UI-Code; mein nächstes SaaS wird eine ChatGPT-basierte Erweiterung für Web-Automatisierung mit ziemlich viel UI sein. Beide verwenden jQuery.
    Der Hauptgrund, warum ich nicht zu reinem JS mit querySelectorAll wechsle: Mir gefällt die Art, Events anzuhängen, insbesondere sie an ein Elternelement zu hängen und damit dynamisch hinzugefügte Kindelemente anzusprechen; außerdem mag ich Function Chaining, und der Code ist kürzer als mit reinem JS

• Großartig. Allerdings habe ich so lange auf 4.0 gewartet, dass ich am Ende mein eigenes jQuery mit ein paar zentralen Unterschieden gebaut habe.
  Animationen, Tweens und Timelines verwenden reines CSS statt jQuerys Custom-System, einzelne Elemente und Listen werden transparent behandelt, und es setzt auf einen Inline-Ansatz

  • Ich dachte immer, es sollte eine moderne, leichtgewichtige jQuery-Alternative dieser Art geben. Gut gemacht, und die Syntax gefällt mir.
    Ich habe selbst etwas Ähnliches implementiert, mit mehr als nur Inline-Events und Standard-Array-Methoden [0].
    Es wäre schön, einen Artikel oder Screencast zu haben, der erklärt, wie bei surreal und dem Begleitprojekt css-scope-inline die Locality of Behavior umgesetzt ist. Ich möchte das verstehen, damit ich es langfristig warten und auch in meine Projekte einbauen kann.
    Ich würde auch gern über die Philosophie des Webs sprechen. Bei ein paar Punkten dürften wir ähnlich denken.
    [0] https://hyperspace.so/All.js.png

• Es fühlt sich an, als wäre ich wieder Junior-Entwickler um 2008. Damals hatte ich eine heftige Diskussion mit dem Tech Lead darüber, ob wir jQuery ins Projekt aufnehmen sollten.
  Seine Argumentation war, dass die Größe der minifizierten Library von 40 KB die Ladezeit der Seite zu stark belasten würde.
  Danach verbrachte er eine ganze Woche damit, Ajax-Calls selbst zu schreiben und die Unterstützung in verschiedenen Browsern zu testen, scheiterte am Ende aber daran, es in Internet Explorer 5 zum Laufen zu bringen.
  In dieser Zeit hat jQuery wirklich viele Probleme gelöst, und am Ende fügte er die Library dem Projekt hinzu

  • Das vergessen die Leute oft: Früher unterschieden sich Browser massiv voneinander, und jQuery war in dieser Hinsicht der einzige vernünftige Klebstoff, der eine Codebase zusammenhalten konnte
  • Applaus für den Tech Lead, der den guten Kampf gekämpft hat

• Gute Arbeit vom jQuery-Team. Ich glaube, ich werde jQuery für immer mögen.
  Es ist einfach ein Tool, das die Arbeit erledigt

  • Bootstrap, PHP, JQuery und WP sind der Stack von Leuten, die tatsächlich Ergebnisse liefern

• Da die DOM-Selektor-Unterstützung der Browser heute so viel besser ist, frage ich mich, warum man 2024 noch jQuery nutzt.
  Das ist nicht abwertend gemeint, und ich finde es cool, dass die Entwicklung noch weitergeht, aber mir ist unklar, welche Use Cases es gibt

  • Es gibt einige ziemlich praktische Selektoren, die document.querySelector() nicht unterstützt.
    Zum Beispiel :selected, :checked und noch ein paar andere, auf die ich tatsächlich schon mehrmals gestoßen bin.
    Insgesamt widerspricht die DOM API fast allem, was meinem Gefühl für gutes API-Design entspricht. Auch an der jQuery API habe ich Kritik, aber sie ist viel besser, und der Lese- und Schreibfluss fühlt sich deutlich natürlicher an
  • Vielleicht wegen Legacy-Projekten.
    Ich warte eine etwa 15 Jahre alte .NET-Web-App und greife dabei wieder auf jQuery zurück. Der Traum, alles mit etwas Modernerem wie Web Components komplett zu refaktorieren oder neu zu schreiben, ist schön, aber in der Praxis werden wir das niemals tun
  • Ich würde auf die bequeme API und das riesige Ökosystem tippen
  • Für Admin-Seiten mag ich jQuery.
    Wenn eine Seite nur von 20 internen Mitarbeitern gesehen wird, ist jQuery leichtgewichtig genug, lässt sich direkt von einem CDN laden, braucht keinerlei Transpilation und erledigt im Grunde alles, was man braucht

• Zur Einordnung: Wir haben den gesamten Drag-and-drop-Editor unserer Low-Code-Plattform mit jQuery gebaut.
  Dazu gehören der Editor, alle Controls, also die UI-Komponenten, und natürlich ist auch der am Ende generierte Code reines jQuery.
  Führungskräfte großer Unternehmen fragen unsere Sales Engineers aber häufig, warum es nicht React oder Angular usw. ist.
  Deshalb freut es mich wirklich, zu lesen, dass jQuery immer noch so relevant ist, und ich bin froh, dass mein Mitgründer und CTO weiterhin hinter dieser Entscheidung steht und nicht versucht, den Stack zu migrieren

• Ich erinnere mich noch daran, als jQuery zum ersten Mal erschien
  Um meine Kollegen zu überzeugen, hielt ich eine interne Präsentation mit dem Titel „Don’t Fear the $“ und erklärte die Vorteile, die jQuery bot

• Ich erinnere mich an die Blütezeit von jQuery, als wir es als Ersatz für Mootools nutzten
  Da viele von React zu HTMX wechseln, könnte es sein, dass sich der Kreis schließt und wir sehen, wie das Web einfach auch reines jQuery verwendet

  • Ich habe eine ähnliche Ära miterlebt, aber dieses Durcheinander vermisse ich nicht
    Wenn ich mir vorstelle, eine moderne App mit Accessibility, Mobile-Support, Echtzeit-Updates, Visualisierungen und sogar einigen PWA-Funktionen nur mit jQuery zu bauen, klingt das wirklich unangenehm
    Ich warte auch darauf, dass der HTMX-Hype auf die Realität trifft. Die Art, Apps mit Pseudo-Attributen wie einer DSL zu programmieren, dürfte schnell ermüden
  • HTMX erinnert mich an Mootools
    Eine kleine und sehr spezialisierte JS-Bibliothek
  • HTMX ist wie $().load()
  • „Viele“ ist vielleicht etwas übertrieben