it-swarm-eu.dev

Welche Vorteile bietet die native JavaScript-Entwicklung?

Wenn man bedenkt, wie viel einfacher die Entwicklung von jQuery im Vergleich zu nativem JavaScript ist, warum verzichten die Leute dann ganz auf Bibliotheken wie jQuery?

Liegt das daran, dass jQuery Einschränkungen aufweist oder langsam ist? Ich meine, wenn jQuery im Vergleich zu nativem Javascript so einfach ist, aus welchen Gründen müssen die Leute immer noch reines Javascript verwenden?

33
Mike

Reden wir über Autos.

Oh, warte, wir haben es schon getan - erinnerst du dich an die Zeit, als wir uns vor einiger Zeit getroffen haben? Wir haben über Autos gesprochen. Tatsächlich schienen Sie ein Experte für Autos zu sein. Sie konnten detailliert erklären, was richtig, falsch und aufregend am neuesten Formel-1-Rennen ist. Sie kannten alle Lamborghini-Modelle auswendig, einschließlich Preis und Verfügbarkeit. Sie hatten sogar Gedanken daran, Ihr eigenes zu kaufen Ferrari 599 GTB Fiorano und haben dafür gespart (ich wette, das Steak-Dinner hat nicht viel geholfen).

Während Sie die Fehler von Toyota mit einer großartigen, aufgeregten Stimme erklärten, sprangen Sie plötzlich von Ihrem Stuhl und schrien in die Luft. Sie schwenkten die Fäuste: "Verdammt, ich bin ein großartiger Experte für alles, was mit Autos zu tun hat! Ich ' Ich werde Automechaniker! "

Und so bist du gegangen. Sie hatten ein Interview, der Boss war genauso beeindruckt wie ich von Ihrem Wissen und Sie wurden eingestellt. Der erste Kunde kam herein. Seine Kupplung war kaputt. Sie haben es inspiziert und wussten nicht, was Sie tun sollten. Tatsächlich hatten Sie absolut keine Ahnung, wie Sie den Ratschlägen des Boss-Mannes folgen sollten. Du wurdest gefeuert.

Aber wie könnte das sein? Sie wissen alles über Autos! Außer ... alles über Autos. Sie können sehr gut wissen, dass Ihr Traumauto einen V12-Motor hat, aber Sie wissen nicht, was das eigentlich bedeutet.

Sie sind also wirklich kein Automechaniker - Sie sind ein Autoliebhaber. Und bis Sie lernen, wie Autos funktionieren , bleiben Sie ein Enthusiast.

Jetzt lass mich dich fragen. Wie funktioniert $.fn.text? Und was ist mit $.fn? Was meinen sie wirklich? Wie gibt $(something) ein gigantisches Ding zurück, das Dinge enthält, und was genau ist das Ding? Können Sie ihre Funktionalität zumindest theoretisch sogar ein wenig replizieren? Können Sie ohne jQuery auskommen?

Zu sagen, dass "natives JavaScript schwer ist", ist einfach ... falsch. In erster Linie, weil JavaScript als Sprache nichts mit dem DOM zu tun hat, was hauptsächlich jQuery abstrahiert. Zweitens, denn sobald Sie etwas über das DOM gelernt haben, können Sie bereits die häufigsten browserübergreifenden Fehler beheben. Aber nur ein kleines Geheimnis - zunächst ist alles schwer. Lange Teilung war eine Hündin in der 5. Klasse.

Als zweite Analogie für diese Antwort gilt: jQuery bezieht sich auf JavaScript-DOM (nicht auf JavaScript, sondern nur auf DOM) wie Array.prototype.forEach Auf for. Es funktioniert in 99% der Fälle. Und es funktioniert gut. Aber für diese 1%, die nicht abgedeckt sind, müssen Sie wissen, wie man die for -Schleife verwendet, wenn auch nur, um praktisch zu sein . Diese gesamte Antwort basiert auf der "reineren" Seite der Frage und nicht einmal auf der technischen Seite (zum Beispiel der Größe der Bibliothek und einigen anderen Dingen, wie in Michael Dorrants Antwort erläutert). Weil ich JavaScript liebe und wenn die Leute es einfach beiseite zu werfen scheinen und "pah, diese dummen Javascriptianer" sagen und ausgefallene weiße Handschuhe schwenken, kommt es auf die Moral an.

Wenn Sie akzeptieren können, dass Sie immer ein JavaScript-Enthusiast sind, wer bin ich dann, um Sie aufzuhalten? Wenn Sie jedoch ein JavaScript-Programmierer sein möchten, müssen Sie zunächst über das Wissen verfügen, um mindestens zwischen zwischen der Verwendung von jQuery (oder einer anderen Bibliothek) und nicht zu wählen mit einer Bibliothek. Lerne das DOM. Erfahren Sie, wie man es benutzt. Schreiben Sie Ihre eigene kleine Bibliothek oder nur eine Sammlung von Hilfsfunktionen. Und sobald Sie sich mit dem DOM auskennen und sich für jQuery - godspeed entscheiden. Faulheit wird für diejenigen vergeben, die hart gearbeitet haben.

89
Zirak

Gründe, die ich kenne:

  1. Wenn der Bedarf extrem gering ist, sagen wir 1 Klick.

  2. Wenn die Download-Geschwindigkeit kritisch ist und die jQuery-Bibliothek zu groß ist UND Sie nicht viel (benutzerdefinierten) Code schreiben müssen, um ihn zu ersetzen.

  3. Bei der Integration mit anderen Technologien ist manchmal Raw Js besser.

  4. Bei der Arbeit an einem Legacy-System (auch bekannt als "Produktion"), das bereits in js mit etablierten Mustern geschrieben wurde.

12
Michael Durrant

jQuery ist einfach ein Framework - eine Reihe von Tools, die in JavaScript geschrieben sind. Mit diesen Tools verwenden Sie weiterhin JavaScript. Einige Leute bevorzugen es, JavaScript mit den von jQuery bereitgestellten Tools zu schreiben, andere entscheiden sich dagegen, andere entscheiden sich für andere Tools.

Einige Gründe, warum Sie "reines" JavaScript ohne jQuery schreiben möchten:

  • Seiten werden schneller geladen, ohne zusätzliche jQuery-Dateien einzuschließen
  • Einige Frameworks sind möglicherweise nicht mit jQuery kompatibel
  • Der geschriebene Code macht nichts, bei dem jQuery hilft
  • Der Code wird für andere geschrieben, und das Erfordernis von jQuery als Abhängigkeit würde das Teilen erschweren
  • Der Code-Autor möchte mehr Kontrolle als jQuery bietet
7
user41718

jQuery fügt wie jede Bibliothek oder jedes Framework ein weiteres Bugs of Layer hinzu. Ich liebe es, aber ich habe auch einen Tag verloren, als ich nach einem Fehler gesucht habe, der sich im jQuery-Kern und nicht in meinem Code befand (eine seltene Gelegenheit, aber nicht so selten).

Ansonsten finde ich keinen anderen Grund, es nicht zu benutzen:

  • Der Overhead ist minimal, insbesondere wenn Sie mit gehostete Google-Version ,
  • Es hilft weniger erfahrenen Javascript-Entwicklern, saubereren und effizienteren Code zu schreiben.
  • Es ist meistens plattformübergreifend, was lebensrettend sein kann, wenn Sie mit älteren Browsern arbeiten müssen.
  • Die riesige Galerie von Plugins hilft mir, in sehr kurzer Zeit Prototypen zu schreiben.
  • Das DOM macht Sinn,
  • bla bla bla ...

ABER es sollte niemals als Ersatz für Javascript-Kenntnisse verwendet werden. Wenn Sie nicht wissen, wie man es in reinem Javascript macht, können Sie zunächst mit einer Bibliothek davonkommen, aber auf lange Sicht werden Sie dafür bezahlen.

Und natürlich gibt es alle von uns, die seit einigen Jahren im tödlichen Kampf mit IE6 gefangen sind und unsere Tricks der alten Schule nicht einfach zugunsten eines glänzenden loslassen neues Spielzeug.

5
yannis

In der Browserumgebung benötigen Sie ein browserübergreifendes Normalisierungstool. Ein solches Werkzeug gibt es in zwei Varianten

  • wraps Host-Objekte mit neuen Objekten, die sich in allen Browsern gleich verhalten
  • erweitern Sie Host-Objekte, um die DOM-API zu implementieren.

Im Allgemeinen können Sie diese Dienstprogramme auf drei Arten verwenden

  • verwenden Sie kleine Funktionen wie addClass oder setText im gesamten Code, wann und wo Sie sie benötigen
  • schreiben Sie Ihre eigene browserübergreifende Normalisierungsbibliothek
  • verwenden Sie eine vorhandene.

Sie benötigen einen Normalisierungsmechanismus, andernfalls erhalten Sie keine Cross-Cross-Browser-Unterstützung.

Die Verwendung eines vorhandenen ist in Ordnung. Ich würde jQuery einfach nicht verwenden. Persönlich schreibe ich gerade meine eigene Bibliothek ( DOM-shim es repariert Browser, ohne eine fremde Propietory-API verfügbar zu machen. Es verwandelt Ihre Browser in einen einzigen gut benommenen standardisierten Browser).

5
Raynos

Wenn Sie keine DOM-Abstraktion, browserübergreifende und ältere Browserunterstützung benötigen, können Sie problemlos auf jQuery verzichten.

Dies ist der Fall, wenn Sie Browser-Erweiterungen, Greasemonkey-Skripte (manchmal), Zahlenverarbeitung, Entwicklung für Node.js oder andere Nicht-Browser-Umgebungen entwickeln.

3
c69

Ich muss meiner Antwort eine offene Ehrlichkeit voranstellen. Ich liebe jQuery. Es macht mein Leben massiv einfacher und macht JavaScript-Code deklarativer, so wie ich glaube, dass die Dinge funktionieren sollten.

jQuery macht viele Dinge…

Ja Sie können Plugins hinzufügen
Ja Sie können Selektoren erweitern
Ja vereinfacht die Animation

aber jQuery macht nicht alles

Haben Sie jemals versucht, mit jQuery in mehreren Fensterkontexten zu arbeiten? jQuery nervt beim Umgang mit verschiedenen Fensterkontexten, weil es den ursprünglichen Kontext window und document aus dem Fenster beibehält, in dem Es wurde genannt.

Ich habe hier und da Code geschrieben, um Popouts * zu erstellen, und jQuery kann einfach das behindern, was ich erreichen möchte. Das Hinzufügen eines neuen Verweises auf jQuery im untergeordneten Fenster kann die Situation häufig verschlimmern, indem es schwieriger wird, festzustellen, welcher jQuery-Kontext verwendet wird.

* Denken Sie an das Popout von Google Mail, um eine E-Mail in einem neuen Fenster zu verfassen, nicht an Spam-Werbung

Verwenden Sie es, wenn es den Code einfacher macht

Die Zeit für die Verwendung von jQuery ist, wenn Sie Ihren Code einfacher, kürzer, lesbarer und schneller machen können.

Die Zeit für nicht die Verwendung von jQuery ist, wenn dadurch Ihr Code nicht einfacher, kürzer, lesbarer oder schneller wird. Wenn Sie die Ladezeiten optimieren müssen, möchten Sie jQuery möglicherweise aufgrund des Ereignisaufwands nicht verwenden.

2
zzzzBov

Wie Sie wissen, ist jQuery ein Allzweck-Framework, das viele Methoden bereitstellt, die viele von uns in ihren Projekten nicht verwenden. (Einige davon habe ich überhaupt nicht benutzt.)

Es gibt zwei Hauptgründe, warum jQuery oder andere gut etablierte Frameworks nicht verwendet werden.

1. Das Projekt ist nicht groß oder komplex genug, um ein solches Framework zu verwenden : In diesem Fall trifft der Codierer eine fundierte Entscheidung auf der Grundlage seiner Erfahrung und seines Wissens in JavaScript. Dies hilft ihm, das Seitengewicht zu reduzieren und den Code besser zu kontrollieren.

2. Der Codierer entwickelt sein eigenes Framework Ich habe in meinem Unternehmen ein Projekt gesehen, das über ein eigenes JavaScript-Framework verfügt. Der Grund, den sie zitieren, ist, dass sie bis zur nächsten Version warten müssen, wenn sie jQuery verwenden und es einen Fehler gibt, den sie beheben können. Wenn eine Funktion hinzugefügt werden soll, müssen sie das jQuery-Team danach fragen oder ein Plugin hinzufügen, obwohl es keine gute Idee ist, es zu einem Plugin zu machen (sie gaben das Beispiel, einen .live Ähnliches in ihrem Framework, noch bevor es offiziell zu JQuery hinzugefügt wurde). Mit Ihrem eigenen Framework haben Sie mehr Kontrolle über den Code. Der Nachteil ist, dass Sie das Rad in Bezug auf Browserkompatibilitätsprobleme usw. neu erfinden müssen. Wenn der Entwicklungsprozess nicht gut ist, wird Ihr Framework aufgebläht und verlängert nur die Zeit für die Wartung.

2
Shree

Zusammen mit den anderen Antworten hier, insbesondere Michael Durrants , würde ich sehen, dass Geschwindigkeit ein Hauptgrund für mich ist, gelegentlich zu verwenden rohes JavaScript.

In letzter Zeit habe ich an vielen Animationen oder anderen CPU-intensiven Aufgaben gearbeitet und manchmal ist rohes JavaScript viel, viel schneller als wenn ich jQuery durchlaufe.

Ein Beispiel ist, wo ich die Deckkraft eines position: fixed - Elements in Bezug darauf ändern wollte, wie weit ein Benutzer auf einer Seite gescrollt hat. Der Effekt war viel zu langsam, als ich dafür jQuery verwendete, was dazu führte, dass das Scrollen ruckelte und der Überblendungseffekt ruiniert wurde. Ich wechselte zu reinem JavaScript und alles war bis auf IE <= 8) seidig glatt.

2
donut

Mike

Ich denke, die Leute, die sich gegen die Verwendung einiger Bibliotheken absichern, sind auf die Abhängigkeit von dieser Infrastruktur/Bibliothekslösung zurückzuführen, um bestimmte Aufgaben auszuführen.

Aber denken wir daran, dass Sprachen auf lange Sicht wie Bibliotheken kommen und gehen.

Vielleicht ist es also zeitlicher Umfang. Vielleicht zögern die Leute, in eine Bibliothek zu investieren, die vielleicht nicht da ist - oder auf lange Sicht genauso viel Schwung dahinter haben.

Mich selber? Ich habe keine Einwände gegen die Verwendung von JQuery. Ich schaue auch auf Box2d.js oder three.js und würde sie viel lieber annehmen, selbst wenn sie kurzfristig haltbar sind, als zu verpassen, welche Früchte sie zu bieten haben.

Unter dem Strich besteht für Mike ein Risiko für die Haltbarkeit einer Bibliothek, die Sie auswählen, und ich denke, einige Mitglieder der Javascript-Community haben möglicherweise Verluste aufgrund des Endes einer Bibliothek oder eines Projekts erlitten und haben gerade gesagt - nie wieder.

0
Tim Miltz

Ich kann zwei weitere Gründe hinzufügen, die nicht erwähnt wurden:

  1. Wenn ich oft brandneue Technologien aufgreife, beginne ich mit Konstrukten auf niedrigerer Ebene, bevor ich zu Konstrukten auf höherer Ebene gehe. Ich bin hauptsächlich ein C++/C # -Entwickler, aber vor einiger Zeit, als ich anfing, mit HTML/CSS/JavaScript herumzuspielen, entschied ich mich, kein Framework zu verwenden, weil ich zuerst die Technologie (dh das JavaScript) verstehen wollte Sprache selbst), auf der diese Frameworks aufbauen.

    • Trotzdem habe ich seitdem jQuery entdeckt und möchte nie wieder von Hand codieren, was jQuery in 1-2 Codezeilen für Sie tun kann.
  2. Ich weiß nicht, wie häufig dies vorkommt, aber für mich scheint es eine Menge Leute zu geben, die, wenn sie das nächste Framework/die nächste Technologie/Sprache sehen, ihre erste Antwort lautet: "Keine andere API, die ich lernen kann!" Es ist ihnen egal, wie einfach jQuery ist, aber sie sehen es einfach so, als stünde es ihnen im Weg und liefert Arbeit mit ihren "wahren und erprobten" Methoden. Dies ist dieselbe Kategorie von Personen, die sich weigern, die Boost-Bibliothek oder eine der STL zu verwenden und weiterhin malloc für fast alles. Sie haben gefragt, warum sie reines JavaScript über jQuery auswählen, und in Wirklichkeit haben sie sich nie entschieden, weil sie sich die meiste Zeit überhaupt geweigert haben, jQuery zu bewerten, und mit ihrem aktuellen Entwicklungstempo vollkommen zufrieden sind, egal wie langsam es ist.

0
DXM

Ich würde sagen, das Hauptproblem ist, dass immer mehr Menschen (die überwiegende Mehrheit?) Nicht mehr wissen, wie man in JavaScript codiert. Wenn jQuery etwas nicht kann, können sie es nicht.

Es kommt zu dem Punkt, dass einfache Javascript-Beispiele immer schwerer zu bekommen sind. Nichts gegen jQuery; Es ist ein großartiger Rahmen. Ich habe viele gute Ideen daraus, aber die Leute sollten zuerst JavaScript lernen und dann ein Framework lernen. Ich persönlich finde mein eigenes Framework flexibler und passt besser zu meinen Anforderungen, und ja, ich erfinde das Rad manchmal neu, aber die vollständige Kontrolle und Kontrolle über Fehlerkorrekturen ist ein großer Vorteil, vorausgesetzt, Sie sind bereit, die Arbeit in das Erlernen von JavaScript zu stecken.

Nicht nur das. Wenn Sie Vanilla JavaScript kennen, macht es viel mehr Spaß, herumzuspielen und mit den neueren Funktionen zu experimentieren, anstatt auf eine Framework-basierte Implementierung zu warten. Ich beschuldige jQuery auch nicht dafür, da es sich hauptsächlich um eine DOM Bibliothek handelt, aber es kann schwierig sein, sie bei großen Projekten zu skalieren. Andere Frameworks leisten hier bessere Arbeit. Prototyp fällt mir ein.

Kurz gesagt, es ist ein großartiger Rahmen, aber nicht das A und O, das die Leute ausmachen.