In Bezug auf Geschwindigkeit: jQuery oder Mootools [geschlossen]
Ich habe gerade die Mootools-Dokumentation durchgesehen und scheint alles zu tun, was jQuery mit vielen zusätzlichen Funktionen macht. Unglaublich, alles passt in weniger Platz als jQuery.
Ich hatte schon immer den Eindruck, dass Mootools bei der DOM-Manipulation leichter und schneller ist als jQuery, also denke ich daran, meine nächste stark JavaScript-gestützte Seite mit Mootools zu schreiben, um die Dinge schnell zu halten.
Dies führt mich zu meiner Frage: Ist Mootools für intensive JavaScript-Anwendungen spürbar schneller als jQuery, oder bin ich dumm und vergesse das, was Donald Knuth gerne sagt?
Wenn diese Frage zu weit gefasst ist oder zur Entfernung angezeigt werden kann, können Sie bitte einen Kommentar hinterlassen und ich werde diesen Beitrag selbst entfernen. Danke.
4 Antworten
Das ist vergleichbar damit, nach einem Leistungsvergleich zwischen Go Carts und f1 Cars zu fragen, ohne zu sagen, wohin Sie fahren würden. Wenn alles, was Sie interessieren, ist DOM perf, dann Jquery (der Go-Cart) wird besser geeignet und schneller in Sachen zu erledigen. Mootools ist etwas komplexer und fortgeschritten.
Es hängt auch von den Fähigkeiten des Fahrers ab. Wenn Sie die Auswirkungen auf die Leistung beim Erstellen einer Anwendung nicht verstehen und die bewährten Verfahren nicht befolgen, wird Ihre Bibliotheksauswahl irrelevant. Es spielt keine Rolle, welches Auto vor Ihrem Haus geparkt wird, wenn Sie nicht fahren können, oder?
Also habe ich dafür gestimmt, das zu beenden. Es ist zu zweideutig ein Thema und es gibt keine einzige richtige Antwort.
Für meine 2 Cent würde ich niemals jquery verwenden, wenn ich eine Wahl hätte. Selector Geschwindigkeit ist in diesen Tagen fast identisch, was bedeutet, dass Sie basierend auf anderen Überlegungen wie Skalierbarkeit und Funktionen, Support, Plugins und verfügbares technisches Know-how, Kosten für jeden auswählen sollten. Es gibt keinen klaren Gewinner, niemals.
Sie können es mit slickspeed selbst herausfinden, aber ich weiß nicht, wie sehr Sie darauf vertrauen können:)
Generell würde ich sagen, es ist Geschmackssache.
Hier sind einige Ergebnisse aus 2009 , aber das Bild könnte sich geändert haben.
Der verbesserte Code bringt auch Leistungsverbesserungen, Dojo ist großartig, um den gesamten JS-Code zu minimieren. Auch Dojo 1.6 fügt dieses nun hinzu (übernommen von hier ):
Ein Follow-up zu Eugenes Antwort: Zusätzlich zu der massiven Infrastruktur, die es bietet, ist Dojo 1.6 auch die erste (und einzige) populäre JavaScript-Bibliothek, die erfolgreich mit dem Advanced-Modus des Closure-Compilers verwendet werden kann. Leistung und Verschleierung Vorteile, die damit verbunden sind - anders als Googles eigene Closure-Bibliothek, das heißt.
Nun, wie bereits gesagt, kann es keinen wirklichen Vergleich geben, da es zwei verschiedene Dinge mit unterschiedlichen Zielen gibt.
Die Tatsache, dass sie sich überschneiden, ist ein Grenzeffekt ...
Sie werden sicherlich einige Anwendungen schneller mit einem finden, aber Sie werden mit der anderen sicherlich schneller andere Anwendungen finden ... (Mein Glaube: weit verbreitete Anwendung wird schneller mit jQuery, wenn mehr konzeptionell einfacher und noch schneller mit mootools Aber es ist nur ein Gefühl! ;-)
Je mehr genaue Antwort auf Ihre Frage, wenn sie dort gefunden wird: JqueryVsMootools.com/#mottos wo es empfohlen wird, den Titel oder die Einleitung zur Beschreibung jeder Bibliothek zu lesen:
JQuery :
Query ist eine schnelle und prägnante JavaScript-Bibliothek, die HTML-Dokument-Traversing, Event-Handling, Animation und Ajax-Interaktionen für schnelle Web-Entwicklung vereinfacht
Mootools :
MooTools ist ein kompaktes, modulares, objektorientiertes JavaScript-Framework für den fortgeschrittenen JavaScript-Entwickler. Es ermöglicht Ihnen, leistungsstarken, flexiblen und browserübergreifenden Code mit seiner eleganten, gut dokumentierten und kohärenten API zu schreiben.
Postskriptum :
Da diese Art von Frage schon oft bei SO geschlossen wurde, denke ich, dass es eine gute Sache sein könnte, dies offen zu lassen ...
