nicht angemeldet
Und es geht durch Funktionen, die Funktionen aufrufen, die Funktionen aufrufen die Funktionen aufrufen .... auf die Performance.
Als wäre das so weit hergeholt. Erstmal wäre festzuhalten: Diese Arbeitsweise liegt in der Natur der Sprache. In einer funktionalen Programmiersprache operiert man üblicherweise mit Lambdas über Listen. Zumindest wenn man die Operationen wiederverwendbar halten will. Und das tut eine Bibliothek sinnigerweise.
Natürlich kann man in JavaScript auch imperativ wie BASIC, C oder PHP schreiben. Sämtliche Listen mit konventionellen for-Schleifen durchlaufen und den Code immer wieder im Schleifenkörper wiederholen. Ja, das muss man tun, wenn es Performance das wichtigste, alles andere überragende Ziel ist. Weil Funktionsaufrufe immer noch ziemlich viel kosten. Aber eine solche Art zu Programmieren erzeugt grässlichen Code.
jQuery ist für den Umgang mit Knotenlisten gedacht. Der jQuery-Konstruktor erzeugt eine Liste. jQuery.prototype enthält allesamt map-, filter-, each-, reduce- usw. Funktionen. Prototype ist da aufgrund seiner Ruby-Abstammung noch konsequenter, weil es erst einmal unter JS die funktionale Programmierung möglich macht, die Ruby auszeichnet. Wie man es auch dreht und wendet: Die meisten gut strukturierten Bibliotheken enden bei einem »Funktionen rufen Funktionen auf, die Funktionen aufrufen ...«.
Die Performance-Optimierung drehte sich daher in letzter Zeit darum, immer nur soviele Funktionen aufzurufen, wie gerade nötig. Dem sind naturgemäß Grenzen gesetzt bei einer API, die völlig flexibel in seiner Anwendung sein soll. Dieses Thema ist zweischneidig und ebenso differenziert müsste man es diskutieren.
Man kann sich nun quer stellen und JavaScript wie PHP schreiben. Das muss man leider tun, wenn es auf jede Millisekunde ankommt. Das ist aber nur äußerst selten der Fall. Wir schreiben aus ganz bestimmten Gründen nicht mehr ständig Assembler oder C, sondern nutzen vielseitige Sprachen wie JavaScript, mit der sich Probleme sehr konzis und aussagekräftig in Code ausdrücken lassen. Auch mit funktionalem JavaScript lässt sich performanter Code schreiben. Performance ist hier natürlich relativ zu sehen: Relativ dazu, dass man Probleme in gut lesbarem Code sehr schnell und sauber lösen kann.
Man kann aber auch versuchen, die Programmierparadigmen, die Javascript ermöglicht, auszunutzen. Nichts anderes machen die auf dem Markt verfügbaren JavaScript-Bibliotheken mit unterschiedlichen Ansätzen, in unterschiedlicher Codequalität und in unterschiedlicher Produktionsreife. Es lohnt sich auf jeden Fall, sich diese verschiedenen Arten der Programmierung anzuschauen. Und unter der Haube der Abstraktion zu schauen, wie häufige Aufgaben tatsächlich gelöst werden. Das muss nicht unbedingt uneingeschränkt besser sein als das, was man bereits kennt, aber da steckt zum Teil jahrelang gewonnenes Know-How und Optimierung drin.
Ich habe gerade mal mit jQuery 1.3.2 (hatte ich gerade irgendwoher im Cache) einen Test gemacht:
Etwas einfaches wie $('#foo) zeigt beim Erst-Aufruf im Firebug 172 Funktions-Aufrufe, davon allein 16 Mal each() und 11 Mal extend().
Bei jQuery 1.4.1 sind es nur noch zwei Aufrufe. Und was sagt uns das? Ziemlich wenig, denn mit was soll man diesen Wert vergleichen. Eine Selektor-Engine und ein Wrapper für Knoten bzw. Knotenlisten ist eben nicht mit getElementById() und der nackten DOM-API vergleichbar.
Mathias
Gunnar Bittersmann