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

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 ).

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.

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.

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.

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.

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.

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.

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.

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.

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.)

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.

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.

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.

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.

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.

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.

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".

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.

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!

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!

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