Wann sollte Vanilla JavaScript vs. jQuery verwendet werden?


238

Ich habe beim Überwachen / Beantworten allgemeiner jQuery-Fragen festgestellt, dass es bestimmte Praktiken gibt, bei denen Javascript anstelle von jQuery verwendet wird, sodass Sie tatsächlich weniger schreiben und ... genau die gleiche Menge tun können . Und kann auch Leistungsvorteile bringen.

Ein konkretes Beispiel

$(this) vs. this

Innerhalb eines Klickereignisses, das auf die ID der angeklickten Objekte verweist

jQuery

$(this).attr("id");

Javascript

this.id;

Gibt es andere gängige Praktiken wie diese? Wo bestimmte Javascript-Operationen einfacher ausgeführt werden könnten, ohne jQuery in den Mix aufzunehmen. Oder ist das ein seltener Fall? (einer jQuery "Verknüpfung", die tatsächlich mehr Code benötigt)

EDIT: Während ich die Antworten bezüglich der Leistung von jQuery im Vergleich zu einfacher Javascript-Leistung schätze, suche ich tatsächlich nach viel quantitativeren Antworten. Bei der Verwendung von jQuery sind Fälle, in denen es tatsächlich besser wäre (Lesbarkeit / Kompaktheit), einfaches Javascript anstelle von zu verwenden $(). Zusätzlich zu dem Beispiel, das ich in meiner ursprünglichen Frage gegeben habe.


Ich bin mir nicht sicher, ob ich die Frage verstehe. Haben Sie nach Meinungen zu den Vorzügen der Verwendung von Bibliothekscode gesucht, oder haben Sie nach zusätzlichen nicht jQuery-Cross-Browser-kompatiblen Techniken gesucht, die denen ähneln this.id?
user113716

1
Aus den Antworten geht hervor, dass jeder diese Frage als philosophisch ansieht, da ich beabsichtigte, dass sie sehr quantitativ ist, um fast eine Liste von Instanzen wie die von mir skizzierte zu erstellen, die übliche (Fehl-) Praktiken sind.
Jondavidjohn


Antworten:


207
  • this.id (wie du weißt)
  • this.value(Bei den meisten Eingabetypen. Ich kenne nur IE, wenn für seine Elemente <select>keine valueEigenschaften festgelegt <option>sind, oder Funkeingänge in Safari.)
  • this.className um eine ganze "Klasse" -Eigenschaft abzurufen oder festzulegen
  • this.selectedIndexgegen a <select>, um den ausgewählten Index zu erhalten
  • this.optionsgegen a <select>, um eine Liste der <option>Elemente zu erhalten
  • this.textgegen einen <option>, um seinen Textinhalt zu bekommen
  • this.rowsgegen ein <table>, um eine Sammlung von <tr>Elementen zu erhalten
  • this.cellsgegen a <tr>, um seine Zellen zu bekommen (td & th)
  • this.parentNode einen direkten Elternteil zu bekommen
  • this.checkedum den überprüften Status eines checkbox Thanks @Tim Down zu erhalten
  • this.selectedum den ausgewählten Status eines option Thanks @Tim Down zu erhalten
  • this.disabledum den deaktivierten Status eines input Thanks @Tim Down zu erhalten
  • this.readOnlyum den readOnly-Status eines input Thanks @Tim Down zu erhalten
  • this.hrefgegen ein <a>Element, um seine zu bekommenhref
  • this.hostnamegegen ein <a>Element, um die Domäne seiner zu erhaltenhref
  • this.pathnamegegen ein <a>Element, um den Weg seiner zu bekommenhref
  • this.searchgegen ein <a>Element, um den Querystring seiner zu bekommenhref
  • this.src gegen ein Element, bei dem es gültig ist, a zu haben src

... Ich denke du kommst auf die Idee.

Es wird Zeiten geben, in denen Leistung entscheidend ist. Wenn Sie beispielsweise mehrmals eine Schleife ausführen, möchten Sie möglicherweise jQuery loswerden.

Im Allgemeinen können Sie ersetzen:

$(el).attr('someName');

mit:

Oben war schlecht formuliert. getAttributeist kein Ersatz, ruft jedoch den Wert eines vom Server gesendeten Attributs ab und wird durch den entsprechenden Wert setAttributefestgelegt. In einigen Fällen notwendig.

Die folgenden Sätze deckten es irgendwie ab. Siehe diese Antwort für eine bessere Behandlung.

el.getAttribute('someName');

... um direkt auf ein Attribut zuzugreifen. Beachten Sie, dass Attribute nicht mit Eigenschaften identisch sind (obwohl sie sich manchmal gegenseitig spiegeln). Natürlich gibt es setAttributeauch.

Angenommen, Sie hatten eine Situation, in der Sie eine Seite erhalten haben, auf der Sie alle Tags eines bestimmten Typs auspacken müssen. Mit jQuery ist es kurz und einfach:

$('span').unwrap();  // unwrap all span elements

Wenn es jedoch viele gibt, möchten Sie möglicherweise eine kleine native DOM-API ausführen:

var spans = document.getElementsByTagName('span');

while( spans[0] ) {
    var parent = spans[0].parentNode;
    while( spans[0].firstChild ) {
        parent.insertBefore( spans[0].firstChild, spans[0]);
    }
    parent.removeChild( spans[0] );
}

Dieser Code ist ziemlich kurz, bietet eine bessere Leistung als die jQuery-Version und kann problemlos zu einer wiederverwendbaren Funktion in Ihrer persönlichen Bibliothek gemacht werden.

Es mag scheinen , als ob ich eine Endlosschleife mit dem äußeren habe whilewegen while(spans[0]), sondern weil wir mit einer „Live - Liste“ zu tun hat es aktualisiert wird , wenn wir das tun parent.removeChild(span[0]);. Dies ist eine ziemlich raffinierte Funktion, die wir verpassen, wenn wir stattdessen mit einem Array (oder einem Array-ähnlichen Objekt) arbeiten.


2
nett ... also dreht sich meistens alles darum, dass dieses Schlüsselwort unnötigerweise in ein jQuery-Objekt eingeschlossen wird.
Jondavidjohn

1
@jondavidjohn: Nun, es gibt einige Korrekturen, die in einigen Fällen hilfreich sind, z. B. this.valuewenn in bestimmten Fällen einige Browser-Macken auftreten. Es hängt alles von Ihren Bedürfnissen ab. Es gibt viele nette Techniken, die ohne jQuery einfach sind, besonders wenn die Leistung entscheidend ist. Ich werde versuchen, an mehr zu denken.
user113716

3
Ich wollte gerade eine Antwort schreiben, aber stattdessen werde ich Vorschläge für Ihre hinzufügen. Im Allgemeinen attr()wird massiv überbeansprucht. Wenn Sie nur mit einem Element arbeiten, brauchen Sie es selten attr(). Zwei meiner Favoriten sind die Verwirrung um die checkedEigenschaft von Kontrollkästchen (alle Arten von mystischen Beschwörungen um , dass man: $(this).attr("checked", "checked"), $(this).is(":checked")etc.) und in ähnlicher Weise die selectedEigenschaft der <option>Elemente.
Tim Down

1
Aaargh, @patrick, noooo: Sie haben empfohlen getAttribute(). Sie brauchen es fast nie : Es ist im IE kaputt, spiegelt nicht immer den aktuellen Status wider und es ist sowieso nicht das, was jQuery tut. Verwenden Sie einfach Eigenschaften. stackoverflow.com/questions/4456231/…
Tim Down

1
Ich habe JS so lange benutzt und wusste nichts über className, danke.
IAdapter

60

Die richtige Antwort lautet, dass Sie bei Verwendung von jQuery anstelle von "einfach altem" nativem JavaScript immer einen Leistungsverlust erleiden. Das liegt daran, dass jQuery eine JavaScript-Bibliothek ist. Es ist keine schicke neue Version von JavaScript.

Der Grund, warum jQuery leistungsstark ist, besteht darin, dass es einige Dinge macht, die in einer browserübergreifenden Situation übermäßig langwierig sind (AJAX ist eines der besten Beispiele), die Inkonsistenzen zwischen den unzähligen verfügbaren Browsern glättet und eine konsistente API bereitstellt. Es erleichtert auch leicht Konzepte wie Verketten, implizite Iteration usw., um das gemeinsame Arbeiten an Gruppen von Elementen zu vereinfachen.

Das Erlernen von jQuery ist kein Ersatz für das Erlernen von JavaScript. Sie sollten eine feste Basis in letzterem haben, damit Sie voll und ganz verstehen, was das Wissen um Ersteres für Sie einfacher macht.

- Bearbeitet, um Kommentare zu umfassen -

Da die Kommentare schnell darauf hinweisen (und ich stimme 100% zu), beziehen sich die obigen Aussagen auf den Benchmarking-Code. Eine "native" JavaScript-Lösung (vorausgesetzt, sie ist gut geschrieben) übertrifft eine jQuery-Lösung, die in fast allen Fällen dasselbe erreicht (ich würde gerne ein anderes Beispiel sehen). jQuery beschleunigt die Entwicklungszeit, was ein bedeutender Vorteil ist, den ich nicht herunterspielen möchte. Es ermöglicht einfach zu lesenden und leicht zu verfolgenden Code, der mehr ist, als manche Entwickler selbst erstellen können.

Meiner Meinung nach hängt die Antwort davon ab, was Sie erreichen wollen. Wenn Sie, wie ich aufgrund Ihres Hinweises auf Leistungsvorteile vermutet habe, die bestmögliche Geschwindigkeit für Ihre Anwendung erreichen möchten, führt die Verwendung von jQuery bei jedem Anruf zu einem Overhead $(). Wenn Sie Lesbarkeit, Konsistenz, browserübergreifende Kompatibilität usw. anstreben, gibt es sicherlich Gründe, jQuery gegenüber "nativem" JavaScript zu bevorzugen.


8
Ich würde gerne ein Beispiel für eine Situation sehen, in der jQuery eine Implementierung in reinem JS übertreffen kann. Egal was Sie tun, wenn Sie jQuery (oder eine andere Bibliothek) verwenden, haben Sie unvermeidbaren Funktionsaufwand. Es gibt keine Möglichkeit, dem (wenn auch geringen) Overhead durch Anrufe zu entkommen $(). Wenn Sie diesen Anruf nicht tätigen, sparen Sie Zeit.
GDDC

16
Eine schlecht geschriebene hausgemachte Lösung wäre wahrscheinlich langsamer. Das jQuery-Team hat im Paket hocheffizientes JavaScript ausgeführt. Siehe die Antwort von @ Freelancer.
Stephen

3
Eine schlecht geschriebene Lösung wird immer eine schlecht geschriebene Lösung sein, und das ist nicht die Schuld der Sprache. Es ändert nichts an der Tatsache, dass die Bibliothek Overhead verursacht, den eine "native" Funktion vermeiden könnte, wenn sie gut durchdacht ist.
GDDC

11
@gddc Ich denke, das beste Beispiel, bei dem jQuery "übertrifft" (außerhalb des Benchmark-Bereichs gelesen), ist die Verkürzung der Entwicklungszeit (das ist ein massiver geschäftlicher Wert) und die Vereinfachung des Experimentierens
Ben

13
Alles, was Sie geschrieben haben, ist wahr, aber Sie haben die obigen @ Ben-Notizen weggelassen. jQuery macht den Entwickler schneller und robuster. Sehen Sie sich diese KillClass () - Implementierung an , die ich vor vielen Jahren geschrieben und häufig verwendet habe. Weißt du was? Es ist für bestimmte Randfälle gebrochen . Schlechter Code ist schlechter Code, und falscher Code ist falscher Code. Bei Verwendung von jQuery schreibt der Entwickler jedoch häufig besseren und korrekteren Code. Meistens sind Computer schnell genug; Es sind Entwickler, die Hilfe brauchen.
Phrogz

38

Es gibt einen Rahmen namens ... oh weißt du was? Vanilla JS. Ich hoffe, Sie verstehen den Witz ...: D Es beeinträchtigt die Lesbarkeit des Codes für die Leistung ... Wenn Sie ihn mit dem folgenden vergleichen jQuery, können Sie feststellen, dass das Abrufen eines DOMElements mit IDfast 35-mal schneller ist. :) :)

Wenn Sie also Leistung wünschen, sollten Sie Vanilla JS ausprobieren und Ihre eigenen Schlussfolgerungen ziehen. Möglicherweise wird JavaScript bei intensivem Code wie in einer forSchleife nicht die Java-Benutzeroberfläche des Browsers hängen / den UI-Thread blockieren.

Vanilla JS ist ein schnelles, leichtes und plattformübergreifendes Framework zum Erstellen unglaublicher, leistungsstarker JavaScript-Anwendungen.

Auf ihrer Homepage gibt es einige perfekte Vergleiche:

Geben Sie hier die Bildbeschreibung ein


1
@ Leniel Macaferi Oh Mann, ich habe diese Antwort geliebt! Ich wusste nicht, dass die Leistung zwischen Vanille und anderen Frameworks einen solchen Unterschied machen kann! Wie auch immer, Hall of Fame für diese Antwort !! PS: Hast du auch die Website gemacht?
Steve

17

Es gibt bereits eine akzeptierte Antwort, aber ich glaube, dass keine direkt hier eingegebene Antwort in der Liste der nativen Javascript-Methoden / -Attribute, die praktisch die browserübergreifende Unterstützung garantiert haben, umfassend sein kann. Dafür darf ich Sie in den Quirksmode umleiten:

http://www.quirksmode.org/compatibility.html

Es ist vielleicht die umfassendste Liste dessen, was in welchem ​​Browser irgendwo funktioniert und was nicht. Achten Sie besonders auf den DOM-Bereich. Es ist viel zu lesen, aber es geht nicht darum, alles zu lesen, sondern es als Referenz zu verwenden.

Als ich anfing, ernsthaft Web-Apps zu schreiben, druckte ich alle DOM-Tabellen aus und hängte sie an die Wand, damit ich auf einen Blick weiß, was sicher zu verwenden ist und was Hacks erfordert. In diesen Tagen google ich einfach so etwas wie quirksmode parentNode compatibilitywenn ich Zweifel habe.

Wie alles andere ist das Urteil meistens eine Frage der Erfahrung. Ich würde Ihnen nicht wirklich empfehlen, die gesamte Site zu lesen und sich alle Probleme zu merken, um herauszufinden, wann Sie jQuery und wann Sie einfaches JS verwenden. Sei dir nur der Liste bewusst. Es ist einfach genug zu suchen. Mit der Zeit werden Sie einen Instinkt entwickeln, wann einfaches JS vorzuziehen ist.


PS: PPK (der Autor der Seite) hat auch ein sehr schönes Buch, das ich zum Lesen empfehle


14

Wann:

  1. Sie wissen, dass es eine unerschütterliche browserübergreifende Unterstützung für das gibt, was Sie tun, und
  2. Es ist nicht wesentlich mehr Code einzugeben, und
  3. es ist nicht wesentlich weniger lesbar und
  4. Sie sind ziemlich sicher, dass jQuery keine unterschiedlichen Implementierungen basierend auf dem Browser auswählt, um eine bessere Leistung zu erzielen. Dann:

Verwenden Sie JavaScript. Verwenden Sie andernfalls jQuery (wenn Sie können).

Bearbeiten : Diese Antwort gilt sowohl für die Verwendung von jQuery insgesamt als für das Auslassen, als auch für die Verwendung von Vanilla JS in jQuery. Wählen Sie zwischen attr('id')und .idlehnen Sie sich für JS, während Sie sich zwischen removeClass('foo')und .className = .className.replace( new Regexp("(?:^|\\s+)"+foo+"(?:\\s+|$)",'g'), '' )lehnen Sie sich für jQuery.


3
Ich denke, das OP beabsichtigt, jQuery zu verwenden, fragt sich jedoch, wo und wann natives JavaScript in seinen jQuery-Methoden verwendet werden soll.
Stephen

.classList.remove('foo')scheint in neueren Browsern
gut

3
@ Tyilo classList.remove ist Teil der HTML5 ClassList API, die nicht in IE9 implementiert ist, zum Beispiel caniuse.com/#feat=classlist
corbacho

13

Die Antworten anderer haben sich auf die allgemeine Frage "jQuery vs. plain JS" konzentriert. Nach Ihrem OP zu urteilen, haben Sie sich wohl nur gefragt, wann es besser ist, Vanilla JS zu verwenden, wenn Sie sich bereits für jQuery entschieden haben. Ihr Beispiel ist ein perfektes Beispiel dafür, wann Sie Vanilla JS verwenden sollten:

$(this).attr('id');

Ist sowohl langsamer als auch (meiner Meinung nach) weniger lesbar als:

this.id.

Es ist langsamer, weil Sie ein neues JS-Objekt hochfahren müssen, um das Attribut auf jQuery-Weise abzurufen. Wenn Sie jetzt $(this)andere Vorgänge ausführen möchten, speichern Sie das jQuery-Objekt auf jeden Fall in einer Variablen und arbeiten Sie damit. Ich bin jedoch auf viele Situationen gestoßen, in denen ich nur ein Attribut aus dem Element (wie idoder src) benötige .

Gibt es andere gängige Praktiken wie diese? Wo bestimmte Javascript-Operationen einfacher ausgeführt werden könnten, ohne jQuery in den Mix aufzunehmen. Oder ist das ein seltener Fall? (einer jQuery "Verknüpfung", die tatsächlich mehr Code benötigt)

Ich denke, der häufigste Fall ist der, den Sie in Ihrem Beitrag beschreiben. Personen, die sich $(this)unnötig in ein jQuery-Objekt einwickeln . Ich sehe das am häufigsten mit idund value(stattdessen mit $(this).val()).

Edit: Hier ist ein Artikel, der erklärt , warum jQuery im attr()Fall langsamer ist. Geständnis: hat es aus dem Tag-Wiki gestohlen, aber ich denke, es ist erwähnenswert für die Frage.

Erneut bearbeiten: Angesichts der Lesbarkeits- / Leistungsauswirkungen des direkten Zugriffs auf Attribute würde ich sagen, dass eine gute Faustregel wahrscheinlich darin besteht, zu versuchen, diese nach this.<attributename>Möglichkeit zu verwenden. Es gibt wahrscheinlich einige Fälle, in denen dies aufgrund von Browser-Inkonsistenzen nicht funktioniert, aber es ist wahrscheinlich besser, dies zuerst zu versuchen und auf jQuery zurückzugreifen, wenn es nicht funktioniert.


hah, danke fürs lesen der frage;) ... das ist also allgemein die ausnahme?
Jondavidjohn

@jondavidjohn: Ehrlich gesagt, ich zögere, diesen Anruf zu tätigen. Ich denke ja, es ist normalerweise zu Ihrem Vorteil, jQuery zu verwenden, da es sich um browserübergreifende Probleme handelt. Es gibt andere Beispiele wie this.style.display = 'none'. Ist das besser als $(this).hide()? Ich würde argumentieren, dass Letzteres besser lesbar ist, Ersteres jedoch wahrscheinlich schneller. Es tut nicht weh, selbst zu experimentieren, um festzustellen, ob bestimmte Aktionen in Browsern ohne jQuery funktionieren. Dies ist normalerweise der Fall, bevor ich ein Element in ein jQuery-Objekt einbinde, um eine Operation auszuführen.
Andrew Whitaker

10

Wenn Sie sich hauptsächlich um die Leistung sorgen, trifft Ihr Hauptbeispiel den Nagel auf den Kopf. Das unnötige oder redundante Aufrufen von jQuery ist meiner Meinung nach die zweite Hauptursache für langsame Leistung (die erste ist eine schlechte DOM-Durchquerung).

Es ist nicht wirklich ein Beispiel für das, wonach Sie suchen, aber ich sehe dies so oft, dass es erwähnt werden muss: Eine der besten Möglichkeiten, die Leistung Ihrer jQuery-Skripte zu beschleunigen, besteht darin, jQuery-Objekte zwischenzuspeichern und / oder Verkettungen zu verwenden:

// poor
$(this).animate({'opacity':'0'}, function() { $(this).remove(); });

// excellent
var element = $(this);
element.animate({'opacity':'0'}, function() { element.remove(); });

// poor
$('.something').load('url');
$('.something').show();

// excellent
var something = $('#container').children('p.something');
something.load('url').show();

interessant ... führt diese Trennung von Var-Instanziierung und Aktion tatsächlich zu Leistungssteigerungen bei der Verarbeitung? oder lässt die Aktion einfach alleine ausführen (was sie wohl weniger belastet ...)
jondavidjohn

1
Dies führt mit Sicherheit zu Leistungssteigerungen, jedoch nur, wenn Sie das ausgewählte Element wiederverwenden. Im letzten Fall var somethingmusste ich das jQuery-Objekt nicht wirklich zwischenspeichern (da ich die Verkettung verwendet habe), aber ich mache es trotzdem aus Gewohnheit.
Stephen

2
Nehmen Sie das gleiche Beispiel. Zweimaliges Aufrufen $('.something')bedeutet, dass jQuery das DOM zweimal durchlaufen muss, um nach allen Elementen mit diesem Selektor zu suchen.
Stephen

2
Im ersten Beispiel $(this)reduziert das Caching die Aufrufe der jQuery-Funktion. Dies gibt Ihnen den größten Gewinn in einem Schleifenszenario.
Stephen

2
@Alnitak Beachten Sie, dass elementgleich ist $(this). Das enthält nicht mehrere Elemente.
Stephen

8

Ich habe festgestellt, dass es sicherlich Überschneidungen zwischen JS und JQ gibt. Der Code, den Sie gezeigt haben, ist ein gutes Beispiel dafür. Ehrlich gesagt ist der beste Grund, JQ über JS zu verwenden, einfach die Browserkompatibilität. Ich neige immer zu JQ, auch wenn ich in JS etwas erreichen kann.


8
Es wäre ein Wunder, wenn es keine Überlappung gäbe, da JQuery JavaScript ist.
Simon

6

Dies ist meine persönliche Ansicht, aber da jQuery sowieso JavaScript ist, denke ich, dass es theoretisch nicht besser als Vanilla JS sein kann.

Praktisch kann es jedoch eine bessere Leistung als handgeschriebenes JS erbringen, da der handgeschriebene Code möglicherweise nicht so effizient ist wie jQuery.

Fazit: Für kleinere Dinge verwende ich eher Vanilla JS, für JS-intensive Projekte verwende ich gerne jQuery und erfinde das Rad nicht neu - es ist auch produktiver.


1
Es gibt viele Beispiele, bei denen Bibliotheken Vanilla JS übertreffen. Es stellt sich heraus, dass viele der integrierten Prototypmethoden von JS schlecht geschrieben sind.
Lernstatistiken am Beispiel

3

Die Liste der Live-Eigenschaften der ersten Antwort thisals DOM-Element ist vollständig.

Vielleicht finden Sie auch einige andere interessant.

Wenn dies das Dokument ist:

  • this.formsum eines HTMLCollectionder aktuellen Dokumentformulare zu erhalten,
  • this.anchorsum HTMLCollectionvon all dem HTMLAnchorElementsmit namegesetzt zu werden,
  • this.linksum HTMLCollectionvon allen HTMLAnchorElements mit hrefgesetzt zu werden,
  • this.imagesum HTMLCollectionvon allen HTMLImageElements zu bekommen
  • und das gleiche mit den veralteten Applets als this.applets

Wenn Sie mit arbeiten document.forms, erhalten Sie document.forms[formNameOrId]das so genannte oder identifizierte Formular.

Wenn dies ein Formular ist:

  • this[inputNameOrId] um das so genannte oder identifizierte Feld zu erhalten

Wenn dies ein Formularfeld ist:

  • this.type um den Feldtyp zu erhalten

Beim Erlernen von jQuery-Selektoren überspringen wir häufig das Erlernen bereits vorhandener HTML-Elementeigenschaften, auf die so schnell zugegriffen werden kann.


Die von Ihnen genannten Eigenschaften sind in der DOM Level 2-HTML-Spezifikation definiert und werden weitgehend unterstützt. document.embedsund document.pluginswerden auch weitgehend unterstützt (DOM 0). document.scriptsist auch eine praktische Sammlung, die in der HTML5-Spezifikation definiert und weitgehend unterstützt wird (und Firefox 9+ ).
Rob W

@Robw Die Liste könnte nun vollständig und definitiv nützlich und schnell sein. Danke;)
lib3d

2

Wie immer komme ich zu spät zu dieser Party.

Es war nicht die zusätzliche Funktionalität, die mich dazu bewogen hat, jQuery zu verwenden, so attraktiv das auch war. Schließlich hindert Sie nichts daran, eigene Funktionen zu schreiben.

Es war die Tatsache, dass beim Ändern des DOM so viele Tricks zu lernen waren, um Speicherlecks zu vermeiden (ich spreche von Ihrem IE). Eine zentrale Ressource zu haben, die all diese Probleme für mich bewältigte und von Leuten geschrieben wurde, die viel bessere JS-Codierer waren als ich, die ständig überprüft, überarbeitet und getestet wurden, war von Gott gesandt.

Ich denke, diese Art von fällt unter das Argument der browserübergreifenden Unterstützung / Abstraktion.

Und natürlich schließt jQuery die Verwendung von Straight JS nicht aus, wenn Sie es benötigen. Ich hatte immer das Gefühl, dass die beiden nahtlos zusammenarbeiten.

Wenn Ihr Browser von jQuery nicht unterstützt wird oder Sie eine Low-End-Umgebung (älteres Telefon?) Unterstützen, kann eine große .js-Datei möglicherweise ein Problem darstellen. Erinnerst du dich, als jQuery noch winzig war?

Normalerweise ist der Leistungsunterschied jedoch kein Problem. Es muss nur schnell genug sein. Da Gigahertz an CPU-Zyklen jede Sekunde verschwendet werden, geht es mir mehr um die Leistung meiner Codierer, der einzigen Entwicklungsressourcen, deren Leistung sich nicht alle 18 Monate verdoppelt.

Das heißt, ich beschäftige mich derzeit mit Barrierefreiheitsproblemen und anscheinend ist .innerHTML ein bisschen ein Nein Nein damit. jQuery hängt natürlich von .innerHTML ab, daher suche ich jetzt nach einem Framework, das von den etwas langwierigen Methoden abhängt, die zulässig sind. Und ich kann mir vorstellen, dass ein solches Framework langsamer als jQuery läuft, aber solange es gut genug funktioniert, bin ich glücklich.


2

Hier ist eine nicht technische Antwort: Viele Jobs erlauben möglicherweise bestimmte Bibliotheken nicht, z. B. jQuery.

Tatsächlich lässt Google jQuery in keinem seiner Codes zu (und auch nicht in React, da es Facebook gehört), was Sie möglicherweise erst gewusst haben, wenn der Interviewer sagt: "Entschuldigung, aber Sie können jQuery nicht verwenden, es ist nicht aktiviert." die genehmigte Liste bei der XYZ Corporation ". Vanilla JavaScript funktioniert absolut überall und jedes Mal und wird Ihnen dieses Problem niemals bereiten. Wenn Sie sich auf eine Bibliothek verlassen, erhalten Sie zwar Geschwindigkeit und Leichtigkeit, aber Sie verlieren die Universalität.

Apropos Interview: Der andere Nachteil ist, dass Sie, wenn Sie sagen, dass Sie eine Bibliothek verwenden müssen, um ein JavaScript-Problem während eines Code-Quiz zu lösen, das Problem nicht wirklich verstehen, was irgendwie schlecht aussieht. Wenn Sie es dagegen in rohem Vanille-JavaScript lösen, zeigt es, dass Sie tatsächlich jeden Teil des Problems verstehen und lösen können, das sie vor Ihnen werfen.


1

$(this)ist anders als this:

Durch die Verwendung stellen $(this)Sie sicher, dass der jQuery-Prototyp an das Objekt übergeben wird.

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.