Hat jQuery die JavaScript-Diskussionen beendet? [geschlossen]


7

Es gibt über 100.000 Fragen zum Stapelüberlauf, die als Fragen zur Fehlerbehebung / Verwendung von JQuery gekennzeichnet sind. Vergleichen Sie dies mit den 124.000 Fragen zum Stapelüberlauf, die für JavaScript-Probleme markiert sind. Fast die Hälfte aller JavaScript-bezogenen Fragen zum Stapelüberlauf werden JQuery zugeordnet (plus oder minus einer Marge für die wenigen anderen JS-Frameworks, die Fragen zu SO erhalten).

Was ich damit sagen will, ist, dass jQuery keine Sprache ist und nicht das A und O aller Frameworks, die auf jedes Szenario angewendet werden müssen, in dem JavaScript vorhanden ist, aber es fängt schnell an (und ich gehe davon aus, dass es bald in den Schatten stellen wird) ) JavaScript als Diskussions- / Anfragequelle auf Websites wie Stack Overflow.

Tötet jQuery den JavaScript-Stern? Gibt es für die nächste Generation von Webentwicklern keinen festen Überblick mehr über die Leistungsfähigkeit, Einfachheit und Verwendung von JavaScript als Mittel zur DOM-Manipulation? Ist dies nur die natürliche Entwicklung der Dinge und der Standpunkt, den ich präsentiere, typisch für das Ego des Codierers (dh sehen Assembly-Programmierer auf diese Weise die .NET / Java / Web-Menge?) Oder ist dies wirklich der Anfang vom Ende des echter JavaScript-Entwickler?


6
Hallo Brian. Diese Frage klingt ziemlich argumentativ und lädt zur Diskussion ein. Von solchen Fragen wird bei Stack Exchange abgeraten . Können Sie Änderungen vornehmen, um die Diskussion zu verbessern? Vielen Dank.
Adam Lear

2
@Anna Lear - Meine Entschuldigung - Ich habe die FAQ zu StackOverflow als Anleitung interpretiert, um die Frage hier zu stellen: • Erfahrene Programmierer, die an professionellen Diskussionen zur Softwareentwicklung interessiert sind, fragen Sie die Programmierer. - Ich möchte auf keinen Fall zu nutzlosem Geschwätz beitragen und werde verstehen, wenn die Frage entfernt wird. Ich dachte, dies sei das Forum für eine theoretischere Debatte.
Brian

3
Ich würde auch gerne wissen, warum meine Frage argumentativ ist und zur Diskussion einlädt (daher unangemessen), aber "denken Sie, dass cin und cout die Pfeile falsch herum haben?" in Ordnung? programmers.stackexchange.com/questions/101234/… . Es scheint mir, dass dies in der Tat ein Forum für eine intellektuelle Debatte über Softwareentwicklung wäre, nicht nur für endliche Fragen und Antworten. - nur sagen ...
Brian

2
Ich denke, unsere FAQ erfassen / kommunizieren den Geist ziemlich gut.
Adam Lear

3
Der in der Frage sehr stark implizierte Vorschlag, dass die aktuelle Generation JQuery verwendet, weil sie nicht so gut in JavaScript sind wie die vorherige, ist der offensichtliche Hinweis auf Ihre Frage, warum dies argumentativ ist. (FWIW Ich erinnere mich an die Tage vor JQuery, und die DOM-Manipulation war alles andere als einfach, wenn Sie wollten, dass sie browserübergreifend funktioniert.)
Peter Taylor

Antworten:


1

Sie könnten sicherlich das Argument vorbringen, dass jQuery die Javascript-Diskussion beendet hat, und dieses Trenddiagramm würde dies unterstützen: http://www.google.com/trends?q=jquery%2C+javascript

Es ist ziemlich einfach, dies auch auf dem Message Board Ihrer Wahl zu beobachten. Immer ein "Wie machst du xxx in Javascript?" Wenn eine Frage gestellt wird, können Sie fast darauf wetten, dass die Antworten das Format "Verwenden Sie jQuery und tun Sie einfach JJJ" haben.

Ich würde sagen, es ist genauer zu sagen, dass es jetzt üblicher ist, Javascript in Bezug auf übergeordnete Frameworks zu diskutieren (ob dies so etwas wie ein jQuery / Prototyp oder Knockout / Backbone oder node.js oder ... ist).


3
Die nur mit jQuery und yyy tun Antworten incur ein automatisches Downvote von mir für nicht-jQuery getaggt SO Fragen.
Michael

@kekekela - vielleicht der genialste Hintergrund für beide Seiten des Arguments. Ich hätte den Kontrapunkt sofort zurückgetreten, wenn die Trendlinien umgekehrt worden wären. Zumindest weiß ich aus den Antworten, dass es eine Vielzahl talentierter und intelligenter Leute gibt, die ihren Code mit jQuery ergänzen und nicht jeden Online-Code darauf aufbauen.
Brian

3
@StuperUser Denken Sie daran, dass die wenigen gespeicherten Codezeilen für Sie als Entwickler eine Annehmlichkeit sind, während die 90 KB eine Strafe für Ihre Endbenutzer darstellen. Natürlich ist jQuery mit vielen DOM-Manipulationen oder -Ereignissen beschäftigt, wie Sie sagen, aber es $(foo)wird zur Standard-SO-Antwort auf einfache Aufgaben, wie z. B. wie bekomme ich alles <img>auf einer Seite . Die Strafe für Endbenutzer ist unangemessen.
Michael

1
@ Michael, ich stimme zu. Jedes Mal, wenn einige Codezeilen in einer gesamten Anwendung gespeichert werden, müssen sie gewartet werden. Entwickler, die über die erforderlichen Kenntnisse verfügen, um JS ordnungsgemäß zu verwenden, müssen eingesetzt / geschult werden. Dies kann über den gesamten Lebenszyklus hinweg viel Zeit und Geld bedeuten. Mit hohen Download-Geschwindigkeiten und Browser-Caching können viel mehr als 90 KB gespeichert werden. Ich verstehe, dass Sie wissen, wann Sie es verwenden müssen und wann nicht. Hoffen wir nur, dass mehr Benutzer ihre Antworten qualifizieren, anstatt standardmäßig $('selector')Upvotes zu verwenden und diese zu erwarten.
StuperUser

1
@StuperUser +1 So erfreut, wenn eine Internet-Meinungsverschiedenheit, wenn sie erklärt wird, eher zu einer Einigung als zu einem Streit wird.
Michael

12
  1. Nein, jQuery beendet kein JavaScript, sondern entfaltet die Sprache.
  2. Es gibt Nodejs, die Javascript als CLI oder für serverseitiges Scripting verwenden.

Über jQuery . Ich programmiere seit 2001 mit DOM-APIs und kann Ihnen versichern, dass Sie mit einer einfachen und gut getesteten DOM-API wie jQuery mehr am eigentlichen Problem als an der API arbeiten können.

Ich habe DOM 2005 auch in rohem Javascript manipuliert und die meiste Zeit damit verbracht, es browserübergreifend funktionieren zu lassen.

Vor jQuery verbrachten viele von uns Zeit damit, die Browserunterschiede und -fehler unabhängig und mit wenig Code-Sharing zu beheben. Wir haben immer wieder die gleiche Arbeit und die gleichen Fehler wiederholt. jQuery hat uns von dieser Pflicht befreit. Heutzutage arbeite ich mit vielen jQuery-Plugins hauptsächlich an meinem Problemfeld, kann aber auch viel kompliziertere Manipulationen am Dokument vornehmen. Nur befreit von DOM-Kopfschmerzen konnte ich die wahre Kraft von Schließungen und der JS-Ereignisschleife lernen (muss für jeden js-Programmierer gesehen werden!)

Die meisten Javascript-Programmierer verwenden jQuery, um das DOM zu manipulieren. Daher beziehen sich die meisten Fragen auf diesen Bereich und jQuery.

Es gibt Alternativen zu jQuery:

  • Prototyp, es hat viele Einstiegspunkte (was verwirrend ist) und enthält Zeitbomben (Es fügt den eingebauten Objekten einige Methoden hinzu, aber nur diejenigen, die noch nicht in den Objekten enthalten sind. Wenn Browser-Entwickler sie in naher Zukunft implementieren Die Objekte ändern ihr Verhalten und viele Websites funktionieren nicht mehr. Die Entwickler müssen ihre Websites dringend reparieren.)
  • RightJS (kann nichts sagen, scheint aber eine nette API zu haben)

Node.js ist eine sich schnell entwickelnde Umgebung, die in einigen Jahren möglicherweise zur Mainstream-Serversprache wird. Mein Eindruck davon ist, dass es noch viele Funktionen gibt, die die Sprache eleganter erscheinen lassen könnten. Im Moment ist die Organisation Ihres Codes sehr aufwändig. Ich kann nicht sagen, ob es mit einem Framework wie jQuery oder nur mit einer neuen Sprachversion repariert werden kann, aber stellen Sie sicher, dass dies von jemandem behoben wird. Node.js und JS im Allgemeinen haben genügend Schwung.


Danke für deine Antwort. Ich muss jedoch einreichen, dass Sie einen Teil dessen berührt haben, was ich als einen der vielen Mythen von JQuery betrachte. Es gibt über 5000 Fragen zu StackOverflow für "JQuery Firefox" und mehr als 5000 für "JQuery Chrome". Über 3k für "JQuery IE". Obwohl ich Ihrer Gesamtperspektive hier zustimme, denke ich, dass ein Teil dessen, was mich wundert, wenn JQuery den Talentpool beschädigt, eine Menge Leute ist, die erstaunt sind, dass etwas in einem Browser nicht funktioniert, das in einem anderen funktioniert - und sie haben keine Ahnung So starten Sie die Fehlerbehebung. +1 für deine Antwort.
Brian

Ich hatte Probleme mit einigen Plugins, die mit einigen Browsern nicht oder nur wie erwartet funktionierten (wie Livequery, die Filterketten nicht versteht). Ich habe die Vollversion von jQuery geladen und debuggt.

@Brian - Ich würde argumentieren, dass dies mehr damit zu tun hat, dass viele der Leute, die diese Fragen stellen, nicht wissen, was es tatsächlich braucht, um irgendetwas browserübergreifend zum Laufen zu bringen . Sie finden auch eine große Anzahl von HTML- oder CSS-Inhalten, bei denen es sich auch um Teile handelt, die nicht browserübergreifend funktionieren. Viele dieser Fragesteller wussten nicht einmal, dass die Browser Entwicklertools zur Fehlerbehebung bei einem bestimmten browserbasierten Problem hatten.
Shauna

8

Ich würde es als näher an der Standardbibliothek in C ++ als an der .Net / Assembly-Analogie ansehen. Oder noch besser .Net und C #. In der C # -Spezifikation gibt es nichts, was besagt, dass Sie .Net verwenden müssen, aber es ist ziemlich eng miteinander verbunden. Was Ihre Frage betrifft, interessieren sich die meisten Webentwickler nicht für JavaScript.

Tatsächlich würde ich argumentieren, dass der DOM-Manipulationsteil von JavaScript ziemlich schrecklich ist (insbesondere angesichts der Tatsache, dass verschiedene Browser es schwierig machten, Dinge überall zum Laufen zu bringen). Ich glaube nicht, dass Sie etwas anderes hineingesteckt und ein besseres Ergebnis erzielt haben könnten, aber jahrelang war es ein Punkt der Frustration (wieder einmal normalerweise aufgrund von Browserherstellern). Die meisten Leute hackten einfach etwas vor jQuery zusammen und nannten es einen Tag (und proklamierten sich die meiste Zeit als "Experten"). jQuery nimmt einfach die Teile, die niemand mochte, und verleiht ihnen ein schöneres Gesicht. Da dies derzeit die Hauptanwendung von JS ist (DOM-Manipulation), wird jQuery immer häufiger angezeigt (oder ein anderes Framework wie Prototype usw.). Nur damit Sie wissen, dass der durchschnittliche Webentwickler vor jQuery kein großartiger JS-Entwickler war.

Davon abgesehen macht sich JavaScript als Sprache gut. Node.js ist ein gutes Beispiel dafür, wie es als tatsächliche Sprache verwendet wird. Ich habe sogar versucht, es in einigen meiner Apps als eingebettete Skriptsprache zu verwenden (für LUA verloren gegangen, aber nur, weil die Einrichtung von LUA weniger Zeit in Anspruch nahm).


3

Jquery abstrahiert die nervigsten und langweiligsten Aufgaben bei der Entwicklung eines Javascript für eine Website. Das Durchqueren des DOM ist eine wiederholbare Aufgabe, die viel Handarbeit erfordert und nur sehr geringe Vorteile bietet, wenn Sie es auf die harte Tour ausführen. Die einzigen Fälle, in denen ich jQuery heutzutage nicht benutze, sind die mobilen Versionen der Websites - Sie können sich einfach keine weitere Anfrage mehr leisten und dort 100.000. Gleiches gilt für das Laden von Ajax.

Auch jQuery lässt quasi funktionale Programmierung Spaß machen. Es führt das Konzept der Funktion als erstklassiges Objekt für Entwickler sehr intuitiv ein. Wirf ein paar Eye-Candy-Effekte und einige sehr gute Plugins - es ist ein ziemlich beeindruckendes kleines Tool, das perfekt für diese Aufgabe geeignet ist.

Standard-Javascript -> Jquery hatte für mich das Gefühl, von C ++ und mfc auf Winforms und C # zu migrieren.


Für die Aufzeichnung gefällt mir diese Antwort am besten. Es ist ehrlich und gibt mir Hoffnung, dass jQuery von einigen auf der Welt angemessen verwendet wird - als Erweiterung und nicht als kostenlose Erweiterung (+1 für die Berücksichtigung des js-Downloads auf Mobilgeräten). Ich markiere Kekekela als korrekt, obwohl ich Statistiken zitiere - obwohl 3% aller Statistiken sowieso erstellt wurden.
Brian
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.