jQuery 1.7 ist draussen und schon wird ein RC für die Version 1.7.1 nachgeschoben. Neuerungen sind on()und off(), die zukünftig statt delegate() und live() genutzt werden sollen.
Bei jQuery macht man sich daran, die Codebasis umzubauen. Auf mittlere Sicht soll der Code schlanker werden. Eine von mir in einem Blogkommentar vorgeschlagene Modularisierung findet bei anderen Nutzern viel Anklang. Die Core-Entwickler von jQuery hingegen sind da vorsichtiger.
Im Rahmen des Vortrages „The state of jQuery“ des jQuery Summit fragte ich, ob denn eine Modularisierung angedacht sei. Addy Osmani machte mir keine allzu grossen Hoffnungen, aber er meinte, sie würden es zumindest durchdenken und prüfen. Zuversicht hörte sich zumindest für meine deutschen Ohren anders an.
Ich hoffe, sie kommen in übersichtlicher Zeit in diesem Punkt voran. Aktuell dürften die meisten jQuery-Nutzungen auf einem kleinen Bruchteil der gesamten Bibliothek beruhen, die von Version zu Version umfangreicher wird. Ich finde, die meisten Bereiche sollten als Plugins abgespalten werden, die dann mit dem Kern zusammenarbeiten. So kann man sich bei mootools und YUI schon immer seine persönliche Bibliothek zusammenbauen und auch jQueryUI bietet dies an. jQuery selber sollte auch in diese Richtung gehen.
18. November 2011 um 7:18 Uhr
Was ich mir in dem Zusammenhang angeschaut habe ist Ender. Auf den ersten Blick mag es etwas verwirrend aussehen, man bekommt aber damit einen Rahmen zu Verfügung gestellt, in dem man sich benötigte Funktionen selbst zusammenstellen kann. Das Grundgerüst (DOM-Ready, Events, Selector Engine und DOM-Tools) ist grade mal 7.5kb groß und von der Syntax her weitgehend identisch mit jQuery. Weitere Komponenten (z.B. Ajax-Handler) gibt es auf GitHub.
Wenn man also nicht auf jQuery-Plugins angewiesen ist (einige laufen sicher mit Anpassungen auch auf Ender), ist es eine interessante, schlanke Alternative.
18. November 2011 um 7:23 Uhr
Ja, ender hatte ich mir auch schonmal angeschaut, als es rauskam. Das Tolle an jQuery ist ja seine Einfachheit und das Ökosystem drumherum. Selbst wenn ender genau so einfach ist, möchte ich das Ökosystem, also die Plugins, nicht missen. Und ich fürchte, eine Anpassung von Plugins ist nicht trivial und demnach zeitaufwändig. Deshalb gebe ich die Hoffnung auf ein schlankeres jQuery nicht auf.
Es ist halt schon blöd, wenn man wie ich auf meiner Seite jQuery nur zum bequemen Auf- und Zuklappen von Conatainern (mit gleichzeitiger ARIAfizierung) nutzt. Das ganze AJAX-Zeug brauche ich dann ebensowenig wie den meisten anderen Kram.
18. November 2011 um 7:29 Uhr
Es ist schon was tolles das Ganze zu modularisieren, da man sicherlich viele zusätzliche last wegschmeißt.
Allerdings muss ich da anmerken: YUI oder moo-tools, selbst jquery-ui ist mir persönlich viel zu umständlich mit dem „klicke dir die lib zusammen“. Darauf hat kaum einer Lust (behaupte ich einfach mal). Ich glaube aus diesem Grund wollen die jQuery-Bauer auch soetwas nicht anfangen.
18. November 2011 um 8:22 Uhr
Klar, das will nicht jeder. Aber das ist ja auch nicht schlimm, denn die können ja auch die Vollversion nehmen. Auch Modernizr nutzt diesen Ansatz. jQuery ist die mit Abstand am weitesten verbreitete JavaScript-Bibliothek, da macht es schon Sinn, ein wenig Hirnschmalz auf die interne Organisation zu verwenden. Ich gebe die Hoffnung nicht auf.
18. November 2011 um 8:55 Uhr
Ich gehe an dieser Stelle mit Chris d’accord. jQuery hat das Feld für aufwendiges JavaScript längst anderen Libs (Dojo, Backbone, etc.) überlassen. Jeder der sich Gedanken um Modularisierung macht ist bei jQuery vermutlich schon falsch.
Bei jQuery geht es doch darum schnellstmöglich zum Ergebnis zu kommen. Wenn man mit einer Vorstellung für eine Animation beginnt und dann später merkt, dass man doch noch was mit AJAX nachladen möchte, müsste man im Fall einer Modularisierung erst mal wieder zu jquery.com und zusammenklicken.
Wenn ich die Vollversion und eine spezialisierte zusammengeklickte Version laden könnte, wäre eben mindestens ein
Entscheidungsschritt mehr zu treffen.
Ich möchte hier nicht sagen, dass jQuery NUR was für unüberlegte Anfänger ist, John Resig wird diese aber sicherlich im Hinterkopf haben und ungern verlieren wollen.
18. November 2011 um 9:17 Uhr
Klar, nicht jeder braucht ein modularisierte JavaScript-Bibliotheken, für viele reicht der „Komplettpaket“-Ansatz völlig.
In wie weit Ender & Co. kompatibel mit jQuery-Plugins sind, habe ich bisher in der Praxis nicht ausprobiert. Aber für den von dir zitierten Use-Case „zum bequemen Auf- und Zuklappen von Containern (mit gleichzeitiger ARIAfizierung)“ würde ich persönlich nicht unbedingt jQuery verwenden, wenn das die einzige benötigte Funktionalität der Website wäre. Wenn man hingegen viele Features nutzt, Plugins einsetzt, etc. ist jQuery ohne Frage natürlich sinnvoll.
Im Bereich mobiler Webseiten/Web-Apps hingegen ist aber ein Punkt wie Modularität und Datenübertragungsvolumen ein wichtiges Thema. So kommt z.B. bei der Benutzung von jQuery Core+jQuery Mobile doch einiges zusammen. Und so toll und wichtig ich das Framework auch finde, muss man meiner Meinung nach immer ein Auge darauf haben, ob das gewählte Tool auch das sinnvollste für den Job ist (das gilt für alle verwendeten Tools, Frameworks, etc).
Deshalb von mir ein klares „Ja, bitte“ zu einem modularen jQuery.
18. November 2011 um 10:48 Uhr
Ich finde die Frage deshalb spannend, weil sich meine Meinung dazu über die Zeit mehrfach geändert hat.
Wenn ich einen Blick über die jQuery-API werfe, dann muss ich sagen, dass ich nicht wüsste, welchen Teil von jQuery ich besser nicht im Projekt haben wollte. jQuery ist in seinem Ansatz bereits außerordentlich DOM-zentriert und die Größe zum großen Teil der crossbrowser-Funktionalität geschuldet, die ich nicht missen möchte. Dazu kommt, dass ich mir bei 31kB der Produktivvariante echt keine Gedanken um die Dateigröße mache – da presse ich aus jeder Headergrafik wenn es sein muss mehr Ersparnis raus, als hier eine Modularisierung von jQuery an Einsparpotential versprechen würde.
Bei jQuery-UI ist die Fragestellung schon viel sinnvoller und genau da ist die Modularität bereits gegeben. Insofern stellt sich auch hier das Problem nicht.
Relevant ist die Frage aus meiner Sicht nur bei Kleinstprojekten. Und genau hier lösen CSS3 Animationen und HTML5 mittelfrisitig die Probleme, einfache Slider oder aufklappende Seitenbereiche zukünftig sehr einfach ohne JS-Einsatz erstellen kann. Außerdem gibt es für diesen Bereich zahlreiche Microframeworks, die genau dafür entwickelt wurden.
Die Diskussion ist auch im aktuellen WorkingDraft-Podcast geführt worden und den darin erwähnten Standpunkt teile ich. Das Problem ist in aller Regel nicht jQuery, sondern es sind stümperhaft programmierte Plugins, die teilweise mit aberwitzig viel Code daherkommen und ebenso aberwitzige Performance/HTML-Codequalität mitbringen.
Viel mehr Bauchschmerzen habe ich mit den API-Änderungen von jQuery, die mit 1.6 und 1.7. Diese sind grundsätzlich richtig, jedoch zeichnete sich jQuery bisher dadurch aus, dass es seit 1.0.3 eigentlich keine nennenswerten API-Brüche mehr gab. Hier wird für die Zukunft ein System wichtig, dass über die Verwendung von „deprecated“ APIs zur Laufzeit informiert – mindestens in der Developer-Fassung. Anders werden die schnellen Releasezyklen bei größeren Projekten nämlich mittelfristig zur Tortur.
25. November 2011 um 22:28 Uhr
Viel mehr Bauchschmerzen habe ich mit den API-Änderungen von jQuery, die mit 1.6 und 1.7. Diese sind grundsätzlich richtig, jedoch zeichnete sich jQuery bisher dadurch aus, dass es seit 1.0.3 eigentlich keine nennenswerten API-Brüche mehr gab. Hier wird für die Zukunft ein System wichtig, dass über die Verwendung von “deprecated” APIs zur Laufzeit informiert – mindestens in der Developer-Fassung. Anders werden die schnellen Releasezyklen bei größeren Projekten nämlich mittelfristig zur Tortur
Die von Dirk genannten Bauchschmerzen befallen mich auch seit geraumer Zeit. Im vergangenen Projekt noch mit .live gearbeitet, im aktuellen mit .delegate und im nächsten Projekt ist dann .on das neue Kind auf der Wiese, das den Spielführer macht. Auch wenn ich es mir bei jQuery integrativer wünsche, ist der prototype.js helper zur der Zeit eine dankbare Sache gewesen.
So sehr ich auch Jens‘ Argumente verstehe und bspw. ebenfalls die partial Downloads bei modernizr toll finde, sehe ich den Vorteil tatsächlich ausschließlich bei Leuten, die sich mit der Library, deren Funktionsteilen und allg. mit Javascript gut auskennen. Viele, die mit Javascript generell nicht so vertraut sind, wissen nicht, was sie brauchen. Und will man die Lib vollständig modular anbieten, bleibt wenig übrig für ausgegraute essential part.
2. Dezember 2011 um 12:11 Uhr
Bei ToolMan habe ich einen interessanten Ansatz nur Modularisierung von Frameworks gesehen. Im Core ist eine Methode implementiert, mit dieser benötigte Komponenten eingebunden werden können.
Klar hat man dann mehr Dateien auf dem Server liegen, aber das, was der Server empfängt, kann individuell zusammengesetzt werden.
jQuery.getMods(new Array('ajax', 'animations'));
jQuery('#test').hide('slow');
Ist halt nur ein Beispiel. Eine weitere Möglichkeit ist Parameter an den Sourcelink zu heften: