Warum ist jQuery im Vergleich zu anderen Javascript-Frameworks so weit verbreitet? [geschlossen]

72

Ich leite eine Gruppe von Programmierern. Ich schätze die Meinung meiner Mitarbeiter, aber in letzter Zeit waren wir uns uneinig, welches Framework für Webprojekte verwendet werden soll.

Ich persönlich bevorzuge MooTools , aber einige meiner Mitarbeiter scheinen auf jQuery migrieren zu wollen, da es weiter verbreitet ist. Das allein reicht mir nicht aus, um eine Migration zuzulassen.

Ich habe sowohl jQuery als auch MooTools verwendet . Dieser spezielle Aufsatz spiegelt tendenziell meine Meinung zu beiden Frameworks wider. jQuery eignet sich hervorragend für die DOM-Manipulation, scheint jedoch darauf beschränkt zu sein, Ihnen dabei zu helfen.

In Bezug auf die Funktionen ermöglichen sowohl jQuery als auch MooTools eine einfache DOM-Auswahl und -Manipulation :

// jQuery
$('#someContainer div[class~=dialog]')
    .css('border', '2px solid red')
    .addClass('critical');

// MooTools
$('#someContainer div[class~=dialog]')
    .setStyle('border', '2px solid red')
    .addClass('critical');

Sowohl jQuery als auch MooTools ermöglichen einfaches AJAX :

// jQuery
$('#someContainer div[class~=dialog]')
     .load('/DialogContent.html');

// MooTools (Using shorthand notation, you can also use Request.HTML)
$('#someContainer div[class~=dialog]')
     .load('/DialogContent.html');

Sowohl jQuery als auch MooTools ermöglichen eine einfache DOM-Animation :

// jQuery
$('#someContainer div[class~=dialog]')
    .animate({opacity: 1}, 500);

// MooTools (Using shorthand notation, you can also use Fx.Tween).
$('#someContainer div[class~=dialog]')
    .set('tween', {duration: 500}) 
    .tween('opacity', 1);

jQuery bietet folgende Extras:

  • Große Community von Unterstützern
  • Plugin Repository
  • Integration mit Microsoft ASP.NET und VisualStudio
  • Wird von Microsoft, Google und anderen verwendet

MooTools bietet folgende Extras:

  • Objektorientiertes Framework mit klassischer OOP-Emulation für JS
  • Erweiterte native Objekte
  • Höhere Konsistenz zwischen Browsern für die Unterstützung nativer Funktionen.
  • Einfachere Wiederverwendung von Code
  • Wird vom World Wide Web Consortium, Palm und anderen verwendet.

Angesichts dessen scheint es, dass MooTools alles macht, was jQuery macht und mehr (einige Dinge, die ich in jQuery und in MooTools nicht kann ), aber jQuery hat eine kleinere Lernkurve.

Die Frage ist also, warum Sie oder Ihr Team jQuery einem anderen JavaScript-Framework vorgezogen haben.

Hinweis: Obwohl ich weiß und zugebe, dass jQuery ein großartiges Framework ist, gibt es andere Optionen und ich versuche zu entscheiden, warum jQuery unsere Wahl sein sollte, im Vergleich zu dem, was wir derzeit verwenden ( MooTools ).

Andrew Moore
quelle
3
Selektoren, Verkettung, Plugins, kompatibel mit anderen JS-Bibliotheken, einfach zu schreibende eigene Plugins und Selektoren, Standard. Ich wette, Sie könnten das OOP-Plugin für jQuery sehr schnell schreiben. Ich hoffe, jeder wird zu jQuery wechseln, da es einfacher ist, das Plugin zu verwenden als den komplizierten JS-Code von jemandem.
IAdapter
4
@ Andrew Moore: Ich glaube, dass eine weniger einfühlsame Frage zu weniger negativen Darmreaktionen geführt hätte. Zum Beispiel könnten Sie einige Dinge aufgelistet haben, die Sie in MooTools leicht tun können und wie sie in jQuery gelöst werden können.
Tomalak
26
Jemand, bitte öffnen Sie diesen Beitrag erneut. Aus diesen Diskussionen kann man viel lernen. Diese Jagd nach dem Abschluss ist bereits zu weit gegangen
CDR
4
@ 01: Tatsächlich ist es ein weit verbreiteter Gedanke, dass die einmalige Verwendung einer Plattform und / oder eines Frameworks in einem Ökosystem in Bezug auf Sicherheit und Fortschritt eine schlechte Sache ist. Wenn ein Konkurrent die Mehrheit hat, entwickelt sich das Ökosystem nicht weiter [und deshalb hatten wir so lange ein Monster wie IE6, das den Markt dominiert].
Andrew Moore
3
@ Andrew Moore. Die bloßen Zahlen von jQuery haben jedoch den Vorteil, dass sie gegen neue Browser zukunftssicher sind. Wenn Upgrades für die Browser herauskommen (und wenn neue mobile Browser für neue Telefone herauskommen), werden sie mit mehr jQuery-Seiten als Moo-Seiten getestet. Wenn jQuery der "Standard" ist, den die meisten Seiten verwenden, müssen sich die Browser daran anpassen, damit zu arbeiten, und nicht umgekehrt.
Nosredna

Antworten:

62

Das ist eine seltsame Frage ... Ich habe den Eindruck, dass ...

  1. Sie sind mit mootools bestens vertraut und nutzen das OOP-Modell voll aus, sodass Ihr Code bereits einfacher zu verwalten und zu unterstützen ist.
  2. Sie erkennen, dass der Zweck von jQuery etwas anders ist und in Richtung DOM-Manipulation und AJAX optimiert wurde und dass Mootools alles tun, was jQuery tut UND noch einige mehr.
  3. Klingt so, als müssten Sie nicht viel für Plugins von Drittanbietern verwenden, was die Popularität und Unterstützung von jQuery etwas weniger wichtig macht.

Fazit: Ist es der Hype? jQuery verwandelt sich in eines dieser magischen Marketing-Schlagworte wie 'AJAX', .NET und Web 2.0 - was für sie großartig ist, aber warum müssen Sie es rechtfertigen, bei dem Framework zu bleiben, das für Sie so gut funktioniert? Es gibt auch die geschäftlichen Überlegungen, von denen ich mir vorstelle, dass sie Dinge abdecken wie:

  • Die Langlebigkeit des Frameworks oder Mootools werden angesichts der ständig wachsenden jQuery wahrscheinlich verschwinden - sehr zweifelhaft, da sie gerade 1.3 Beta 1 veröffentlicht haben und 2.0 bis Ende des Jahres in der Pipeline stehen.
  • Kosten für Mitarbeiter und deren Schulung (Ich stelle mir vor, dass es schwieriger sein wird, Mootools-Programmierer zu finden, als solche, die Fragen in ihren Lebenslauf aufnehmen).
  • Zeit (und Kosten) für die Wartung und Erweiterung Ihrer Systeme in jedem Framework unter Berücksichtigung Ihrer Ressourcen.

Beide Frameworks sind großartig, aber ich glaube, dass Ihre Interessen am besten darin bestehen, bei mootools zu bleiben.

Dimitar Christoff
quelle
30
Das ist die Entscheidung, die ich auch getroffen habe. Am Ende sagte ich schließlich mit Mootools. Tatsache ist, ich habe gesehen, dass viele Entwickler jQuery in ihren Lebenslauf aufgenommen haben und absolut keine Ahnung hatten, was document.getElementById () getan hat, und tatsächlich nur einen sehr kleinen Hinweis darauf, was jQuery im Allgemeinen war, außer 'es ist die Sache mit das $ -Zeichen '. Das ist die Gefahr bei Schlagworttechnologien. Die Leute fangen an, es in Lebensläufe zu schreiben, selbst wenn sie nur eine vage Vorstellung davon haben, was es ist.
Andrew Moore
2
Angesichts der jüngsten Entwicklung könnten Sie auch das Beste aus beiden Welten haben. Schauen Sie, was für ein wunderbares Stück Magic Mootools-Kernentwickler Ryan Florence vor einiger Zeit implementiert hat: ryanflorence.com/…
plouh
60

Persönlich macht jQuery genau das, was ich brauche.

Ich versuche, die meisten meiner Aufgaben in meinem serverseitigen Code zu erledigen, der gut strukturiert ist: Er verfügt über eine ordnungsgemäße OOP, Ebenen und eine MVC-Architektur. Wenn ich brauche etwas mit Javascript zu tun, ich habe (bisher) festgestellt , dass jQuery hat , was ich brauche. Ehrlich gesagt fällt das in drei Kategorien:

  • Einfache DOM-Manipulation , die normalerweise Dinge ein- / ausblendet, ohne den Server zu treffen.
  • Ajax ruft an , sagte Nuff.
  • Vorteile der Benutzeroberfläche , einschließlich modaler Popups, Animationen und verblassender Übergänge von / zu versteckt / angezeigt. Ich bin ein Hardcore-Backend-Codierer, und ich mag UI-Sachen. Ich mag es wirklich, dass ich mit jQuery programmgesteuert Dinge erstellen kann, die ansprechend aussehen.

Darüber hinaus ist die jQuery-Plugin-Bibliothek riesig, und ich habe einige Bibliotheken gefunden, die meine clientseitige Arbeit vereinfachen. Gutes Zeug.

MooTools führt OO-Denken ein, was nett ist, aber nicht das, was ich brauche. Ich möchte meine Struktur im Backend behalten und muss dieses Denken nicht in meinen clientseitigen Code einführen. Für mich ist clientseitiger Code ein sehr kleiner Teil der Betonung, und aus Sicht der Klasse darüber nachzudenken ist viel übertrieben und viel mehr Arbeit. Ich habe das Gefühl, ich würde zwei Anwendungen anstelle von einer erstellen, wenn ich die Best Practices für MooToools verwenden würde.

Ich denke, das fasst zusammen, warum es so beliebt ist, besonders hier. Im Großen und Ganzen sind wir Leute vom Typ Backend-Code, und mit jQuery können wir programmgesteuert eine ansprechende Benutzeroberfläche erstellen und uns auf unseren Backend-Kern konzentrieren.

JoshJordan
quelle
6
+1 auf den einfachen UI-Vorteilspunkt - Ich hasse UI-Programmierung und es ist einfach fantastisch,
Jonathan Rupp
3
Eine kurze Frage: Was hat das Ein- / Ausblenden von Elementen mit dem Server zu tun (siehe "Einfache DOM-Manipulation")?
Steve Harrison
9
Hinweis für sich selbst: Konstruktive Antworten in Threads mit Meinungen bringen Ihnen immer noch negative Stimmen: /
JoshJordan
2
@ Andrew Moore: Geschätzt :) Ich bin überrascht, dass ich hier 3 Abstimmungen erhalten habe - ich wünschte, die Leute würden ihre Argumentation veröffentlichen, damit ich die Antwort besser ausarbeiten könnte. Ich hoffe, das hat geholfen, und ich wäre auf jeden Fall daran interessiert, Ihre Gedanken zu dem, was ich gepostet habe, zu lesen. Kritik an einem dominanten (oder gar nicht dominanten) Paradigma ist eine gute Sache!
JoshJordan
5
Meine am besten bewertete Antwort ist auch bei weitem meine am schlechtesten bewertete. Es steht immer noch bei 14 Stimmen in der Bilanz. Einige Leute hassen es einfach, wenn Sie eine Technologie loben, die sie nicht mögen, oder Fehler in einer Technologie erwähnen, die sie tun, und sie lassen diesen Hass durch Abstimmung aus.
Chuck
16

Ich bin kein Fan davon, JavaScript klassische Objektorientierung aufzuerlegen. Es gibt so viele Möglichkeiten, dass ein JavaScript-Programmierer Base2 für OO verwendet, während ein anderer Prototype oder Moo oder JS.Class oder Joose verwendet. Resig hat bewusst beschlossen, jQuery keine Klassen hinzuzufügen, und dies hat die Benutzer dazu ermutigt, nativere JavaScript-Methoden zur Lösung von Problemen zu finden.

Infolgedessen ist es für mich einfacher, JavaScript zu lesen, das andere jQuery-Autoren schreiben, und jQuery-Code zu schreiben, der für andere leichter zu lesen ist. Normalerweise versuche ich nicht, die Klasse OOP in JavaScript zu emulieren. Stattdessen erstelle ich Objekte im laufenden Betrieb und gebe sie weiter. Außerdem habe ich viele Arrays von Objekten. Es ist so leicht zu verstehen, dass ich dieses Denken sogar auf OOP-Sprachen übertragen habe!

Soweit ich weiß, hat Moo jQuery möglicherweise eingeholt oder übertroffen. Aber ich kann meine Zeit nicht damit verbringen, die 6 oder 7 großartigen JavaScript-Bibliotheken zu verfolgen, um zu sehen, welches Pferd vor mir liegt.

Ich denke, es war größtenteils eine Frage des Timings. Als Massen von Programmierern in AJAX sprangen, war jQuery die heiße neue coole Sache, die ihre Probleme löste.

Andere Bibliotheken haben weitgehend aufgeholt. YUI, ExtJS, Dojo, Moo - sie sind alle großartig. Aber ich kann sie nicht alle benutzen.

Ich arbeite hart genug versucht , die Auswirkungen der neuen Funktionen der Bibliothek , die ich , um herauszufinden , tue Einsatz. Zum Beispiel hat jQuery ab 1.3 Live-Ereignisse hinzugefügt. Dadurch konnte ich tatsächlich Code von vielen Seiten ausschneiden. Bietet Moo das jetzt auch an und woher soll ich wissen, dass es passiert ist, wenn es passiert ist?

Ich bin sicher, Moo ist großartig. Ich würde gerne die Zeit haben, es zu lernen. Aber hast du dir Dojo angesehen? Ich musste es für ein Projekt verwenden und stellte fest, dass es auch die meisten großartigen Ideen von jQuery übernommen hatte. Und es hat Pubsub und gute Unterstützung für Comet.

Ich fühle mit dir. Aber Ihre Programmierer sprechen vernünftig. Das Erlernen von jQuery ist gut für ihre Karriere, und es gibt mehr Bücher, Beispiele und andere Programmierer, die um Hilfe bitten können, wenn sie jQuery verwenden.

Wenn Sie sich doch für jQuery entscheiden, überlegen Sie genau, bevor Sie sich für eine OO-Bibliothek entscheiden. Es gibt einige coole (wie JS.Class oder Joose), aber diesen Schritt zu tun bedeutet, sich von dem Code der meisten JavaScript-Programmierer zu isolieren.

Nosredna
quelle
7
Meine Priorität ist nicht die Karriere meiner Mitarbeiter, sondern die Kundenzufriedenheit. Derzeit verwenden wir jQuery für drei (3) Projekte, und es scheint, dass das Javascript für diese Projekte im Vergleich zu MooTools-Projekten gleicher Komplexität schwieriger zu warten ist.
Andrew Moore
3
Außerdem schreibt MooTools JavaScript kein klassisches OO vor. Diese Funktion können Sie verwenden oder vollständig schließen. Tatsächlich bringt die MooTools OO-Implementierung das Beste aus prototypischer Vererbung und klassischer Vererbung zusammen!
Andrew Moore
Wenn Sie interne Erfahrungen haben, die zeigen, dass Ihre MooTools-Projekte besser laufen als Ihre jQuery-Projekte, haben Sie eine großartige Möglichkeit, Ihren Fall zu vertreten. Können Sie sagen, warum die jQuery-Projekte sauer werden? Ist das Fehlen des OOP-Modells?
Nosredna
@ Andrew, das bezweifle ich nicht. Ich sage nur, wenn ich Klassen in JavaScript sehe, stolpert es mich, weil es so viele subtile Variationen in den Implementierungen gibt. Wenn Sie sich an EINEN halten, geht es Ihnen sicher gut. Aber wie viel Prozent der JavaScript-Projekte verwenden MOO OOP? Ich wette, es ist ein kleiner Prozentsatz. Ich sage nicht, dass daran etwas falsch ist. Ich meide es einfach, weil es kein Teil der Sprache ist - es ist eine andere Sache zu lernen, die nur in einem kleinen Prozentsatz der JS-Projekte vorkommen wird, denen ich begegne.
Nosredna
1
Tatsächlich sind jQuery-Projekte aufgrund der Art und Weise, wie alles über das jQuery-Objekt ausgeführt wird, sauer geworden (oder $, wenn Sie ohne noConflict ausgeführt werden). Wir hatten auch Ketten mit ungefähr 75 Funktionen [aber ich muss meine Programmierer dafür verantwortlich machen].
Andrew Moore
11

Ich habe mir diese Frage schon eine Weile gestellt, indem ich nur versucht habe, meinen Kopf um das Argument zu wickeln. Und mit jeder Diskussion, die ich las, wurde die überwältigende Antwort "breiter angenommen - daher besser".

Ich bin einer, der beide ausgiebig nutzt. JQuery bei der Arbeit (angenommen, weil es "weiter verbreitet" war) und Mootools bei persönlichen Projekten. Infolgedessen fühle ich mich bei der Verwendung von JQuery ständig verkrüppelt. Sei es mit JSON-Unterstützung, Elementerstellung, Ereignisbehandlung ... und so weiter. Bei der Arbeit schreibe ich Ketten mit einer Länge von 75 Ereignissen ... und fühle mich dadurch schmutzig.

Mein Hauptproblem bei JQuery ist jedoch, dass es an Plug-Ins und Entwicklern von Drittanbietern an Konsistenz oder Praxis mangelt. Das anekdotische "Weitere Plug-Ins sind verfügbar" hilft mir wirklich nicht, wenn es keine Konsistenz zwischen den Plug-Ins gibt, weder strukturell noch anderweitig. Ich habe mehrere Wochen gebraucht, um das "akzeptierte" Plug-In-Modell zu lernen, und selbst dann habe ich meinen eigenen pragmatischen Stil daran angepasst, da ich Fehler und Ineffizienz in den aktuellen Strukturen finde. Es kann gesagt werden, dass es ein "Profi" ist, in den jeder springen und JQuerying starten kann. Ich bin jedoch eher geneigt, dies als "Betrug" zu bezeichnen, da Sie 30 verschiedene Möglichkeiten sehen, um etwas zu erreichen, und es schwierig ist, einen akzeptierten Standard festzulegen.

Was bedeutet es also, "JQuery zu kennen"? Bedeutet das, dass Sie wissen, wie man ein wenig .hide (). Show (). FadeIn (). FadeOut () rockt?

Wenn ich bei der Arbeit einen Gangster auf meinem JS haben muss, vermisse ich einige Mootools. Ich meine keine native JSON-Unterstützung? Komm schon......

Als Reaktion auf die „Weit verbreitet angenommen“ Antwort, wir alle wissen OSCommerce sind die „ weithin angenommen “ Einkaufswagen, und wir alle wissen , was ein Haufen Scheiße , das ist. Ich vergleiche JQuery in keiner Weise mit OSCommerce. Ich weise nur auf die fehlerhafte Antwort "Weitgehend angenommen" hin.

Was Plugins betrifft, hat der App Store für Apple was ... 100.000 Apps? 50.000 sind Furz-Apps. Sicher, es gibt viele Plugins für JQuery, aber das Verhältnis von Papierkorb zu Wert ist großartig.

Chase Wilson
quelle
7

Mit jQuery haben Sie Zugriff auf klare und präzise funktionale Programmiermethoden. Seit der Veröffentlichung der Methodenverkettung in (LINQ) in C # 3.0 funktioniert dies sehr gut für .NET-Programmierer. Der Fluss von einer Sprache zur nächsten ist also einfach. Das DOM nach einem Objekt oder einer Liste von Objekten abfragen zu können, funktioniert für uns viel besser. Es ist zuerst die Auswahlkraft von jQuery, die es so attraktiv macht, dann die Erweiterbarkeit, und natürlich sind alle damit verbundenen integrierten Funktionen gut. Die Community dahinter ist auch insofern wunderbar, als ich zuerst nachschaue, ob jemand anderes etwas getan hat, und dann versuche, es selbst zu tun, wenn keine Lösung gefunden wurde. Und zu guter Letzt ist die Tatsache, dass Microsoft in Visual Studio 10 aufgenommen wird und es unterstützt, großartig. Moo Tools, Prototype usw. können einfach nicht mit all dem mithalten.

Andrew Siemer
quelle
3
Die Community hinter jQuery ist großartig (und die Tatsache, dass es auch in VS integriert ist), ich gebe zu, aber MooTools hat die gleichen Auswahlmöglichkeiten wie jQuery.
Andrew Moore
7

JS-Frameworks sind sowieso so ähnlich. Wenn Sie schon länger mit Mootools arbeiten, bleiben Sie dabei. Aus diesem oder jenem Grund ist es viel wichtiger, Ihr Framework zu kennen, als eines auszuwählen.

Meiner Meinung nach ist mootools besser für fortgeschrittene Javascript-Programmierer, während jquery besser für Nicht-Javascript-Programmierer ist. Das ist es, was ich denke, nachdem ich beide Dokumentationen gelesen habe, wohlgemerkt, ich habe keine von ihnen verwendet. jQuery bietet keine Unterstützung für den Kern von Javascript, Funktionsbindung, Objektklonen und Thread-Stacking, um nur einige zu nennen.

Alsciende
quelle
5

jQuery macht wie jedes Framework das, was es macht, und wenn es nicht Ihren Anforderungen entspricht, sollten Sie etwas anderes verwenden. Ich benutze jQuery nicht, um komplizierte Programmierungen in Javascript durchzuführen. Ich benutze es, weil es DOM-Manipulationen und CSS3-Stil einfach macht und 95% der Zeit das ist, was ich brauche.

Jarrett Widman
quelle
5

Ich habe MooTools auch schon eine Weile nicht mehr angeschaut. Aber hier sind meine Punkte für JQuery:

  1. Konsistentes Programmiermodell (es gibt eine JQuery-Methode, die funktioniert)
  2. Hervorragende Dokumentation . Als ich anfing, hatte JQuery die beste Dokumentation da draußen.
  3. Umfangreiche Stecker von Drittanbietern
  4. Microsoft-Support - Ich bin ein asp.net-Entwickler. Dies erleichtert den Kunden das Denken. Außerdem wird es jetzt mit meinen Werkzeugen geliefert.
  5. Viele Anleitungen für den Einstieg.
  6. Die Website von JQuery sieht besser aus als die Website von MooTool. Es tut mir leid, dass das wichtig ist, aber es tut es. Denken Sie daran, dass viele dieser Tools sowohl Designer als auch Entwickler ansprechen müssen.
Chris Brandsma
quelle
5

YAGNI.

Ja, es ist hier irgendwie fehl am Platz, aber das ist der Hauptgrund, warum jQuery eine größere Basis als MooTools hat. Alle diese Extras, die MooTools auf den Tisch bringt, sind nett, aber YAGNI.

Es geht nicht um das Beste, es geht darum, zufrieden zu sein - die angemessene Lösung für das vorliegende Problem zu finden. jQuery ist einfach zu bedienen, sein Hauptziel ist die DOM-Manipulation. Da 95% der Leute, die Javascript lernen, dies nur tun, um das DOM zu manipulieren, macht es keinen Sinn, die längere MooTools-Lernkurve zu durchlaufen. MooTools bringt einfach nichts auf den Tisch, was jQuery nicht mit weniger Aufwand liefert.

MooTools fordert mehr von Ihnen, bevor Sie es verwenden. Mit jQuery können Sie schnell etwas zusammenwerfen. Wenn Sie anfangen, große, leistungsstarke js-Apps zu schreiben, stoßen Sie möglicherweise auf einige der Nachteile dieses Ansatzes, aber auch hier tun 95% der Leute, die js schreiben, dies nicht, sodass diese Dinge für sie keine Rolle spielen. Sie verwenden eine serverseitige Sprache für das Heavy-Lifting und Javascript für das DOM.

In diesem Fall sind sie möglicherweise auch für Ihr Team nicht von Bedeutung. Punkt für Punkt, um Sie durch die Listen zu führen (zuerst jQuery):

Große Unterstützergemeinschaft - für das Projekt nur wenig relevant. Von größerer Relevanz für das Team persönlich, weil es das Leben nach Ihnen anspricht. Wenn das Unglück zuschlägt (bitte, Gott, nein) und Ihre Firma weg ist, bekommt jQuery mehr Jobs als MooTools.

Plugin Repository - sehr relevant, da es hilft, das Rad nicht neu zu erfinden.

Integration in ASP.NET und VisualStudio von Microsoft - sehr relevant, wenn Sie ein .NET-Shop sind. In der Tat sollte dies allein der Grund für einen Wechsel sein, wenn Sie .NET ausführen.

Wird von Microsoft, Google und anderen verwendet - wen interessiert das?

Nun zur MooTools-Liste:

Objektorientiertes Framework mit klassischer OOP-Emulation für JS - irrelevant, es sei denn, die Art Ihrer Projekte macht dies zu einem Plus. Ich weiß nicht, was Sie bauen, aber für Webshops ist dies nur selten relevant. Die meisten Webshops haben nicht genug Code, um dies zu einem Plus zu machen.

Erweiterte native Objekte - wiederum für die meisten Webshops irrelevant

Höhere Konsistenz zwischen Browsern für die Unterstützung nativer Funktionen. - Relevant

Einfachere Wiederverwendung von Code - Dies steht in geringem Widerspruch zum jQuery-Vorteil eines großen Repositorys. Ein großes Repository allein spricht für die Wiederverwendung von Code. Ich vermute, Sie verwenden hier eine enge Definition der Wiederverwendung von Code, die möglicherweise nicht relevant ist. Ich habe einen Großteil des von mir erstellten jQuery-Codes sowie des MT-Codes wiederverwendet.

Wird vom World Wide Web Consortium, Palm und anderen verwendet. - Irrelevant. Die einzige Relevanz darüber, wer sonst noch was verwendet, ist, wenn Sie dort einen Job suchen. Es ist relevanter, wie viele Geschäfte es verwenden, als in einem bestimmten Geschäft, das es verwendet.

Es gibt keinen einzigen wahren Weg, sich der Javascript-Codierung zu nähern. Schieben Sie Ihre Vorurteile aus dem Weg, setzen Sie sich mit Ihrem Team zusammen und bringen Sie auch deren Vorurteile aus dem Weg. Sprechen Sie mit der Türkei über die spezifischen Arten von Projekten, die Sie durchführen (und durchführen möchten), und über die Stärken jeder Bibliothek, die auf diese Fälle angewendet werden. (Wie sie mit anderen Fällen umgehen könnten, spielt keine Rolle, da diese anderen Fälle nicht existieren.) Daraus sollten Sie einen Konsens erzielen.

(YAGNI = Du wirst es nicht brauchen, wenn ich es erklären muss.)

Arlen
quelle
1
Ich verstehe nicht, warum Sie sagen, dass MooTools mehr von Ihnen verlangt, um ein Ergebnis zu erzielen. Sie müssen OOP nicht mit MooTools verwenden, wenn Sie dies nicht möchten. Mit Code-Wiederverwendung meine ich nicht Kopieren-Einfügen. Ich meine zum Beispiel das Erstellen einer PointedTips-Klasse, die dann auf Elemente angewendet werden kann, indem neue Punkte ausgeführt werden ($ ('# myElement')) [jQuery hat stattdessen Plugins: $ ('# myElement'). PointedTips ()].
Andrew Moore
Und MooTools hat ein Plugin eines Drittanbieters für die Integration mit VS. Ich hätte sagen sollen "Out of the Box Integration". Aber wir sind eine PHP-Box.
Andrew Moore
Sie geben genau dort ein gutes Beispiel für meinen Standpunkt. In MooTools erstellen Sie eine Klasse, in jQuery schreiben Sie 1-2 Zeilen js. Der Ansatz von MT ist passend, wenn Ihr Ziel darin besteht, eine komplizierte App in js zu erstellen, aber die meisten Leute verwenden js nur, um einen Spezialeffekt zu erzielen, und das ist im Allgemeinen eine Zeile jQuery-Code. Ich sage nicht, dass jQuery immer besser ist, ich sage "Pferde für Kurse". Sehr oft kann das, was Sie versuchen, in jQuery schneller und einfacher erledigt werden, daher seine Popularität.
Arlen
4

Ich habe mich für jQuery als Standard-UI-Bibliothek entschieden, gerade weil es im Gegensatz zu prototype.js oder mootools keine nativen Objekte erweitert oder anderweitig monkeypatchet. Treten Sie in den Dokumentationswinkel ein und es gibt wirklich keine Frage, welches Framework verwendet werden soll.

Wyatt Barnett
quelle
Ich habe mir gerade die Website von MooTools angesehen. Die Zunahme einheimischer Typen macht mich nervös, aber ich mag, wie sie Hashes gemacht haben. mootools.net/docs/core/Native/Hash
Nosredna
2

Du sagst es irgendwie selbst:

Angesichts dessen scheint MooTools alles zu tun, was jQuery tut und mehr (einige Dinge, die ich in jQuery und in MooTools nicht tun kann), aber jQuery hat eine kleinere Lernkurve.

Die meisten zusätzlichen Dinge, die MooTools macht, sind Dinge, die wir einfach nicht brauchen .

Wie Sie selbst sagen, ist jQuery leichter zu erlernen, was für die meisten Menschen bei der Auswahl eines Frameworks tatsächlich wichtiger ist.

Keith
quelle
1

Was ich in JavaScript NICHT brauche, ist definitiv OOP und eine hässliche Objektemulation.

Als ich das letzte Mal MooTools überprüft habe (vor vielleicht 1,5 Jahren :-), hatte es Browser-Inkompatibilitäten mit der Manipulation von Multiple Select.

JQuery sieht für mich also völlig in Ordnung aus.

Sergei
quelle
1

JQuery ist nicht nur eine nette Bibliothek, sondern sein Schöpfer, John Resig, hat auch einen gewissen Ruf als Autor von Pro Javascript Techniques .

Wir haben 2-3 Exemplare dieses Buches in unserem Büro.

jQuery ist klein (absichtlich), kann aber über Plugins um Funktionen erweitert werden.

Powerlord
quelle
1

Was meine Erfahrung mit Mootools ziemlich unangenehm machte, war die Dokumentation und die Stabilität der API: Ich konnte einfach keine Dokumentation finden, die sich auf die verwendete Mootools-Version bezog. Wird kein so großes Problem sein, wenn die definierte API stabil ist. Aufgrund einiger Funktionen, die in der neueren Version verschwunden sind (nach stundenlangem Suchen wurde ein ChangeLog gefunden), war eine Migration ebenfalls nicht möglich. Danach war mootools für mich aus dem Rennen.

Wie viele andere möchte ich klassenbasiertes OOP nicht in einfache Manipulationen der Benutzeroberfläche einführen. Dafür benutze ich jQuery: nicht so komplizierte Dinge für die Benutzeroberfläche. Wenn ich umfangreiche browserbasierte Anwendungen erstellen muss, wechsle ich immer zu den großen Lösungen (ExtJS, YUI, qooxdoo), die eine Vielzahl gebrauchsfertiger Widgets bieten.

Martin Schuhfuß
quelle
1

Eine größere Benutzergemeinschaft und eine breitere Akzeptanz machen einen großen Unterschied beim Vergleich von Tools / Bibliotheken, die ähnliche Funktionen und Konzepte bieten. Eine größere Community bedeutet mehr Unterstützung, mehr Beispiele, mehr gute Ideen und mehr wiederverwendbare Codefragmente. Dies ist besonders wichtig, wenn Sie an einem seltenen Szenario arbeiten - wahrscheinlich ist es schon jemand anderem begegnet.

Zweitens ist jQuery in Benchmarks, die ich gesehen habe, schneller als MooTools.

Ich mag auch ihre Betonung darauf, einen kleinen Kern zu behalten und Funktionen durch Plugins hinzuzufügen. Verhindert, dass die Kernbibliothek wirklich groß und unhandlich wird.

Ich habe MooTools noch nie persönlich verwendet, aber ich habe keinen Zweifel daran, dass es eine fantastische Bibliothek ist, die ein akzeptables Äquivalent zu den meisten jQuery-Funktionen oder -Konzepten bietet, aber Punkt 1 nimmt den Kuchen für mich.

Brian Lacy
quelle
Über den Geschwindigkeitsanspruch: domassistant.com/slickspeed
Andrew Moore
Ich habe in Chrome und Firefox getestet und MooTools hat viel schlechter abgeschnitten als jQuery.
Nosredna
2
Bei mehreren Tests in allen fünf gängigen Browsern auf mehreren Computern ist mein durchschnittliches Ergebnis in der Regel, dass jQuery und MooTools eine vergleichbare Leistung erbringen, jedoch mit einem spürbaren Vorteil für jQuery. Der Prototyp bleibt deutlich zurück, während YUI in ALLEN Tests ein klarer und tragischer Verlierer ist. Auf jeden Fall scheinen diese Tests darauf hinzudeuten, dass die Leistung bei der Wahl zwischen jQuery und MooTools NICHT Ihr Hauptanliegen sein sollte, da sich MooTools gut genug behauptet. Danke für den tollen Link Andrew!
Brian Lacy
1

Ein weiterer Grund: Es ist einfacher, jquery an das Management zu verkaufen. Bei der internen, asp.net-basierten Entwicklung in einer Unternehmensumgebung lauten die magischen Worte "Es wird von Visual Studio unterstützt".

chris
quelle
Das ist mir eigentlich egal, da ich das Management bin und wir kein ASP.NET entwickeln.
Andrew Moore
3
Sie haben gefragt, warum jQuery weiter verbreitet ist und nicht, warum Sie es bevorzugen.
chris
0

Zum einen ist das nicht alles. Es gibt durchaus ein paar andere Funktionen als gut . Zum anderen benutzt es nicht jeder. Aber ich möchte kein gutes Geschwätz unterbrechen.

Matthew Flaschen
quelle
2
Es ist kein Scherz, ich habe beide benutzt, habe die Kraft von jQuery gesehen. In jQuery kann ich jedoch nichts tun, was ich in MooTools nicht tun kann, während das Gegenteil nicht der Fall ist. Ich mag jQuery nicht, ich verstehe nur nicht genau, warum es so weit verbreitet ist.
Andrew Moore
0

Ich muss viele der Antworten unterstützen ... eine großartige Dokumentation und Community-Unterstützung sind von entscheidender Bedeutung. Früher hasste ich js Programmierung und mied es wie das Messgerät, aber jetzt habe ich es wegen jquery und der schnellen Lernkurve vollständig angenommen.

Es geht nicht immer darum, wer die beste Technologie hat!

ScottE
quelle
0

Mootools funktionieren nicht richtig oder überhaupt nicht, wenn ein jquery-Prototyp usw. verwendet wird. Es gibt absolut keinen Grund, sie gleichzeitig zu verwenden, aber hin und wieder landen sie auf derselben Seite (z. B. Plugins, Diashows, Widgets) etc) und die Dinge funktionieren nicht mehr.

Das an sich ist inakzeptabel. Also alle Requisiten für jquery, um keine unnötigen Kopfschmerzen zu verursachen!


quelle
4
@Dheer: Das gilt nicht mehr für die neueste Version, und es gibt absolut keinen Grund, warum man mehrere JavaScript-Frameworks verwenden würde, außer mangelnde Planung.
Andrew Moore
0

Warum haben die Leute angefangen, Faxgeräte zu benutzen? Ab einem bestimmten Punkt steigt der Nutzen exponentiell an.

Scott
quelle
1
Es ist keine Frage, ob ich Faxgeräte verwenden soll oder nicht, ich habe die Leistungsfähigkeit von Faxgeräten gesehen und die Notwendigkeit dafür verstanden. Ich frage, warum HP Faxgeräte beliebter sind als Samsung Faxgeräte, wenn Samsung alle Funktionen von HP und einige davon bietet.
Andrew Moore
1
@ Andrew Moore: Großartige Analogie.
Chase Wilson