Vorteile der Verwendung von reinem JavaScript gegenüber JQuery


86

Was sind die Vorteile der Verwendung von Nur-Javascript gegenüber der Verwendung von Nur-JQuery?

Ich habe nur begrenzte Erfahrung mit JavaScript und JQuery-Codierung. Ich habe HTML-Seiten jeweils Teile und Ausschnitte hinzugefügt, aber hauptsächlich serverseitige Inhalte in anderen Sprachen codiert. Mir ist aufgefallen, dass Sie zwar theoretisch die gleichen Dinge mit einem der beiden Ansätze tun können (und Sie können sie natürlich sogar in dasselbe Projekt verwechseln), aber die Tendenz scheint, JQuery immer von Anfang an zu verwenden egal was das projekt verlangt.

Ich frage mich also, ob es pünktlich Vorteile bringt, nicht nur JQuery zu verwenden, sondern einfach nur einfaches altes JavaScript zu verwenden.

Ich weiß, dass dies wie eine Nicht-Frage aussieht, weil darüber gesagt werden kann, dass "es keine definitive Antwort gibt" oder "es kann für immer diskutiert werden", aber ich hoffe tatsächlich auf pünktliche Antworten wie "Sie können dies in" ein Ansatz und Sie können es nicht mit dem anderen tun ".


Gemäß dem Kommentar von scrwtp beziehe ich mich nicht nur auf den DOM-Handhabungsteil. Meine Frage ist eher: JQuery ist eine Bibliothek. Für Javascript. Was ich an dieser Bibliothek im Gegensatz zu anderen Bibliotheken für andere Sprachen merkwürdig finde, ist, dass sie in JQyerys Fall so konzipiert zu sein scheint, dass sie ausschließlich verwendet werden kann und kein direktes Berühren von Javascript erfordert. Dies ist im Gegensatz zu Hibernate und SQL, wo obwohl die Bibliothek (oder besser gesagt das Framework in diesem Fall, aber ich denke, die Analogie gilt immer noch) den Griff auf eine Menge Aspekte nimmt, Sie immer noch SQL verwenden können, wenn Sie es verwenden Zumindest für einige Randfälle. Im Fall von JQuery & Javascript können Sie jedoch alles, was Sie mit Javascript tun, nur mit JQuery tun (oder zumindest scheint mir das so zu sein).


Laut Stargazer712's Kommentar: Ja, ich stimme Ihnen zu, die Frage hier ist, wie Sie es ausdrücken, "nur eine Frage, wie Sie JavaScript verwenden werden". Das ist es, was ich eigentlich wollte, aber ich habe einige schlechte Formulierungen gemacht. Hier ist eine weitere Analogie: Spring Expression Language. Es ist eine Java-Bibliothek. Sie können es nicht ohne Java verwenden, es basiert auf Java, und Sie können immer noch Java verwenden. In der Praxis können Sie diese Bibliothek jedoch zu einem Java-Projekt hinzufügen und dann Ihren gesamten Code mit der Expressionssprache von Spring EL schreiben, wodurch Ihr Code praktisch überhaupt nicht mehr Java ähnelt und sich sogar das Paradigma ändert (zum Beispiel, wenn Sie es nicht mehr haben) starke Durchsetzung bei Verwendung dieser). Obwohl ich verstehe, dass JQuery nur eine JS-Bibliothek ist, scheint es mir, dass es in der Praxis den gleichen Effekt hat wie Spring EL mit Java, dh Sie können seine APIs nur während eines Projekts verwenden und die APIs von JavaScript vermeiden. Und ich habe mich gefragt, ob das eine gute Sache ist, was die Fallstricke usw. sein könnten.

(Und ja, nachdem ich die Antworten aller gelesen habe, verstehe ich Folgendes:

ein. meine frage ist bis zu einem gewissen punkt etwas unsinnig

b. Selbst wenn die Frage vollständig zutreffend wäre, wäre die Antwort so ziemlich "Nein, Sie können nicht einfach immer nur JQuery verwenden."


25
Es ist nicht korrekt zu sagen, dass "nur JQuery verwenden" _ JQuery ist eine JavaScript-Bibliothek.
SuperM

4
Keine for- oder while-Schleifen, keine Variablen, keine Funktionen? Das alles ist JavaScript.
SuperM

2
Mit "normales altes JavaScript" meinen Sie wahrscheinlich JavaScript DOM API. Sie können es überprüfen und die Frage bearbeiten, um Verwirrung zu vermeiden.
Scrwtp

4
Ist Cross-Browser-Kompatibilität nicht Grund genug?
Simon Whitehead

10
"Es (jquery) scheint so konzipiert zu sein, dass es ausschließlich verwendet werden kann und kein direktes Berühren von Javascript erforderlich ist." Das ist nur sachlich falsch. jQuery ist einfach eine Sammlung von JavaScript-Funktionen (wenn auch mit seltsamen Namen wie "$"). Ein wichtiger Teil des Verständnisses von jQuery ist diese Erkenntnis. Seine GERADE zusätzlichen Funktionen, die die DOM-Manipulation und das Schleifen handhaben.
Graham

Antworten:


113

Zunächst einmal: Es ist unmöglich, nur jQuery zu verwenden. Alles, was jQuery tut, ist, ein $ -Objekt mit einer Reihe von Methoden zu Ihrem globalen Gültigkeitsbereich hinzuzufügen. Selbst manipulativere Bibliotheken wie Prototype sind keine Alternative zu Javascript, sondern ein Werkzeug, um häufig auftretende Probleme zu lösen.

Die Hauptvorteile beim Hinzufügen von jQuery zu Ihrem Toolbelt sind:

  • Browserkompatibilität - So etwas wie .attr () ist viel einfacher als die nativen Alternativen und funktioniert nicht über verschiedene Browser hinweg.
  • Vereinfachung von normalerweise komplizierten Operationen - Wenn Sie eine gut geschriebene browserübergreifende Version einer XHR-Methode sehen möchten, werfen Sie einen Blick auf den Quellcode von $ .ajax - für diese Methode allein ist es den Aufwand von jQ fast wert.
  • DOM-Auswahl - einfache Dinge wie das Binden von Ereignissen und das Auswählen von DOM-Elementen können kompliziert sein und sich je nach Browser unterscheiden. Ohne viel Wissen können sie auch leicht schlecht geschrieben werden und Ihre Seite verlangsamen.
  • Zugriff auf zukünftige Funktionen - Dinge wie .indexOf und .bind sind natives Javascript, werden jedoch von vielen Browsern noch nicht unterstützt. Wenn Sie jedoch die jQuery-Versionen dieser Methoden verwenden, können Sie sie browserübergreifend unterstützen.

Javascript ist nicht mehr nur eine clientseitige Sprache, und da jQuery so DOM-abhängig ist, ist es ein schrecklicher Kandidat, auf den Server zu wechseln. Ich empfehle dringend, sich etwas Zeit zu nehmen, um zu verstehen, warum Sie jQuery verwenden (diese Frage zu stellen, ist ein guter erster Schritt!) Und zu prüfen, wann dies erforderlich ist. jQuery kann gefährlich sein, einige der Hauptgefahren sind:

  • Codequalität - jQuery hat eine große Community und eine geringe Lernkurve. Dies ist ein perfekter Sturm für viele schlecht geschriebene Open-Source-Plugins.
  • Ineffizienz - jQuery lässt sich leicht ineffizient schreiben. Beispielsweise ist die Verwendung von jQuery's each anstelle von for-Schleifen nicht erforderlich und kann in einigen Fällen die Leistung beeinträchtigen. Viele gute Infos zu diesem Thema bei JSPerf
  • bloat - jQuery ist eine riesige Bibliothek. Meistens verwenden Sie eine kleine Teilmenge der Funktionen und greifen auf die gesamte Bibliothek zu. Es gibt einige großartige Alternativen, die Ihnen Teilmengen der Funktionen wie zepto.js und underscore.js bieten. Abhängig von Ihrer Situation können Sie einige Bytes einsparen, indem Sie die richtige Bibliothek für Ihre Anforderungen auswählen.

Letztendlich ist jQuery eine unglaublich nützliche und hilfreiche Bibliothek, wenn es richtig verwendet wird. Es ist jedoch keine Alternative zu Javascript. Es ist eine Bibliothek, genau wie zepto.js , YUI , Dojo , MooTools und Prototype - eine davon ist möglicherweise eine viel bessere Wahl für Ihr aktuelles Projekt.

Javascript ist eine missverstandene Sprache und wird von den meisten Menschen erst seit kurzem als mehr als eine Skriptsprache angesehen. Ich empfehle wirklich, mehr darüber zu lesen. Hier sind ein paar gute Einstiegspunkte:

Edit 07/2014 - Mir ist aufgefallen, dass dieser Beitrag immer noch Beachtung findet. Deshalb habe ich eine Reihe von Links hinzugefügt. Diese sind in keiner bestimmten Reihenfolge, sollten aber hilfreich sein.

  • Ben Almans Blog - viele gute Praktiken hier. Ich bin nicht mit allen einverstanden, aber ich lerne ständig neue Dinge aus seinem Blog.
  • Code Academy - Grundausbildung in Javascript und jQuery. Manchmal hilft es, zu den Grundlagen zurückzukehren.
  • Javascript Garden - ein Beitrag über die kniffligeren oder missverstandenen Funktionen von Javascript. Bitte lesen Sie dies von Zeit zu Zeit, bis alles Sinn macht.
  • Bocoup - das sind Trainingskurse. Wenn Sie in der Nähe eines sind, gehen Sie zu ihm. Viele der besten JS-Sprecher und Lehrer unterrichten diese.
  • Paul Irishs Blog - nicht ausschließlich JS, aber viele Best Practices werden hier beschrieben. Ihm und Bens Twitter-Feeds sind beide großartig zu folgen.
  • Javascript: The Good Parts - oft als "The Javascript Bible" bezeichnet - dieses Buch von Douglas Crockford ist ein erstaunlicher Ort, um Javascript zu verstehen.
  • Isaac Schlueters Blog - Isaac ist der Schöpfer von npm und arbeitet am Knotenkern. Er schreibt viel über die JavaScript-Community und nicht über Code-Konventionen, aber wenn Sie sich wirklich mit js beschäftigen, ist es eine großartige Lektüre.
  • Douglas Crockfords Javascript - Wenn Brendan Eich der Vater von Javascript ist, ist Douglas der ausgesprochene Onkel von Javascript. Er ist der Autor der JSON-Spezifikation, der Javascript-Bibel und vieler erstaunlicher Beiträge zu den Macken und dem kometenhaften Aufstieg von Javascript.
  • Brendan Eichs Blog - Brendan ist der Schöpfer von Javascript - er schreibt über alle möglichen albernen Dinge in seinem Blog, und obwohl er seine Fehler als Person hat, sind seine Javascript-Posts wertvoll.
  • James Hallidays (@substack) Blog - Substack ist wohl der wichtigste Entwickler von node.js in der Community - mit rund 400 (und täglich wachsenden) npm-Modulen und einer Leitphilosophie von winzigen, unixartigen Modulen ist alles, was er schreibt, wert lesen.
  • Max Ogdens Blog Max Ogden ist ein weiterer produktiver node.js-Autor und kann hervorragend Blog-Posts schreiben, die Ihnen etwas beibringen. Er ist auch der Autor (mit anderen glaube ich) von Javascript für Katzen.
  • Javascript für Katzen - Dies ist ein kurzes Tutorial, das Sie durch die Grundlagen von Javascript aus der Perspektive einer Katze führt. Wenn Sie ein Anfänger sind, lesen Sie dies durch. Es macht Spaß und lehrt in einer Stunde, wie viele Bücher Wochen brauchen, um zu kommunizieren.
  • Nicholas Zakas 'Blog Nicholas ist der Autor einiger fantastischer Javascript-Bücher: Objektorientierte Programmierung in Javascript , Verwaltbares Javascript , Professionelles Javascript für Webentwickler und Hochleistungs-Javascript . Er konzentriert sich hauptsächlich auf den Kunden, hat aber eine Menge Best Practices und Leistungstipps.
  • Guillermo Rauch's Blog - Guillermo ist ein weiterer produktiver node.js Entwickler, der hauptsächlich für Socket.io und Mongoose bekannt ist. Sein Blog (und sein neues Buch Smashing Node.js) sind großartige Ressourcen.

Ich bin mir sicher, dass es noch viel mehr großartige Ressourcen gibt, an die ich nicht denke oder die ich nicht kenne. Andere Antwortende können diese Liste gerne ergänzen.


3
+1 für die Bemerkung, dass JS nicht mehr nur eine clientseitige Sprache ist und wie JQuery in all dies passt.
Shivan Dragon

1
Beachten Sie, dass alle Funktionen Objekte sind, aber so ziemlich alles in JavaScript. $ ist besser beschrieben als eine Funktion mit daran $.ajaxangehefteten Eigenschaften auf "Klassenebene", z. B. ( ), die Wrapper-Objektmengen von dom-Elementen ausspuckt, um DOM-Methoden im Allgemeinen viel weniger zu einer PITA zu machen, indem sie prägnanter und methodenreicher gemacht werden Auto-Loop über Gruppen von Dom-Objekten, wann immer dies sinnvoll ist, und gemeinsame Nutzung einer vorhersehbaren API zwischen Browsern (was weniger ein Problem ist, IE <= 8).
Erik Reppen

1
Dies ist ein großartiger Beitrag, aber ich möchte mich mit einem Punkt auseinandersetzen - "Riesige Bibliothek ... benutze Zepto / Unterstrich" - Erstens ist Unterstrich eine völlig andere Art von Bibliothek - hauptsächlich für den Umgang mit Arrays / Objekten - plus Verwendung von LoDash Stattdessen ist es schneller. Zweitens ist Zepto kleiner, weil es nicht die Dinge abdeckt, die jQuery macht. Das könnte zu Fehlern führen, die jQuery behoben hätte. Schließlich ist jQuery NICHT mehr so ​​riesig / monolythisch, es ist ungefähr 30 KB groß, wenn es einmal gezippt wurde, und Sie können dies speichern, indem Sie 1 Bild weniger verwenden. Für mich ist die erzielte Entwicklungseffizienz diese Bytes wert.
LocalPCGuy

1
@LocalPCGuy auf jeden Fall einige gute Punkte. Dieser Beitrag war (genau!) Vor 2 Jahren, und seitdem hat sich im js-Ökosystem einiges getan. Zum Beispiel verwende ich persönlich browserify und kleine Module, anstatt überhaupt eine Bibliothek mit globalem Namensraum zu verwenden. Ich denke jedoch, dass die Grundvoraussetzung immer noch zutrifft, das heißt, dass für viele (die meisten?) Fälle eine Spülbeckenbibliothek selten erforderlich ist. Ich würde es den meisten Entwicklern empfehlen, um sicherzustellen, dass sie die Kosten für die Größe von Bibliotheken richtig begründen, bevor sie sich für die Verwendung entscheiden, nur weil es einfacher ist, genau zu bestimmen, was Sie benötigen.
Jesse

1
Reagiere auf all die Dinge, habe ich recht!?!?! / sarcasm - wie wäre es mit dem richtigen Werkzeug für den Job @Andy, und es ist nicht immer Reagieren. Ich denke, dass React einige gute Dinge tut, aber wir sollten nicht so tun, als wäre es ein Heilmittel für die JavaScript-Welt.
LocalPCGuy

17

Es gibt Vorteile, aber es ist fraglich, ob sie die Nachteile wirklich überwiegen.

Das wichtigste ist, dass Sie Bandbreite sparen und schnellere Antworten erhalten. jQuery fügt Ihrer Antwort weitere ~ 30 KB hinzu. In einigen Netzwerken (und in einigen Ländern) kann dies einige Millisekunden länger dauern. Auf der anderen Seite können Sie die Zwischenspeicherung jedoch auch ganz einfach über Ihren Webserver einrichten.

Zweitens benötigen Sie möglicherweise nur einige sehr einfache Funktionen, und das Herunterladen und Einrichten von jQuery kann mehr Zeit in Anspruch nehmen, als nur das zu implementieren, was Sie benötigen.

Und zum Schluss möchten Sie vielleicht Ihr eigenes Framework rollen, was meistens eine schlechte Idee ist, aber manche Leute haben ihre Gründe.

Wenn Sie jedoch jQuery verwerfen, nur weil Sie von der Lernkurve eingeschüchtert sind, sollten Sie es sich noch einmal überlegen. Zumal es so eher sanft ist.


Einverstanden, vor allem über den Bandbreitenteil. JQuery 1.8.2 hat 92 KB in der minimierten / verschleierten Version. Einverstanden ist auch, dass dies jedoch keine sehr starken Gründe sind, JQuery nicht zu nutzen. Vielen Dank!
Shivan Dragon

1
@ ShivanDragon: Du hast gzip vergessen. Das macht es viel kleiner.
ThiefMaster

@ ThiefMaster: Es ist wahr, danke für den Hinweis.
Shivan Dragon

10
Wenn Sie jQuery von CDNs (wie Google One) verwenden, ist die Wahrscheinlichkeit hoch, dass Benutzer es vorinstalliert haben, wenn sie andere Websites besuchen. Daher wäre die Auswirkung auf Ihre durchschnittliche (wenn auch nicht maximale) Antwortzeit geringer.
Xion

1
@Phil Warum benutzt du es überhaupt?!?! jQuery wurde und wird nie benötigt. Es ist das rein satanische Böse (zusammen mit dem Rest der dämonischen Bande: ReactJS, Underscore, LoDash, Modernizr, CommonJS, Angular, Google Analytics, insbesondere AMD usw.). Persönlich habe ich nie eine ganze Bibliothek aufgenommen (obwohl ich selten bestimmte Funktionen aus Bibliotheken extrahiert und optimiert habe, die ich brauche), ich werde nie eine ganze Bibliothek aufnehmen und fast jede Webseite, die ich erstelle, wird beim Einwählen ins Internet in weniger als 11 Frames geladen (1/59 Sekunde).
Jack Giffin

14

Soweit ich weiß, gibt es im Vergleich zu einer Bibliothek wie JQuery , MooTools usw. nur zwei Vorteile bei der Verwendung von Vanille-Javascript .

  • Bibliotheken haben eine Nutzlast, die die Bandbreite aufnimmt. Aber wie bereits in den anderen Antworten erwähnt, können Sie dies durch Gzipping und Caching begrenzen. Wenn Sie nur eine Teilmenge von jQuery benötigen, die Sie mit SizzleJS und mit MooTools ausführen können, können Sie die gewünschten Feature-Sets auf dieselbe Weise auswählen wie Modernizr .
  • Bibliotheken sind groß und brauchen einige Zeit zum Lernen. Andererseits ist dies eine einmalige Investition für Entwickler ... und es sieht in Ihrem Lebenslauf gut aus, Javascript-Bibliotheken zu kennen.
  • (BONUS) Bibliotheken sind keine Wunderwaffe. Wenn Sie also das Rad neu erfinden möchten, ist dies definitiv der richtige Weg.

Es ist erwähnenswert, warum Sie eine Javascript-Bibliothek verwenden möchten, für die es viele gibt:

  • Sie müssen kein eigenes Framework schreiben, um Ihre Entwicklung zu unterstützen. Wenn Sie neugierig sind, wie die Dinge funktionieren, können Sie sich den Code ansehen, da er Open Source ist.
  • Die Bibliotheken lösen die Browserkompatibilität. Sowohl DOM als auch Javascript weisen einige Unterschiede zwischen den Browsern auf. Vertrauen Sie mir, dies ist eine enorme Zeitersparnis, wenn Sie selbst Reparaturen hacken müssen.
  • Es ist de facto ein Internetstandard, Javascript-Bibliotheken zu verwenden. Die meisten von ihnen sind mittlerweile gut dokumentiert, und die meisten Webentwickler (die Javascript beherrschen) wissen, wie man sie verwendet.
  • Sie geben Javascript nicht wirklich auf, wenn Sie eine Bibliothek benutzen. Sie müssen immer noch Javascript mit seinen Typen, Objekten, der Funktionsweise von Verschlüssen usw. kennen.
  • Die meisten Bibliotheken sind modularisiert und es dauert nicht lange, Plugins zu schreiben oder die erforderlichen und das AMD-Muster zu verwenden .
  • Die Auswahl von CSS-Elementen aus dem DOM ist eine große Hilfe.
  • (BONUS) Sie können sie auch mit CoffeeScript verwenden .

Ich habe in einem Webshop gearbeitet, in dem Vanille-Javascript unerbittlich war, weil jQuery groß und beängstigend war. Diese Entscheidung, die größtenteils von einem einzigen "Javascript-Entwickler" beeinflusst wurde, war die Quelle vieler Browser-Bugs und die langsame Entwicklung und der Versuch, in seine Codebasis zu gelangen, war eine haarsträubende Erfahrung. Das Schreiben eines eigenen Frameworks scheint eine gute Idee zu sein, aber wenn Sie neue Entwickler einstellen möchten, können diese nicht schnell ein- und aushelfen. Dann ist da noch das Problem des Busfaktors zu berücksichtigen.

Wie gesagt, ich habe dort gearbeitet ... anderswo gab es grünere Weiden. : ^)


10

Ich vermische die Verwendung von beiden ziemlich viel. Der Hauptgrund dafür ist, dass Sie für einige Anwendungen (z. B. Chrome-Erweiterungen) keine browserübergreifende Unterstützung benötigen. Das bedeutet, dass ich neue Fortschritte wie CSS3 nutzen kann, die Ihren Code durch Übergänge gegenüber der Verwendung von JQuery erheblich vereinfachen können.

Auch mache ich oft etwas Brauches. Auf jeden Fall, wie die anderen sagten, sollten Sie das Rad nicht neu erfinden. Aber wenn Sie nach verrückten Funktionen gefragt werden, fällt es mir oft viel leichter, sie selbst zu schreiben, als ein JQuery-Plugin zu hacken, das nah beieinander liegt, aber nicht perfekt zusammenpasst.

Ich habe auch mit Entwicklern zusammengearbeitet, die nur mit jQuery arbeiten. Und ich muss sagen, dass sie bei der Funktionalität weitaus häufiger Kompromisse eingegangen sind, als wenn sie kein JQuery-Plugin gefunden hätten, das das getan hat, was sie wollten.

Irgendwann in der Webentwicklung werden Sie aufgefordert, etwas zu tun, das nicht in einer Bibliothek vorgefertigt ist. Stellen Sie an diesem Punkt sicher, dass Sie verstehen, wie die Basissprache wirklich funktioniert.

Also TLDC : Verwenden Sie beide, Sie sind im Nachteil, wenn Sie nur Vanille verwenden, und Sie sind im Nachteil, wenn Sie Vanille nicht von innen und außen kennen und darauf bestehen, immer jquery zu verwenden.


3
Reine Vanille ist der richtige Weg!
Marko

Wenig weiß Ryan, dass jQuery document.querySelectorAllhinter den Kulissen heimlich missbraucht .
Jack Giffin

6

Das einzige, was ich mir vorstellen kann, was Sie ohne JQuery nicht machen können, ist die Verwendung von JQuery-Plugins. Selbst dann könnten Sie Ihre eigene JS-Bibliothek schreiben, die genau das bietet, was das Plugin benötigt.

Stellen Sie sich das folgendermaßen vor: JQuery ist eine Open-Source-Javascript-Bibliothek, die in Javascript geschrieben ist. Sie können sich die Quelle ansehen und dabei lernen, wie Sie alles tun, was sie tut.

Sie können JQuery nicht ohne einfaches altes Javascript verwenden. Sie werden wahrscheinlich nicht verwenden document.getElementById, aber Sie werden weiterhin Funktionen und Variablen auf die standardmäßige Art und Weise von Javascript definieren. Sie könnten sogar eine Standardschleife schreiben for.

Der Hauptvorteil der Verwendung von JQuery ist derselbe wie bei jeder anderen Drittanbieter-Bibliothek in einer beliebigen Sprache: Sie müssen nicht so viel Code schreiben, um die für Ihre Anwendung spezifische Logik zu implementieren.

Lassen Sie sich von der Größe nicht abschrecken. Die CDN-Version ist ein ~ 33k-Download, der vom Browser des Benutzers nach dem ersten Seitenaufruf zwischengespeichert wird.


6

Wenn Sie sich Sorgen um die Leistung machen, sollten Sie versuchen, Vanille-Js zu verwenden, wann immer dies möglich ist. Frameworks erhöhen nicht nur den Bandbreitenaufwand, sondern auch den Verarbeitungsaufwand. Und jQuery bietet auch Browserkompatibilität für ziemlich alte Browser.

Wenn Sie an mobilen Apps oder Spielen (oder beidem zusammen) arbeiten, müssen Sie zuerst Leistung und Ressourceneffizienz erreichen.

jQuery und Plugins beschleunigen möglicherweise Ihre Entwicklung, aber insbesondere, wenn Sie sich auf jquery-Plugins von Drittanbietern verlassen, sollten Sie wissen, was diese tun. Viele von ihnen sind schlechte Beispiele für Codequalität und -effizienz.

jQuery kann 2- bis 10-mal langsamer sein als natives JavaScript. Und es kann Entwickler leicht ermutigen, ihre Benutzeroberfläche nicht richtig zu gestalten und sich zu sehr auf jQuery-Selektoren zu verlassen, die viel langsamer als native sind.


+1, ich bin damit einverstanden, dass Sie Spiele machen. Dies ist aus Performancegründen ein guter Grund, JQuery zugunsten von Vanilla JS fallen zu lassen. Dies gilt so ziemlich für die meisten Sprachen, wenn es darum geht, ein Spiel mit ihnen zu machen. Zum Beispiel empfehlen die Google-Leute in ihren Android-Dokumenten, nicht nur Bibliotheken beim Erstellen von Spielen außer Acht zu lassen (in Java für Android), sondern auch einige der guten Codierungspraktiken zugunsten der Geschwindigkeit außer Acht zu lassen.
Shivan Dragon

... wenn Sie so viel über effiziente DOM-Manipulation wissen wie die Leute, die jQuery schreiben, ja.
Erik Reppen

@ErikReppen, bitte untersuchen Sie tatsächlich den tatsächlichen Quellcode der "Leute, die jQuery schreiben". Ich war fast einen Monat lang geblendet von den Schrecken, die ich in den ersten 23 Zeilen gesehen habe.
Jack Giffin

Viel hat sich in JQ seit 2013 geändert.
Erik Reppen
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.