In einer der jüngeren ShopTalk-Episoden kam die Frage nach der Verwendung von jQuery in Tutorials auf.
In letzter Zeit habe ich bemerkt, wie verschwommen die Grenze zwischen jQuery und JavaScript beim Erlernen der Sprache geworden ist. Es ist schwer, ein gutes Tutorial zu finden, das nicht jQuery anstelle von JavaScript verwendet. Was ist deine Meinung zur übermäßigen Verwendung der Bibliothek?
Die Frage stammte von Nick Hehr, der auch darüber geschrieben hat. Unsere Antwort kannst du dort über diesen Zeitstempel-Link anhören.
Wenn du diese Seite schon länger liest, weißt du, dass wir uns in dieser Hinsicht etwas schuldig gemacht haben. Ich bin mir nicht sicher, ob hier jemals ein Tutorial veröffentlicht wurde, das nur "Vanilla" JavaScript (also JavaScript pur, ohne Framework) anstelle von jQuery verwendet hat. Oder wenn, dann sind es nur sehr wenige. Ist das schlimm? Ich bin mir nicht so sicher, ob es das ist. Aber es ist auf jeden Fall eine Diskussion wert.
Etwas später habe ich einen Artikel veröffentlicht, in dem es darum ging, wie man Text nach einem Ereignis austauscht. Ich habe fünf Möglichkeiten vorgestellt, dies zu tun. jQuery wurde in zwei davon verwendet, "Vanilla" JavaScript in einer anderen und CSS für die beiden anderen. Die Verwendung von jQuery, selbst unter anderen Optionen, entfachte eine Diskussion im Stil von „Das ist doch total übertrieben“.
Ah, hilfreich, aber jQuery ist hier wirklich nicht nötig: Swapping Out Text, Five Different Ways – https://#/5gyFGmoCVp
— Smashing Magazine (@smashingmag) 3. Juli 2013
Hier ist meine Meinung dazu.
Ich schreibe, was ich tue
Dieser Blog ist eine Reflexion der Dinge, die ich lerne. Ich verwende jQuery oft. Wenn ich also Dinge in ein Tutorial übersetze, mache ich es so, wie ich es selbst tun würde.
Ich habe in den letzten vielen Jahren nur an einer Handvoll Websites gearbeitet, die kein jQuery verwendet haben, und diejenigen, die es nicht taten, verwendeten eine andere Bibliothek oder brauchten überhaupt kein JavaScript.
jQuery ist JavaScript
Wörtlich. Die Verwendung von jQuery bedeutet immer noch, wörtlich JavaScript zu schreiben und damit zu arbeiten. jQuery macht es nur einfacher und senkt die Einstiegshürde. Ich kenne viele gute JavaScript-Entwickler, die mit jQuery angefangen haben. Genauso wie es viele gute Gitarristen gibt, die als Coverband einer Dave Matthews Band Coverband angefangen haben.
Tutorials sind Konzepte
Das Ziel eines Tutorials ist es, eine Idee zu vermitteln und dies ziemlich prägnant zu tun.
Angenommen, du möchtest eine Schaltfläche mit einem bestimmten Klassennamen auswählen und beim Anklicken den Text ändern. Um Abhängigkeiten zu vermeiden, könntest du document.querySelectorAll(".my-button") verwenden. Aber das gibt ein Array zurück, also musst du am Ende [0] verwenden, um das Element anzusprechen und das Ereignis anzuhängen. Oder sollten wir stattdessen querySelector verwenden, das das erste Element auswählt? Oder sollten wir eine Schleife laufen lassen oder über das Array mappen, um alle zu binden? Oder sollten wir getElementByClassName verwenden? Wie sieht es mit der Browserunterstützung aus? Sollen wir über Polyfills dafür sprechen? Oder sollten wir einfach eine ID hinzufügen und getElementById verwenden, da dies wahrscheinlich eine Best Practice ist?
Oder wir könnten einfach $(".my-button") machen und mit dem Tutorial fortfahren. All diese Dinge sind interessant und diskutierenswert, aber nicht in jedem einzelnen Tutorial jedes Mal. jQuery ermöglicht es den Konzepten in Tutorials, zu glänzen, ohne sich in Details zu verlieren.
Die Zukunft
Im Moment habe ich das Gefühl, dass jQuery immer noch ein ziemlich wichtiger Bestandteil des Front-End-Stacks ist, es sich lohnt, es zu lernen, und es immer noch angemessen ist, es in Tutorials zu verwenden.
Aber die Dinge werden sich im Web ändern. Wie JavaScript in Tutorials präsentiert wird, wird sich ebenfalls ändern. Wahrscheinlich. Wir werden uns damit ändern. Wahrscheinlich. Ich habe in den letzten Monaten Kommentare gesehen wie „Ich habe das Gefühl, wenn ich jQuery benutze, habe ich etwas falsch gemacht“, was ich noch nie zuvor gehört habe und ein Vorbote des Wandels sein könnte. Die „Newschool“-Ansätze von Ember/Angular stehen ebenfalls bevor.
Hört, hört! Mach einfach weiter, sage ich. Du hast absolut recht.
Chris, jeder deiner Beiträge ist wichtig für mich. Mach weiter so. Gott segne dich.
jQuery ist eine gut gepflegte und gut dokumentierte Bibliothek. Rücksichtslose Ablehnung um der „JavaScript-Reinheit“ willen ist meiner Meinung nach dumm. Tatsache ist, wenn du jQuery nicht verwendest, ist die Wahrscheinlichkeit groß, dass du jQuery in deiner eigenen Bibliothek neu schreibst.
Was die Zukunft von JavaScript als MVC-Frameworks betrifft, so sind diese in jeder Hinsicht kein Ersatz für jQuery. Als Entwickler müssen wir vorsichtig auf die „neue heiße Sache“ reagieren.
Ich stimme völlig nicht zu. Schau dir meinen Kommentar unten an (sobald ich ihn fertig geschrieben habe).
Meiner Meinung nach hat die jQuery API die effizienteste Art der Arbeit mit dem DOM etabliert. Ich liebe JavaScript, aber es wäre nicht dasselbe ohne jQuery oder eine ähnliche API wie Zepto. Browser bieten endlich ähnlichere Methoden, wie querySelectorAll, aber was machen wir dann mit diesen abgefragten Elementen? Wir wissen, dass Event-Binding und Element-Manipulation mit jQuery effizient zu programmieren und browserübergreifend kompatibel sind, daher wäre Regressionstesting an dieser Stelle Zeitverschwendung. Solange mir niemand eine API zeigen kann, die genauso einfach zu erlernen ist und eine prägnantere Syntax hat, bin ich nicht interessiert :)… wenn es nicht kaputt ist…
Für mich ist jQuery eine großartige Möglichkeit, schnell voranzukommen und zu testen, ob ein Konzept funktioniert. Danach kann es untersucht werden, um es zu verbessern, zu verfeinern und umzugestalten, aber um einen Commit zu speichern, ist jQuery immer noch eine gültige Option.
Wenn du nur jQuery kennst, möge Gott deiner Seele gnädig sein, wenn (nicht ob) du an einem Projekt arbeitest, das es nicht verwendet, und du solltest zu demselben Gott beten, dass du nicht in meinem Entwicklungsteam bist, wenn (nicht ob) es passiert.
Hallo Scott - Mit Verlaub, angesichts des desaströsen Zustands der Front-End-Webentwicklung (jQuery hin oder her) bist du hier (und unten) etwas überheblich.
Ich habe deinen Lebenslauf überprüft, und es sieht so aus, als ob die minivegas-Seite sowohl jQuery als auch WordPress verwendet. Eine andere sagt, dass man ein iPad braucht, um diese Seite zu erleben (verwendet aber auch jQuery). Eine dritte verwendet jQuery und Modernizr (eine weitere Abstraktion über JS).
Du hast also einiges zu erklären, und ich würde dir respektvoll vorschlagen, nicht so überheblich mit Meinungen aufzutreten, denen du anscheinend selbst nicht wirklich zustimmst :-)
Dieser Kommentar ist respektvoll gemeint, und nimm ihn bitte konstruktiv auf.
Danke!
@ Scott Kosman
Coole Story, Bro…
Als Neuling (ich glaube, ich werde manchmal für immer ein Neuling sein) ist es ein Kampf, Vanilla-JS-Tutorials zu finden. Einerseits ist es in Ordnung, wenn mir ein jQuery-Tutorial zeigt, wie ich etwas erreichen kann, und ich nehme es an, aber andererseits war es ein Kampf, nicht einer dieser Entwickler zu werden, die jQuery kennen, aber JavaScript nicht wirklich beherrschen. Ich muss mich extra anstrengen, um Artikel zu finden, die kein jQuery verwenden. Stack Overflow-Fragen scheinen immer jQuery-Antworten zu haben, selbst wenn die Frage des Fragestellers ausdrücklich nach reinem JS fragt. Mein Standpunkt ist also: Ich finde es in Ordnung, dass du jQuery in deinen Tutorials verwendest, aber ich denke, die Branche als Ganzes braucht mehr gute, qualitativ hochwertige, detaillierte, fortgeschrittene Vanilla-JS-Lernressourcen.
Die „OMG BENUTZE DOCH EINFACH JQUERY“-Crowd auf Stack Overflow macht mich wahnsinnig. Gelegentlich mache ich eine Downvoting-Sperre, wenn jemand genau das tut, was du beschrieben hast: eine jQuery-basierte Antwort geben, obwohl nicht danach gefragt wurde.
Und was das betrifft: „Ich denke, die Branche als Ganzes braucht mehr gute, qualitativ hochwertige, detaillierte, fortgeschrittene Vanilla-JS-Lernressourcen“, kann ich nur sagen: JA JA, LIEBER HERR IM HIMMEL, DU HAST MICH BEI HALLO GEHABT JA. Orte wie Stack Overflow (trotz meines letzten Absatzes) und MDN und dergleichen sind großartige Ressourcen, aber was die Branche (meiner Meinung nach) wirklich braucht, ist eine gute Ressource „Hier erfährst du, wie du gängige jQuery-Aufgaben ohne jQuery erledigst“. Es gab einen großartigen Einführungsartikel dazu bei netttuts Anfang 2012, aber wir brauchen definitiv mehr davon.
Vielleicht sollte ich einen Blog starten.
@Scott Kosman Ich stimme vollkommen zu (mit deinem Kommentar oben und der Antwort hier). Scrolle nach unten, um meinen Mini-Rant-aber-wirklich-wahrhaftig-ehrlichen-Problem-aufgeblähten Beitrag zu lesen.
Ein weiterer Neuling hier. Mein Plan ist es, Vanilla JS so gründlich wie möglich zu lernen, während ich gleichzeitig JQuery lerne. Ich werde praktische und funktionierende Kenntnisse in Vanilla JS haben, ABER ich werde wahrscheinlich die meiste Zeit JQuery verwenden. Es ist einfach so viel einfacher.
Zu deinen Bedenken bezüglich der Suche nach JS-Artikeln: Ich weiß nicht, wie es dir geht, aber ich liebe Bücher. Es gibt VIELE Vanilla-JS-Tutorial-Bücher, die sehr fortgeschritten sein können. Ich sehe kein Problem darin, JS-Ressourcen zu finden, wenn man am richtigen Ort sucht.
Ich stimme Scott zu, Stack Overflow wird verrückt, wenn es darum geht, auf jQuery zurückzugreifen, wenn nicht danach gefragt wurde. Normalerweise stört es mich nicht, aber oft suche ich nach einer Vanilla-Methode für Konzepte, die ich nicht regelmäßig verwende, und stattdessen bekomme ich einen Vorschlag für eine jQuery-Erweiterung. Ich mag jQuery sehr – es sollte definitiv in Tutorials verwendet werden, wenn Kürze geschätzt wird – aber Projekte von jQuery-Erweiterungen abhängig zu machen, stört mich aus irgendeinem Grund. Ich mag Erweiterungen außer jQueryUI nicht wirklich. (Und tatsächlich finde ich jQueryUI oft mühsam und schreibe stattdessen meine eigenen UI-Funktionen.) Die Verwendung einer Unmenge von Erweiterungen fühlt sich an, als würde man ein Auto mit Komponenten aus verschiedenen Teilen der Welt mit unterschiedlicher Dokumentation in verschiedenen Sprachen bauen… UND diese Komponenten können in nur zwei Jahren veraltet sein. Es ist einfach unordentlich.
Ian, wenn du nach einem GROSSARTIGEN Tutorial-Set suchst, schau dir JavaScript for Professional Web Developers von Nicholas Zakas an. Es ist eine 10 und alles, was du brauchst, um vom Neuling zum mäßig Fortgeschrittenen zu werden.
http://www.wrox.com/WileyCDA/WroxTitle/Professional-JavaScript-for-Web-Developers-3rd-Edition.productCd-1118222199.html
Ich bin schuldig, hauptsächlich weil ich jQuery einfach finde und alles in Vanilla JavaScript ewig gedauert hat.
Allerdings scheint es verrückt, eine ganze Bibliothek einzubinden, nur um etwas zu erreichen, das leicht in JavaScript erledigt werden kann.
Ich denke, das Problem heute ist, wann die Leute anfangen, JavaScript zu lernen. Wenn jemand beschließt, JavaScript zu lernen, wird er Bücher kaufen, zum Beispiel „Javascript the definite guide“, das einige jQuery-Kapitel enthält. Er wird Fragen auf Stack Overflow stellen, und selbst wenn er einfache Fragen stellt wie: „Wie schalte ich eine CSS-Klasse um?“, werden die Leute mit jQuery antworten.
Ich persönlich denke, dass man zuerst JavaScript lernen sollte, Vererbungsumfang, Best Practices usw. verstehen sollte… dann auf jQuery „upgraden“, da es die Dinge beschleunigt, aber die Denkweise ist bereits geschaffen. Ich habe oft Leute gesehen, die Folgendes tun:
$(‘#divId’).each(…)
obwohl man, wenn man ein wenig JavaScript (oder HTML) wüsste, wüsste, dass es auf einer Seite nicht mehr als ein Div mit derselben ID geben kann.
Es scheint, dass jQuery irgendwie zu einer völlig parallelen Sprache wird, anstatt einer „on-top“-Sprache im Vergleich zu JavaScript, es ist einfacher zu verwenden und funktioniert in jedem Browser. Es würde mich nicht wundern, wenn Browserhersteller in naher Zukunft jQuery-Routinen in ihren Engines optimieren würden.
Nun, jQuery war das „JavaScript“, das ich zuerst gelernt habe, aber je tiefer ich in die Materie eindrang, desto mehr habe ich auch auf reines JS geachtet. jQuery zu verwenden, ist einfach, es einfach und ohne Probleme zu erledigen.
Die Punkte, die du anführst, sind in Ordnung, aber es gibt immer noch viel Raum für die „Sag NEIN zu jQuery-Kampagne!“. Bevor ich weitermache, lasst mich klarstellen: jQuery ist großartig. Ich werde es verwenden, wenn ich es brauche, und es ist großartig für diejenigen, die JavaScript verstehen und ein wenig zusätzliche Hilfe benötigen.
Das bringt uns wirklich zu deinem zweiten Punkt: jQuery ist JavaScript. Genau. Warum sollten also Leute, die nicht wissen, wie man JavaScript verwendet, jQuery verwenden? Ich sage nicht, dass du (Chris) nicht weißt, wie man JavaScript verwendet, ich sage, dass es einige von den unzähligen Leuten gibt, die deinen Blog lesen, die es nicht wissen. Dies wird zu einem großen Problem, wenn Neulinge anfangen, nach Dingen wie dem von dir verlinkten Artikel zu suchen, oder in Videos wie diesem, wo jQuery einfach nur eingefügt wird, um Text (was!?) an die Seite anzuhängen. Schließlich werden Leser anfangen, jQuery einfach deshalb einzubinden, weil sie an eine falsche, umgekehrte Überzeugung glauben, wie „JavaScript ist jQuery.“
Nun, die Vorstellung, dass „JavaScript jQuery ist“ (anstatt „jQuery JavaScript ist“), kann nicht allzu schädlich werden (abgesehen von offenkundiger Unkenntnis wichtiger Prinzipien, die Nur-jQuery-Benutzer nicht lernen werden), bis die Leute tatsächlich anfangen, ihr eigenes jQuery zu schreiben, anstatt einfach Copy-and-Paste zu machen. Man könnte sich das Ergebnis dieser Katastrophe nur vorstellen: hässlicher, schrecklicher, absolut zum Kotzen erregender Code. Dies steigert sich zu Benutzern, die denken, sie wüssten JavaScript (weil
JavaScript ist jQuery) in die Community kommen, schlechte Angewohnheiten verbreiten und um Hilfe bitten bezüglich „besserer Programmierpraktiken“, „Code-Optimierung“ und „OMG WARUM FUNKTIONIERT DAS NICHT!?“…Hier kommt der Aufschrei über „das Rad neu erfinden“ und „eine ganz neue JavaScript
FrameworkBibliothek schreiben (verstanden richtig!)“ Um ehrlich zu sein, werden solche Angriffe jedoch selbst bei den einfachsten Dingen geschrien, wie dem Anhängen von Text oder dem Entfernen eines Elements. Wenn ich eine Animation brauche, verwende ich manchmal CSS3, manchmal schreibe ich einen 5-zeiligen Code (Wirklich! Es braucht nicht viel mehr als 5 Zeilen), und hey, manchmal binde ich jQuery ein. Wenn es um die Produktion geht, solange du weißt, was du tust, kannst du es tun. Die Einbindung von jQuery ist nicht einmal so schädlich, wenn es nur um die HTTP-Anforderung geht, weil es so oft gecacht wird. Das größte Problem sind diejenigen von uns, die nicht wissen, wie man JavaScript verwendet, mit der willigen Einstellung, dass „JavaScript jQuery ist.“(Das soll nicht heißen, dass ich deinen Blog nicht liebe und ihn jeden Tag auf neue Artikel, Links oder Videos überprüfe… FYI)
Was ist falsch daran, „um Hilfe bezüglich ‚besserer Programmierpraktiken‘, ‚Code-Optimierung‘“ zu bitten?
Schau, Menschen haben unterschiedliche Lernstile, wenn es um, nun ja… alles geht. Ich werde mein persönliches Beispiel unten lassen. Nach dem, was ich aus deinem Kommentar entnommen habe, habe ich etwas falsch gemacht. Denk einfach daran, dass Lernen durch Wissen gepaart mit Übung/Erfahrung geschieht, und durch Übung/Erfahrung gibt es Erfolg und Misserfolg. Das Schöne daran, so etwas wie das Web zu lernen, ist, dass es völlig offen ist.
Damals, als MySpace angesagt und cool war, sah ich eines Tages, dass jemand anderes einen Link gepostet hatte, der nicht all diesen verrückten „https://www…“-Müll enthielt, sondern der Link war der eigentliche Titel der Seite in ihrem Beitrag. Ich fragte mich: „Kann ich das auch?“. Ich suchte bei Google und stieß auf ein Code-Snippet für
<a href="http://yoururlhere">Your Link Title Here</a>. Ich hatte keine Ahnung, was „a href“ war. Ich kopierte/fügte es ein (gasp!) und es funktionierte großartig (lauteres gasp!).Am nächsten Tag wollte ich einen weiteren Link posten. Und am nächsten Tag, und am nächsten… schließlich sagte ich mir: „Was macht dieses ‚a href‘?“ Ich googelte mehr und fand es heraus. In der nächsten Woche versuchte ich, es von Hand zu schreiben, anstatt zu kopieren/einzufügen. Und es schlug fehl. Also ging ich zurück, kopierte/fügte ein, verglich und fand es heraus.
Das hat mich inspiriert. Diese dumme, scheiternde soziale Website, die wie Geocities auf Crack aussah, und mein Copy/Paste-Lernen inspirierten mich dazu, mehr über das Programmieren des Webs zu lernen. Heute habe ich einen Vollzeitjob, in dem ich das Web programmiere, und ich lerne immer noch, genau wie jeder andere auch.
Bitte diktiere keine Lernstile oder Ansätze. Und bitte, um Himmels willen, entmutige keine Schüler, die um Hilfe bitten.
Vielleicht war ich nicht klar genug. Hilfe ist großartig. Fragen sind besser. Neugier ist fantastisch. Was nicht gut ist, ist, wenn Leute um Hilfe und Fragen bitten, wenn die Ressourcen direkt vor ihnen liegen. Wenn du nicht farbenblind bist, solltest du nicht fragen müssen, welcher Ball rot und welcher weiß ist. jQuery fördert dieses Verhalten.
Entschuldige auch den doppelten Beitrag, aber Fragen bezüglich besserer Programmierung/Optimierung in der jQuery-Kategorie stammen normalerweise von kopiertem & eingefügtem Code aus dem Internet, der übermäßig komplizierte Dinge tut, während Benutzer, die diese Fragen stellen, nicht einmal einen Cent über das wissen, wonach sie fragen (ganz zu schweigen von dem Sandkorn, das sie in die Recherche gesteckt haben).
Ressourcen zum Erlernen der Thermodynamik sind verfügbar… soll ich also nie Fragen stellen, wenn Ressourcen verfügbar sind? Und warum kann eine Frage/Antwort keine Ressource sein? Du diktierst, wieder einmal, einen Lernansatz. Nicht jeder lernt durch Lesen von W3C- oder ECMAScript-Spezifikationen oder api.jquery.com. Einige lernen durch Coaching, einige durch Lesen, einige durch Zuhören, einige durch Sehen, einige lernen sogar durch Kopieren zuerst.
Entweder war ich immer noch nicht klar genug oder du verdrehst meine Worte absichtlich. Nimm den Taschenrechner-Ansatz: Eine Seite wie wolframalpha.com zu verwenden, ist in Ordnung. Einen TI Inspire-Taschenrechner zu verwenden, ist in Ordnung. Einen Taschenrechner zu verwenden, ist in Ordnung. Aber wann wird es zu viel? Wenn du Taschenrechner für Dinge verwendest, die du nicht weißt, wie man sie macht, und fragst, warum etwas nicht so funktioniert, wie du es möchtest. Das klingt etwas weit hergeholt, aber lies weiter.
Sagen wir, ich möchte grundlegende Multiplikationsfunktionen auf einem Taschenrechner verwenden. Ich tippe so etwas wie
10/0ein, weil ich unendlich möchte, nur um herauszufinden, dass die Division von 10 durch 0 einen Fehler ergibt.. was!?Ich denke, wenn wir alle dies in einen Taschenrechner eingeben würden, ohne zu wissen, wie man dividiert, wären wir alle ziemlich verwirrt. Als ich das erste Mal davon erfuhr, stand jedoch ein Lehrer direkt vor mir und lehrte mich, wie man dividiert. Du musst lernen, wie man dividiert, bevor du fragst, warum eine Division so funktioniert, wie sie es tut. Lehrer sind in Ordnung – sogar großartig. Deshalb müssen wir von ihnen lernen. Wenn wir nur Taschenrechner verwenden würden, wüssten wir nicht, wie man dividiert, wir wüssten nicht, was die Fehler sind, und wir könnten keine Taschenrechner und Unterrichtspläne für zukünftige Generationen erstellen.
Was ist mit dem Sprechen? Wir lernen kein richtiges Englisch (oder was auch immer deine Muttersprache sein mag), bevor wir lernen zu sprechen. Und doch werden wir zu produktiven Sprechern, nur weil wir die um uns herum nachahmen, ohne jemals zu wissen, was wir sagen. Ja, wir lernen Grammatik, aber erst nach Jahren des Sprechens.
Dein Ansatz mag für dich richtig sein, aber für andere kann er hinderlich sein. Es kann zu einer Ausrede werden, nie etwas zu bauen, weil man vielleicht nicht „genug gelernt“ hat. Ich persönlich bin für alles, was die Einstiegshürde für jeden senkt, der neugierig auf das Programmieren ist. Es fördert Kreativität und Interesse in einem wachsenden Bereich. Und ja, es wird Leute geben, die Fehler machen, und glücklicherweise haben wir eine reiche Gemeinschaft von Entwicklern, die helfen, Leute in die richtige Richtung zu lenken.
Deine Perspektive ist interessant. Bevor ich etwas anderes sage, möchte ich klarstellen, dass ich nicht versuche, Menschen daran zu hindern oder zu verhindern, so zu lernen, wie sie wollen.
Was das Sprechen betrifft, hast du recht. Wir lernen in Segmenten, Wörtern, Gemurmel und Schreien zu sprechen, aber das ist die natürliche Reihenfolge. So wie wir JavaScript lernen. Wir lernen nicht zu sprechen, indem wir Poesie, oder SMS-Abkürzungen, oder Romane schreiben… Am Ende schaffen wir unsere eigene Art von Sprache durch die Art, wie wir sprechen (d.h. wir sprechen alle unterschiedlich, so wie wir alle unterschiedliche Programmierweisen haben).
Nun zum Lernaspekt. In der Vergangenheit habe ich Tausenden bei der Programmierung in Foren, Q&A-Seiten und Chatrooms geholfen. Meiner Erfahrung nach verstehen die Leute erst, wenn sie es buchstäblich verstehen. Es gab Hilfe-Vampire, die wiederholt dieselbe Frage stellen (und du kannst sicher sein, dass diese Frage in den Dutzenden Male, in denen sie gestellt wurde, beantwortet wurde), indem sie Frameworks wie jQuery verwenden. Aber dann gab es auch diejenigen mit echten Lernabsichten. Sie fangen mit einer ziemlich nervigen Hilfe-Vampir-artigen Frage an und nehmen dann Vorschläge an. Ich habe buchstäblich gesehen, wie ihre Avatare (man kann keine Augen in einem Chatroom sehen) aufleuchten, sobald sie verstehen, warum eine jQuery-Funktion so funktioniert, wie sie es tut, und sie verstehen es erst nach einem einfachen Durchgang durch die Vanilla-Spur.
Ich hoffe, das ergibt Sinn.
Ich würde sagen, JQuery ist eher wie Slang, nicht Poesie. Es wird vieles nicht gesagt. Und wir lernen Slang, bevor wir „richtiges“ Englisch lernen. Es ist effizienter zu verwenden und zu kommunizieren, und solange der Kontext stimmt, ist es die bevorzugte Sprechweise. Es lässt dich vielleicht nicht klug aussehen, aber es erledigt die Arbeit.
Ich müsste „jQuery ist eher wie Slang“ widersprechen. Nehmen wir jedoch diesen Ansatz, um dennoch zu beweisen, warum jQuery nicht für einfache Dinge verwendet werden sollte. Sagen wir, Mr. Smith unterrichtet die Klasse über Verben und Substantive. Ich bezweifle, dass er einen Satz wie „Ich LOL’d beim heutigen vorgestellten Beitrag, omg.“ nehmen würde. Er würde einen grammatikalisch korrekten Satz wählen, damit die Schüler zuerst verstehen, was ein Verb ist. Danach könnte er dann das als Verb (oder Verbphrase) verwendete „LOL’d“ einfügen, um zu zeigen, wie Elemente ausgetauscht werden können.
Also, laut deiner Analogie: jQuery = LOL.
Meiner Meinung nach ist ein Teil eines erfolgreichen Blogartikels, insbesondere wenn wir über Code diskutieren, das Tutorial auf eine Weise anzubieten, die für die größte Anzahl von Lesern zugänglich ist. Rohes JavaScript hat sicherlich seinen Platz… aber wenn jQuery schnell zur bevorzugten Bibliothek wird, nun… warum SOLLTE man nicht zeigen, wie der Code in jQuery aussieht?
Wird es in manchen Fällen übertrieben sein? Sicher. Wenn ich in meinem Projekt bereits jQuery verwende, neige ich jedoch eher dazu, weiterhin jQuery-Syntax zu verwenden, wo immer möglich, damit mein Code konsistent ist. Wird meine Seite einen Leistungseinbruch erleiden? Das hängt wohl vom Code ab, und dann ist die Frage, ob dieser Einbruch signifikant genug ist, um eine Änderung des Codes zu rechtfertigen?
Es gibt ein gewisses Maß an Elitismus und Spott bei bestimmten Argumenten wie „jQuery ist hierfür nicht notwendig“. Am Ende des Tages gibt es kein Projekt, bei dem jQuery NOTWENDIG ist. Bei jQuery geht es darum, deinen Prozess zu vereinfachen und dir eine gute Grundlage für die Arbeit zu geben (denn wer will das Rad neu erfinden?), nicht darum, dir auf magische Weise etwas anzubieten, was du vorher nicht mit einfachem JavaScript hättest tun können.
Ich stimme zu, der Elitismus ist weit verbreitet.
Du machst das gut mit deinen Tutorials. Ich folge der 80/20-Regel. Bei 80 % der Projekte muss lediglich die browserübergreifende Arbeit erledigt werden, sodass Entwickler jQuery oder eine andere Bibliothek verwenden können, um ihre Arbeit zu erleichtern. Die restlichen 20 % sind Projekte, bei denen natives JavaScript tatsächlich gerechtfertigt ist.
Wie in einem deiner anderen Artikel erwähnt, kannst du, sobald die Welt aufhört, IE9 und darunter zu verwenden, mehr Wert auf die nativen Methoden, Eigenschaften und Objekte von W3C und HTML5 legen, aber bis dahin haben jQuery und seinesgleichen immer noch ihren Platz in der Entwicklungswelt.
Ich finde die Web-Community interessant… Einerseits sagen die coolen Web-Kids, man solle einen CSS-Präprozessor verwenden… das macht das Schreiben von CSS einfacher… und bringt einen davon weg, „reines CSS“ zu schreiben… und dann sagt dieselbe Community… verwende kein jQuery, obwohl es das Schreiben von JavaScript einfacher macht, und schreibe stattdessen reines JavaScript… echte Entwickler würden niemals jQuery verwenden…
Ich verwende jQuery, weil es das Schreiben von JavaScript einfacher macht… Es eliminiert viele der browserübergreifenden Probleme, sodass ich mich auf die Logik meines Codes konzentrieren kann… Ich kann Dinge tun wie Elemente nach Klassennamen auswählen und Klassen mit wenigen Codezeichen umschalten… vielleicht ist es Millisekunden langsamer als reines JavaScript, aber für Website-Arbeiten… was ich mache, ist es in Ordnung…
Chris… bitte verwende weiterhin jQuery in deinen Tutorials… mir persönlich gefällt das Aussehen von jQuery-Code im Vergleich zum sehr wortreichen Aussehen von reinem JavaScript-Code…
Ich stimme dir zu 100% zu, und ich verwende jQuery in fast allen meinen Projekten, aber CSS-Präprozessoren sind anders. Sie kompilieren zu reinem CSS, BEVOR sie auf den Server gepusht werden. Das bedeutet überhaupt keinen Leistungseinbruch.
Wenn jQuery zu direktem JS kompilieren würde und wir das auf den Server pushen würden, dann wäre es ein fairer Vergleich. Tatsächlich, wenn jemand da draußen nach einem tollen neuen Tool sucht, das er entwickeln kann, bitteschön für diese kostenlose Idee. ;)
@Josh – Ich denke, das ist ein ausgezeichneter Punkt zu den Endresultat-Unterschieden, obwohl es Michaels Punkt, dass Präprozessoren nicht unbedingt als reines CSS ANFANGEN, ein wenig abtut, so dass jemand, der mit dem Schreiben von CSS über einen Präprozessor begonnen hat, ähnliche logistische Probleme haben könnte wie jQuery -> JavaScript. Das offensichtlichste Problem für mich wäre die Annahme, dass reines CSS verschachtelte Elemente zulässt (&:before, etc)
Eine Frage, die ich habe… und vielleicht ist es wirklich nur „Kommt darauf an…“ wäre, wie viel Leistungseinbuße jQuery wirklich im Vergleich zu reinem JavaScript verursacht? Reden wir über Millisekunden Verarbeitungszeit? Ist es signifikant genug, um zu sagen „Ja, JavaScript sollte hier wirklich verwendet werden“ oder ist es mehr „Ich bevorzuge…“
Ich nutze die Zeit, die ich durch die Wiederverwendung von Code spare, um andere Dinge zu tun, zum Beispiel Spaß zu haben. Prost!
In einer Welt, in der Kunden Einhörner als Webdesigner verlangen, schätze ich jemanden, der eine T-förmige Spezialisierung im Front-End-Design beibehält. Wenn ich mehr über die Nuancen des Schreibens in Javascript im Vergleich zu JQuery erfahren wollte, würde ich zu jquery-tricks.com oder javascript-tricks.com gehen; aber das tue ich nicht. Ich möchte im Moment verdammt gut in CSS3 und HTML5 sein. Also, Chris, mach weiter so.
@Jeremy: Du hättest letzte Woche meinen Vortrag zu diesem Thema halten sollen (Speaker-Deck-Folien).
Das ist definitiv ein heißes Thema im Moment. Es lässt sich nicht leugnen, dass jQuery großartig ist und das Leben von Front-End-Entwicklern in den letzten 6, 7… 9 (wie auch immer) Jahren einfacher gemacht hat. Aber die meisten Kopfschmerzen aufgrund von Browserunterstützung, die zu dieser Zeit entscheidend waren, sind heute weit weniger problematisch.
jQuery zu lernen, weil es einfacher als JavaScript ist, ist der falsche Ansatz. Das bedeutet nicht, dass die Verwendung von jQuery falsch ist, aber die Werkzeuge, die du verwendest, nicht zu verstehen, wird zu vielen unerwarteten Problemen führen.
fasst es für mich zusammen.
Für Tutorials würde ich lieber jQuery (oder jede andere Bibliothek) freie Optionen sehen – es sei denn, das, was du erreichen willst, wäre ohne einfach unzumutbar.
Schöne Folien.
Es gibt nichts „Vanille“ an der DOM API, es ist eine Bibliothek wie jede andere, außer dass sie standardmäßig in den gängigsten JavaScript-Laufzeiten enthalten ist, nämlich denen in Webbrowsern. Die Verwechslung der DOM API mit der JavaScript-Sprache ist nicht korrekter als die Verwechslung von JavaScript mit der jQuery API. Es ist nur so, dass die erstere Verwechslung die ältere ist und sich daher natürlicher anfühlt.
Die Besonderheiten der clientseitigen Entwicklung scheinen einige JS-Entwickler dazu zu bringen, Bibliotheken und Frameworks mit einem Misstrauen zu behandeln, das bei serverseitiger Programmierung oder anderen traditionelleren Arten der Entwicklung nicht oft zu finden ist. Die Wahrheit ist, dass all dein Code, selbst wenn du Assembly-Sprachbefehle schreibst, die direkt auf einer CPU ausgeführt werden sollen, immer noch eine Abstraktion über einer tieferen Komplexität ist, und bei moderner Anwendungsprogrammierung arbeitest du immer mit APIs, die APIs umschließen, die APIs umschließen. Ob diese APIs von der Laufzeit oder von einer Drittanbieterkomponente bereitgestellt werden, sollte keine Rolle spielen. Was wichtig ist: Funktionieren sie? Helfen sie dir, ein Problem zu lösen? Sind sie gut dokumentiert und unterstützt?
Die meisten serverseitigen Entwickler nehmen problemlos ein Dutzend oder mehr Abhängigkeiten von Bibliotheken und Frameworks in Kauf, die bei der HTTP-Verarbeitung, dem Content Management, der Datenserialisierung, der Persistenz, der Codierung usw. helfen. Sollten PHP-, C#- und Java-Entwickler, die bis über beide Ohren in den Abstraktionen eines gewählten Web-Frameworks stecken, diese ablegen, um rohe Sockets zu bearbeiten, weil es irgendwie „vanillefarbener“ ist? Nein, das wäre Wahnsinn.
Wenn du jQuery nicht brauchst, verwende es auf keinen Fall. Wenn du einen messbaren, wichtigen Leistungsgewinn erzielst, indem du es nicht verwendest, dann verwende es nicht. Aber opfere dich nicht für eine bedeutungslose Vorstellung von Programmierreinheit, indem du eine API ablehnst, um eine schlechtere zu verwenden. Gute Software auszuliefern ist schon schwer genug. Nutze jeden Framework, jede Komponente und jede Bibliothek sinnvoll, die dir das Leben leichter machen und dein Produkt besser machen kann.
Es ist eine unerhörte Behauptung, einfach zu sagen, dass das Schreiben von Vanilla JS von Natur aus besser für die Leistung ist. Versuche, eine Selector-Engine zu schreiben, die SizzleJs (jQuerys Selector-Engine) übertrifft und keine riesige Zeitverschwendung ist.
Ich stimme dir vollkommen zu – ich wollte das nicht als Antwort schreiben :(
+1000
@Cp Man, Sizzle überhaupt zu verwenden, kann Zeitverschwendung sein!
In 99% der Fälle kannst du Elemente ohne CSS3 auswählen (sag mir nicht, dass du wirklich diese erweiterte
:not()-Syntax brauchst…), und für den Rest… musst du diese wahrscheinlich nicht einmal auswählen! Oder du kannst es schneller mit einfachen Javascript-Iterationen tun.Nun, wie auch immer, du kannst dich auf Sizzle verlassen. Aber du kannst Sizzle auch alleine verwenden, ohne jQuery :) Ich habe es getan, um einen Polyfill für IE7 (für
querySelectorAll) und IE8 (fürmatchesSelector) bereitzustellen. Funktioniert großartig.Es wäre falsch, jemandem JavaScript mithilfe von jQuery beizubringen, aber Tutorials sind keine Einführung in die Sprache. Sie dienen dazu, Neues zu lehren. Wenn du ein Tutorial liest, kennst du bereits etwas JavaScript, und da die Wahrscheinlichkeit groß ist, dass du auch etwas jQuery kennst, scheint es mir in Ordnung zu sein.
Ich denke, es ist fair zu sagen, dass sich einige (nicht alle) JS-Entwickler fühlen, als würde ihr „Revier“ von Leuten, insbesondere Designern, überfallen, die sich vollständig auf JQuery verlassen, um ein dynamisches Element in ihre Website einzubauen. Ich sehe eine Menge JS-Puristen, die unglaublich ablehnend gegenüber Leuten sind, die sich auf JQuery verlassen, aber keine Bedenken haben, Bootstrap jedes Mal einzubinden, wenn sie ein Projekt beginnen. Während ich nicht bestreiten werde, dass JS größtenteils „tiefer“ und komplexer ist als HTML-Markup und CSS, ist die Theorie des guten Designs genauso komplex wie jedes JS, dem ich begegnet bin.
Es ist zwar für JQuery-Neulinge von Vorteil, einige grundlegende JS zu lernen, aber ich denke, dass dasselbe für Entwickler gilt, die sich auf Bootstrap verlassen, um ihre Websites zu „verschönern“. Wie viel Zeit wird mit dem Erlernen von Typografie, responsivem Design oder Farbtheorie verbracht? Gibt es einige grundlegende Unterschiede zwischen Bootstrap, das als vorgefertigtes CSS vorliegt, und JQuery, das auf Vanilla JS aufbaut? Sicher, aber sie bieten letztendlich dasselbe: Eine Brücke zu einer Disziplin, die dir sonst fremd wäre oder sogar gänzlich außerhalb deiner Reichweite liegen würde.
Ich verwende JavaScript seit den späten 90ern, bin aber sicherlich kein Experte (und kämpfe etwas mit den moderneren OOP-Ansätzen). Als ich vor ein paar Jahren anfing, jQuery zu verwenden, fingen die Dinge wirklich an, sich zu fügen, und meine Fähigkeiten haben sich schneller verbessert.
Während einige Puristen vielleicht sagen, dass jQuery nur für Anfänger ist, denke ich, dass es von deinem Lernstil abhängt. Und wenn es einfacher ist, mehr Designer dazu bringt, sich in die interaktive Entwicklung zu stürzen, wie kann das schlecht sein? Warum NOCH MEHR Einstiegshürden aufbauen, indem man die Dinge schwieriger macht?
Ich stimme den Neulingen zu, dass es beim Einstieg wichtig ist, JavaScript zu verstehen, bevor man jQuery verwendet, wenn man die richtige Mentalität hat. Und du wirst immer Neulinge in deinem Publikum haben, wenn du Tutorials schreibst.
Aber ist es das wert, ein Beispiel 10 Zeilen Code statt 5 zu machen, nur um rein zu bleiben? Ich würde sagen, nein. Solltest du davon ausgehen, dass „jeder“ weiß, was jQuery ist (noch)? Ich würde sagen, nein.
Ich habe vor einiger Zeit einen Beitrag Replacing jQuery geschrieben. Das war nach meinem zweiten Nicht-jQuery-Projekt in Folge (beides kleinere Websites ohne DOM-Manipulation oder AJAX). Und ich habe ungefähr 50/50 positive/negative Kommentare zu dem Konzept erhalten, jQuery nur zu verwenden, wenn es wirklich notwendig ist.
Ich finde es außergewöhnlich ärgerlich, Informationen zu JavaScript-Lösungen über die Google-Suche zu finden! Es ist da draußen hauptsächlich jQuery!
WTF
Die Framework-Wahl sollte den Projektanforderungen unterliegen, nicht der Toolkit-Religion.
Was mich wirklich erstaunt, ist die totale Unkenntnis von prototype.js in diesem Thread. Ich glaube, es ist das Gegenstück zu jQuery. JQ verwendet einen funktionalen Ansatz, während prototype.js die Sprache selbst erweitert. JS ist eine prototypbasierte Sprache und als solche ziemlich exotisch in unserem Zoo der Programmiersprachen. Prototype.js ist nicht das einzige Framework, das Prototypen erweitert, aber wahrscheinlich das am weitesten entwickelte.
Wenn du dich ernsthaft für Programmierung interessierst und nicht nur nach einem Marquee-Ersatz suchst, solltest du definitiv alle drei lernen: JQ, prototype.js und natives JS.
Als Entwickler muss mein Code in allen Browsern funktionieren. Außerdem muss ich Dinge schnell entwickeln… jQuery hilft mir, schnelleren, saubereren Code zu schreiben, der (fast) in allen Browsern gleich ausgeführt wird. Ich sehe nichts Falsches daran. Nun, es ist langsamer als Vanilla JS, aber in diesem Leben ist alles ein Kompromiss :)
Ich verwende tendenziell viel jQuery, wenn ich code, aber das liegt nur daran, dass ich mich in vielen Fällen wohler damit fühle als mit Vanilla JavaScript. Es ist einfacher für mich, jetzt etwas Funktionales zum Laufen zu bringen, als mich durch Seiten von Stack Overflow zu wühlen, um passende Antworten zu finden, die meinen spezifischen Bedürfnissen dienen.
Versteh mich nicht falsch – wenn ich auf eine Situation stoße, von der ich weiß, dass ich sie mit Vanilla JavaScript bewältigen kann – dann binde ich jQuery nicht ein. Das ist einfacher für die Ladezeiten der Seite.
Ich denke, wenn du jQuery kennst und dich wohl fühlst, es zu verwenden, dann ist nichts falsch daran. Es ist nicht weniger beeindruckend und funktioniert genauso gut oder besser.
Ich habe Websites gesehen und Entwickler gekannt, die sich weigern, jQuery und andere Bibliotheken aus welchen Gründen auch immer zu verwenden. Das ist in Ordnung für mich, es ist ihre Website und ihr Code, nicht meiner.
Ich mochte jQuery in Tutorials früher nicht. Ich habe die Syntax nicht verstanden. Das ist also ein Risiko. Jetzt bin ich ziemlich fließend in JavaScript, und es stört mich nicht.
Dennoch denke ich, dass es am besten ist, jQuery auf DOM-Auswahl und Events zu beschränken und Chaining nicht übermäßig zu verwenden.
Obwohl ich zustimme, dass du schreiben solltest, was du weißt (es ist schließlich dein Blog!), ist es ein Ärgernis, fast jedes Tutorial oder jede Stack Exchange-Antwort über JavaScript nur jQuery-Lösungen sehen zu müssen, besonders wenn du mobil arbeitest, wo es viele Frameworks gibt, und jQuery hinzuzufügen, wenn du es nicht bereits verwendest, zu viel Speicherbedarf ist, um es einem mobilen Gerät zuzumuten – ein Framework ist genug.
Manchmal ist es besonders lächerlich, wenn man Antworten sieht, die in jQuery komplizierter sind als in einfachem JavaScript. Die sind immer amüsant anzusehen.
Ich könnte nicht mehr zustimmen, besonders dem Teil, dass man sich in Details verliert. Ich habe so ziemlich dasselbe in diesem Beitrag gesagt, der ebenfalls eine Antwort auf jemand anderen war
http://www.impressivewebs.com/why-use-jquery-simple-tutorials/
Obwohl einige Aussagen, die ich in diesem Beitrag mache, im Nachhinein etwas zu kühn waren, zitiere ich einfach zwei Absätze, die immer noch meine aktuelle Ansicht widerspiegeln
Tolles Thema! Als Personalvermittler erzählen mir Junior-Front-End-Entwickler (z. B. zwei bis drei Jahre Erfahrung) häufig, dass jQuery und JS genau dasselbe sind. (Seufz). Meine Folgefrage dazu lautet: „Nun, wenn jQuery aus irgendeinem Grund nicht die Lösung bietet, die du gesucht hast, könntest du eine Lösung in reinem JS entwickeln?“ Ich sage ihnen, der Grund für die Frage sei, dass die Unternehmen, für die ich rekrutiere, reines JS-Testen als Teil des Interviewprozesses verlangen. Wenn sie das hören, ist die Antwort, die ich in etwa 95 % der Fälle bekomme… „ähm… hmmm… nun… ähhh… ich könnte es versuchen“ Typischerweise sagen Senior-Entwickler (z. B. 10+ Jahre), „Bring es her“.
.
Ich denke, JavaScript verdient seine eigenen Tutorials ohne jQuery. Ich habe mit jQuery allein angefangen, aber dann erkannt, dass ich Vanilla JavaScript richtig hätte lernen sollen, um die Sprache besser zu verstehen und jQuery oder andere JavaScript-Frameworks effektiv zu nutzen. Da JavaScript heutzutage auf jeder Plattform ist, scheint es, dass man JavaScript allein richtig lernen sollte. Ich habe auch einen Beitrag diesbezüglich auf meinem Blog geschrieben
https://sarfraznawaz.wordpress.com/2012/02/12/learning-javascript/
Ich stimme vollkommen zu, dass es in Ordnung ist, jQuery in Beispielen zu verwenden, da es einfach, prägnant und vertrauenswürdig ist. Diejenigen, die mit Vanilla JS nicht vertraut sind, werden nicht durch seine Exzentrizitäten belastet und können den Artikel einfach genießen (der ohnehin normalerweise auf CSS ausgerichtet ist!)
Im weiteren Sinne kann ich nicht umhin zu denken, dass all die Vanilla-JS-Evangelisten hier ein wenig optimistisch sind. Die überwiegende Mehrheit der Unternehmensentwicklung kann IE8 und darunter nicht ausschließen, daher BRAUCHST du jQuery, um dir das Leben einfacher zu machen. Wenn du etwas auch nur annähernd Kompliziertes hast, das in einem alten Browser funktionieren muss, erspare dir den Ärger und schreibe es in jQuery, das einfach zu lernen ist und eine großartige Dokumentation hat.
Kürzlich hatte ich das Glück, an einer App zu arbeiten, die nur in IE10 und Chrome funktionieren muss. Als fest verwurzelter jQuery-Enthusiast habe ich einen Teil der Funktionalität darin in jQuery erledigt und jQuery, wo möglich, umgestaltet, sobald ich mit der Lösung zufrieden war. Es ist ziemlich intuitiv und erfordert nicht unbedingt, dass jedes Tutorial ohne jQuery neu geschrieben wird.
Ein bisschen Pragmatismus ist hier sehr hilfreich, und du hast genügend Zeit, um beide JavaScript-Varianten zu lernen. IE7/8/9 werden nicht so schnell aus den Statistiken deines Unternehmens verschwinden!
Ich denke, Tutorials sollten den Leser darüber informieren, wie man Dinge richtig macht und gute Gewohnheiten annimmt. Sie in jQuery zu unterrichten, hilft ihnen dabei. Zum Beispiel in JavaScript, ja, du könntest etwas in einer Zeile schreiben. Aber dann kommen viele Variablen ins Spiel wie browserübergreifend, was, wenn dies passiert, was ist mit blah. Und plötzlich werden daraus leicht 10 Zeilen. Vielleicht sogar mehr, wenn du eine böse browserübergreifende Problemumgehung für mehrere andere Browser machen musst. Jemand findet heraus, hey, ich kann das doch in einem machen, und ohne es vollständig zu verstehen, schneidet er möglicherweise einen Großteil des Codes heraus. jQuery hat das normalerweise alles abgedeckt. Zum Glück für sie erlaubt ihnen die Mehrheit der Projekte die Verwendung von jQuery, und sie können damit durchkommen. Ich kenne keinen vernünftigen Projektmanager, der dagegen wäre, und normalerweise legen Kunden keine Sprachtechnischen Spezifikationen fest, die über die Wahl von Ruby, PHP, Python, ASP hinausgehen, sodass der Entwickler seine Wahl treffen kann.
Aber ich muss sagen, nicht alle. Ich habe an Projekten gearbeitet, die nur JavaScript erforderten, und jQuery war keine Option. Aber das waren Projekte, die JS als externe Skriptsprache verwendeten und keine Website oder Webanwendung waren.
Aber da dies gesagt ist, wenn du es ernst meinst mit der Webentwicklung. Lerne JavaScript. Wenn wir Entwickler interviewen, die sagen, sie kennen „jQuery“, aber nicht so gut in JavaScript sind, bekommen sie zu 95 Prozent der Zeit keinen Rückruf.
Als ich anfing, JavaScript zu lernen, gab es bereits mehrere JavaScript-Frameworks. Ich weigerte mich, sie zu lernen und zu verwenden, weil es sich anfühlte, als würde jemand anderes für mich arbeiten – und das hat mich gestört.
Es mag heutzutage albern klingen, aber ich hatte das Bedürfnis, tief in die Sprache einzutauchen. Ich musste lernen, wie JavaScript funktioniert, und es im Detail lernen. Das führte dazu, ein tieferes Verständnis der Sprache zu erlangen. Und warum jQuery bei vielen Aufgaben, die ich für trivial hielt, so langsam war.
jQuery erlaubt das nicht. jQuery ist fast wie eine neue Sprache, in Programmierphilosophie und Syntax. Es gibt Dinge, die man in Vanilla JavaScript tun kann, aber mit jQuery sollte man einen völlig anderen Ansatz verwenden, um konsistent zu bleiben – ohne besonderen Gewinn an Codlänge oder gar Klarheit.
Außerdem hat jQuery seine eigenen Arbeitsweisen. Es könnte zu großen Speicherlecks führen oder zu einem CPU-Fresser werden, wenn es nicht korrekt verwendet wird, selbst in moderneren Browsern (Twitter hat es auf die harte Tour gelernt). Deshalb ist es wie eine völlig neue Sprache. Wie oft hast du einen Anfänger so etwas tun sehen?
Und so weiter mit
$("#field"). Oder noch beängstigenderVersteh mich nicht falsch, jQuery ist großartig. Es ist die Waffe der Wahl für jede Website, die dem großen Publikum des Internets offensteht. Damals war es befreiend, IE-Legacy-Methoden und eine Menge anderer Inkompatibilitäten und Inkonsistenzen zwischen Browsern zu vergessen, und das ist es immer noch. Und jQuery spart eine ganze Menge Code-Tippen. Aber es hat seine Tücken.
Erstens ist es langsam und speicherintensiv. Es ist also nicht gut für alles. Nicht für Anwendungen, die auf hohe Leistung angewiesen sind, wie viele, die die neuesten Webtechnologien verwenden.
Es ist also ziemlich verständlich, dass viele Entwickler tatsächlich eine Vanilla-JavaScript-Lösung kennen möchten – weil sie vielleicht überhaupt kein jQuery verwenden.
Glücklicherweise kennen die meisten Entwickler tatsächlich ein bisschen jQuery – genug, um zu verstehen, was vor sich geht. Und die meisten Beispiele und Tutorials verwenden jQuery auf triviale Weise, um sich den Schmerz zu ersparen, einen Polyfill für das Hinzufügen von Event-Listenern zu erstellen und sich nicht nur auf
addEventListenerzu verlassen und die Beschwerden eines Neulings zu lesen, der nicht versteht, warum der Code in IE8 nicht ausgeführt wird.Wenn das, was du mit JavaScript tun möchtest, einfach genug ist, kannst du also mit jQuery arbeiten: Die Anfänger würden es wahrscheinlich verwenden, während erfahrenere Programmierer kein Problem damit haben werden, es zu verstehen. Aber immer beschreibe, was du tust, im Detail, d.h. in (fast) jeder Zeile deines Codes. So etwas wie
$("#container").find("input")ist nicht gerade trivial für jemanden, der nicht an jQuery gewöhnt ist.(Am besten wäre es, beide Versionen des Codes zu schreiben – mit jQuery und ohne. Aber das wäre zeitaufwändig.)
Und wenn du dich mit einer modernen Webtechnologie befasst, verwende immer Vanilla JavaScript – und füge vielleicht etwas hinzu wie „Du kannst dir etwas Mühe sparen, indem du $(…) verwendest“.
„Ich kann einen verdammt guten Blick auf ein T-Bone-Steak werfen, indem ich meinen Kopf in den Arsch eines Bullen stecke, aber ich verlasse mich lieber auf das Wort des Metzgers.“
Als Webdesigner / Front-End-Entwickler
Das Markdown funktioniert überhaupt nicht, lol.
100% Zustimmung
Lass mich wissen, wie es kaputt ist. Soweit ich sehen kann, wurde das, was du gepostet hast, korrekt als Markdown interpretiert.
Es kommt darauf an, was du mit „schneller“ meinst. Wenn du „schneller zu entwickeln“ meinst, hast du wahrscheinlich recht. Aber es ist ein No-Go, wenn du denkst, es sei „schneller auszuführen“.
Und das ist eine kluge Sache.
Oh ja, das gibt es: Ein Tutorial lesen, das [füge hier ein JS-Framework ein] verwendet. Was? Du bist nicht an [füge das zuvor genannte JS-Framework ein] gewöhnt? Wie schade. (Ich hoffe, du verstehst meinen Punkt.)
In der Tat, aber entschuldige, ich verstehe deinen Punkt hier nicht. Willst du andeuten, dass es einen guten Ort gibt, um jQuery zu fragen und zu lernen? Dasselbe gilt für Vanilla JavaScript, weißt du.
/ 6. Du musst dich nicht schuldig fühlen, weil du Webdesigner bist, also musst du JavaScript nicht in die Tiefe kennen. Das ist verständlich. Aber was ist, wenn die Webentwickler zu dir sagen: „Wir verwenden [füge das zuvor genannte JS-Framework ein], bitte verwende es auch“?
Und ja, das Markdown ist in meiner Nachricht kläglich gescheitert :(
Es war so gut in der Vorschau, und doch hat es alle Zahlen verloren, als ich es gesendet habe.
Chris, bitte hilf :(
Wären die Ressourcen, die wir zur Hand haben, so reichhaltig und leicht verfügbar, wenn jQuery in der Community nicht so verbreitet wäre?
Nette Vertuschung..
Ich bin ein Neuling und habe mit JavaScript angefangen, verwende aber jQuery lieber, weil es etwas schneller zu coden ist. Interessanterweise habe ich heute darüber nachgedacht, ob es besser ist, JavaScript zu verwenden, da es der Gründervater war. So oder so würde ich beiden Parteien zustimmen, dass für Demozwecke die Verwendung von jQuery in Ordnung ist (jeder kennt es, und für die Leute, die Vanilla verstehen, werden sie höchstwahrscheinlich wissen, wie man die Syntax anpasst, um es in JS zu skripten), und dass JS definitiv genauso viel Aufmerksamkeit in Bezug auf Tutorials usw. benötigt, wie jQuery sie hat.
Beide sind wichtig und man könnte argumentieren, dass das eine besser ist als das andere. Wenn es funktioniert und im Kontext Sinn macht, warum es nicht verwenden? Definitiv kein Grund, sich darüber aufzuregen.
Seid cool, unterstützt euch gegenseitig, lasst uns unsere Gemeinschaft zum Besseren wachsen lassen!
Ich denke, dass die Verwendung von jQuery in Ordnung ist, obwohl es vorteilhaft sein könnte, sicherzustellen, dass die Leute verstehen, dass jQuery eine Bibliothek/ein Framework ist und kein Teil der Sprachspezifikationen. Ich sehe das genauso, wie ich jede andere Sprache sehe. Du lernst die Grundlagen von Java, aber du lernst auch etwas über apache-commons, JavaFX, Spring und andere Bibliotheken, die dir das Leben leichter machen.
Ein vielseitiger Programmierer kennt die Sprache und die verfügbaren Bibliotheken da draußen.
Sich darüber aufzuregen, warum man jQuery verwenden soll, ist wie sich darüber aufzuregen, warum man WordPress verwenden soll, weil es andere CMS gibt, die tonnenweise mehr Funktionen, mehr dies, mehr das haben usw.
Eilmeldung. Sie sind beliebt. Die Leute suchen sie. Es ist eine Frage von Angebot und Nachfrage.
Wirklich? Vergleichst du die JavaScript-jQuery-Debatte mit einem Vergleich zwischen CMS? Das ist überhaupt nicht der Punkt der Diskussion.
Wie einige vielleicht bemerken, ist jQuery ist JavaScript, also ist JavaScript per Definition beliebter als jQuery. Wenn du die Popularität berücksichtigst, gäbe es keinen Zweifel.
Es geht darum, ob man ein JavaScript-Framework verwendet oder nicht. Es könnte jQuery, Dojo, Prototype sein… jQuery wird verwendet, weil es ist das beliebteste Framework. Aber wir reden nicht über die Wahl eines Frameworks.
Ich verstehe nicht, warum das ein solches Problem für JavaScript-Puristen ist. Wenn du ein Tutorial über etwas liest, das jQuery verwendet, und du weißt, wie man es in Vanilla JavaScript macht, dann… verwende JavaScript. Warum sich die Mühe machen, jemanden anzugreifen, weil er jQuery verwendet? Manche Leute mögen Vanilla-JavaScript-APIs nicht, und jQuery verpackt sie in einer für sie viel vernünftigeren Weise, also was ist daran falsch?
Es gibt einen Grund, warum jQuery sehr beliebt bleibt, und das liegt daran, dass die Leute es mögen. Es hilft ihnen, das zu erreichen, was sie wollen, und das ist es. Ehrlich gesagt, würde ich lieber jemanden sehen, der vielleicht nichts über JavaScript weiß, aber brillante Dinge mit jQuery erstellen kann. Sicher, JavaScript-Puristen werden dann sagen: „Ich kann es auch mit Vanilla JavaScript machen“, aber andererseits spielt es keine Rolle. Mit jQuery erstellt dieser Jemand etwas Brillantes. Ohne jQuery würde er es vielleicht nicht tun.
Ich glaube, der Aufstieg der Javascript-Popularität verdankt auch jQuery viel. Ohne die Popularität von jQuery wäre Javascript meiner Meinung nach nicht in dem Zustand, in dem es sich gerade befindet. Selbst die beliebtesten JS MVCs (Backbone, Ember, Angular bis zu einem gewissen Grad) verwenden jQuery.
Was kommt als Nächstes? SCSS/LESS nicht über Vanilla CSS verwenden?
Das „Falsche“ ist, dass jQuery nur ein Teil der Javascript-Welt ist. Viele Entwickler – nicht nur Anfänger – kennen jQuery möglicherweise nicht sehr gut oder überhaupt nicht. Daher ist Ihr Ratschlag „dann verwenden Sie Javascript“ nutzlos, wenn der Entwickler jQuery nicht tatsächlich in Javascript übersetzen kann.
Der Autor, der ziemlich flüssig in jQuery ist, neigt möglicherweise dazu, komplexe Syntaxstrukturen zu verwenden und das Chaining zu missbrauchen, und das wäre ein Albtraum für jemanden, der das Tutorial lesen möchte.
Und geben wir es zu: jQuery ist für die meisten Dinge übertrieben. Und ich meine nicht die Dinge in einem Tutorial – sondern für die Webentwicklung im Allgemeinen. Ein guter Entwickler kann einige Hilfsfunktionen schreiben, um Event-Listener anzuhängen, Klassen hinzuzufügen und AJAX-Aufrufe zu tätigen, und das würde fast alles abdecken, was ein Entwickler mit jQuery tun würde, wobei viel weniger Speicher und CPU verwendet werden. Das wird oft vergessen, aber da IE8 verschwindet, wird jQuery immer unwichtiger (und ich bin mir sicher, John Resig hätte nichts dagegen – es wäre dasselbe für die anderen Frameworks).
Am Ende denke ich also, dass es in Ordnung ist, jQuery für sehr grundlegende Dinge zu verwenden, wie das Hinzufügen einer Klasse oder eines Event-Listeners, nur um zu zeigen, wie man einen Effekt anwendet. Denn selbst
$.getoderanimatekann für einen Anfänger eher obskur sein. Für etwas Komplizierteres verwenden Sie Vanilla Javascript. Es sei denn, es handelt sich natürlich um ein Tutorial, das explizit für jQuery gedacht ist.Und ja, der nächste Schritt ist, die Verwendung von Vanilla CSS anstelle von SCSS/LESS in Frage zu stellen, und zwar in noch größerem Umfang, da CSS-Frameworks für CSS nicht annähernd so beliebt sind wie jQuery für Javascript, sodass sie für Anfänger – d. h. die häufigsten Tutorial-Leser – weitaus obskurer sind.
P.S.: Und ich glaube nicht, dass jQuery viel dazu beigetragen hat, die Popularität von Javascript zu steigern. Es spielt keine Rolle, ob jeder Browser jetzt
querySelectorAllimplementiert, es ist nur minimal. Für den Aufstieg von Javascript können Sie sich bei dem Anstieg der Popularität standardkonformer Webbrowser bedanken, insbesondere bei Firefox und dann bei Chrome.Was ich in letzter Zeit gesehen habe, sind Tutorials, die in allen verschiedenen Javascript-Mustern geschrieben sind. Ich habe begonnen, diese Muster zu lernen, damit ich das Javascript vollständig verstehen und übersetzen kann.
Als ich anfing, Webentwicklung zu lernen, begann ich, JQuery zu lernen und zu verwenden, aber irgendwie fühlte ich mich leer und verspürte das Bedürfnis, reines Javascript zu lernen. Jetzt lerne ich immer mehr, und ich verwende jQuery nur, wenn aus irgendeinem unvorhersehbaren Grund die Zeit knapper wird. Nun, eigentlich möchte ich es genauer sagen ... Ich verwende „Jquery Plugins“, wenn die Zeit knapper wird, ansonsten verwende ich reines Javascript und ich liebe es.
Ich finde, dass die IT-/Entwicklungswelt, wie vieles andere auch, ziemlich polarisiert ist und bis zu einem gewissen Grad lächerlich polarisiert ist. Linux vs. Microsoft, jQuery vs. JavaScript usw. Was kommt als Nächstes? Proteste und Kriege basierend auf Ihrer Entwicklungssprache oder -plattform? Ja, das ist extrem, aber ich habe einige sehr hitzige Debatten über Technologien gesehen und bin einfach kopfschüttelnd davongegangen. Andererseits gab es vor einiger Zeit dieses lächerliche OccupyFlash... im Ernst?
Wir sind in unserem Arbeitsbereich, um Lösungen zu liefern – ob das nun eine grundlegende Website, E-Commerce, ein Spiel usw. ist. Ich kenne keinen Kunden von uns, der jemals gesagt hat: „Wir wollen nicht, dass Sie jQuery verwenden, nur reines JavaScript“. Den meisten ist das auch egal. Ihnen ist wichtig, dass das Erlebnis, das sie ihren Kunden/Kunden bieten möchten, ihre Erwartungen erfüllt (oder übertrifft).
Für mich ist es wichtiger, die von Ihnen gewählten Werkzeuge, Sprachen und Plattformen gut zu kennen und zu wissen, wie Sie sie am besten nutzen, um Ihre Ziele zu erreichen. Sie sollten ihre Stärken, Schwächen, Fallstricke sowie wo und wann Sie sie nicht verwenden sollten, kennen.
Wenn Ihr jQuery-Code ein Leistungsproblem verursacht, optimieren Sie ihn. Wenn er optimal ist, dann greifen Sie zu reinem JavaScript.
Ich möchte nicht in einem Entwicklungsteam arbeiten, in dem der Lead jQuery einfach verwirft, nur weil er/sie es nicht als „rein“ ansieht. Sollten wir keine IDEs verwenden, weil sie das Codieren auch einfacher machen? Wer braucht Debugger, Tracing, Profiling, Code-Vervollständigung... ja, ich würde lieber das Gleiche mit mehr Arbeit erreichen.
Wenn Sie das Interesse und die Neigung haben, lernen Sie, was Sie können. Lernen Sie unbedingt JavaScript, Sie werden dadurch besser. Aber brandmarken Sie niemanden als inkompetent, weil er kein JavaScript-Ninja ist (übrigens, ich bin es so leid, Stellenbeschreibungen zu sehen, die nach Ninjas, Gurus, Code-Kriegern usw. fragen. Erwarten sie, dass man in seinem Ninjago-Kostüm auftaucht?)
Ich stimme dem, was MG gerade gesagt hat, voll und ganz zu und schließe mich an, und wie Chris in seinem Artikel clever sagt
Es hat keinen Sinn, Zeit damit zu verschwenden, sich über die Verwendung oder den Missbrauch von jQuery zu streiten. Diejenigen, die es weise verwenden, haben so viele erfolgreiche Projekte bereitgestellt (ich bin einer davon, kann ich sagen). Es hat keinen Sinn, so viel reinen Javascript-Code zu schreiben und sehr wenig zu erreichen, während das Gegenteil mit jQuery leicht zu bewerkstelligen ist.
Kurz gesagt, verwenden Sie jQuery, Zepto, underscore oder reines js, was auch immer Ihnen die beste Leistung bietet und maximale Flexibilität bei Ihrem Codierungsstil bietet. Genug gesagt.
Ich denke, jQuery ist falsch für einfache Tutorials, bei denen es im Tutorial nicht um jQuery geht. Wenn Sie sich von <IE9 Event-Modell und anderen Kompatibilitätsproblemen fernhalten möchten, sollte das Tutorial nur einen Shim erwähnen, um das gleiche Verhalten in IE zu erhalten. Genau wie
$(element).removeClass("active");kann über reines Javascript mitelement.classList.remove("active");erreicht werden. Zeigen Sie einfach auf den Shim, der Unterstützung hinzufügt.Was zählt, ist, ob die gegebene Aufgabe zufriedenstellend erledigt wird oder nicht. Alles andere ist Gerede.
Genau: Auf die eine oder andere Weise militant zu sein, wenn manchmal das Beste für Ihre Kunden das Gegenteil Ihrer Präferenz ist, ist nicht klug. Allerdings verfolgen viele Front-End- und sogar einige Back-End-Webprogrammierer diesen technischen Ansatz nicht. Sie schätzen entweder das Aussehen und Gefühl mehr als die Praktikabilität oder stürzen sich einfach auf die Lösung, die für sie am wenigsten Arbeit bedeutet.
Das gesagt, frage ich mich oft, wenn ich Websites auf meinem Mobiltelefon besuche und meine erste Reaktion ist: „Warum lädt ein jQuery-Schnickschnack auf meiner langsamen, getakteten Verbindung für meinen kleinen Bildschirm? Ich kann noch nicht einmal sehen, wofür ich hierher gekommen bin!“
Ich bin erst seit knapp 3 Jahren Webentwickler und erst im letzten Jahr habe ich gelernt, jQuery/JavaScript zu verwenden, und ich verstehe nicht wirklich, warum sich die Leute so sehr aufregen, wenn es darum geht, jQuery statt JavaScript zu lernen.
Wenn es die Arbeit einfacher macht, jQuery zu verwenden, dann verwenden Sie es, sage ich. Ich bin vielleicht nicht die richtige Person, um das zu sagen, aber es ist einfach verdammt viel einfacher, jQuery zu verwenden, weil das, was Sie codieren, buchstäblich so ist, wie Sie es in Kurzform sagen würden.
Du hast absolut Recht, Charlie, jQuery ist viel einfacher zu verwenden als Vanilla JS. Kann oft die perfekte Lösung sein, wenn Sie eine Menge Skripte für eine Website haben. Außerdem ist das Ökosystem von jQ fantastisch (so viele Plugins zur Auswahl!).
Aber diese Benutzerfreundlichkeit macht jQuery süchtig. Manchmal wird jQ als Overkill-Lösung hinzugefügt, wenn nur 10 Zeilen Vanilla JS kopiert, eingefügt und angepasst werden könnten, wodurch der Website-Download unnötig verlangsamt, das Seitenranking gesenkt usw. wird. Sie müssen keinen Bohrer kaufen, wenn ein einfacher Schraubendreher schneller und billiger funktioniert.
+1
Ich kann mich leicht mit dem Konzept anfreunden, dass man die Sprache lernen sollte, bevor man sich in ein vorgefertigtes Framework hüllt und einfach die API anwendet. Sicher.
Wie Jake betonte, sehe ich auch eine wahnsinnig große Community von Entwicklern, die Bootstrap und all die Tools verwenden, die Bootstrap als Plattform behandeln. Ganz zu schweigen von der neuen Welle von Angular-Entwicklern, die die Chance nutzen, Angular-Bootstrap zu installieren.
Ist es nicht dieselbe Diskussion, wenn ein Entwickler, anstatt zu lernen, wie man besseres CSS entwickelt und ordnungsgemäße architektonische Praktiken anwendet, standardmäßig einfach Bootstrap aus dem Regal nimmt?
So ziemlich jedes Beispiel, in dem jemand in diesem Thread gesagt hat, „man braucht jQuery nicht, um X zu tun“, kann ich dieselben Argumente bei Bootstrap anwenden.
Wenn ich beschimpft werden soll, weil ich 93 KB jQuery zu einem Projekt hinzufüge, um mir die Arbeit zu erleichtern, habe ich dann nicht das Recht zu sagen, dass das Hinzufügen von Bootstrap (98 KB minimierte Version) genauso schlimm ist?
Ich denke, dass wir als Community weniger Zeit damit verbringen müssen, andere herabzusetzen, die nicht das „wahrgenommene“ Richtige tun, und verstehen müssen, dass wir alle Aufgaben zu erledigen haben. Im Laufe der Zeit und mit Erfahrung beginnen wir, unsere Toolsets neu zu bewerten und unsere eigenen zu entwickeln.
</peace out>
^^Wort.