Was das prototype.js-Framework leistet …

… wenn man nur will, will ich gern noch hinzufügen. Ich wundere mich immer wieder, wenn ich merke, wie schwer sich einige Programmierer damit tun, Frameworks als das zu akzeptieren, was sie vor allem sein sollen: eine Arbeitserleichterung bei der Entwicklung von zeitgemäßen Web-Anwendungen. Im Fall des prototype.js-Framework werden sogar Argumente vorgebracht, bei denen ich schließlich nur noch missmutig den Kopf schütteln kann.

Diskussionspunkt Nummer eins gegen prototype.js ist die etwas unhandliche Größe des Pakets. Wer bei einer aktuellen WordPress-Installation unter wp-includes/js nachschaut, wird dort eine prototype-Version vorfinden, die stolze 137 kb auf die Waage bringt. Die erheblich geringere Größe von rund 77 kb wird übrigens immer wieder gern als Vorwand benutzt, um zu Gunsten von jquery zu argumentieren. Hierzu merke ich immer gern an, dass auch komprimierte prototype.js-Versionen zur Verfügung stehen, die zum Teil nur noch circa 20% des ursprünglichen Platzes benötigen.

Weiterhin wird gern vorgebracht: Man kann das alles ja auch ohne Frameworks bewerkstelligen. Das ist zwar grundsätzlich wahr, wirkt jedoch – für meinen Geschmack – etwas zu sehr verallgemeinert. Will ich nur einen sehr kleinen Teil einer Website mit einigen „Komfort-Funktionen“ versehen, stimme ich gern zu. Bei größeren Projekten bezweifle ich stark, dass dies so ohne weiteres möglich ist. Einer der Vorteile vieler moderner JS-Framworks ist ja auch die die ausgesprochen hohe Kompatiblität mit einer Vielzahl von aktuellen Browsern, und genau hier fangen viele handgestrickte Lösungen an, ihre ersten Schwächen zu zeigen. Von der Unmenge an Code, die notwendig ist, um auf allen Plattformen gleichermaßen gut zu performen, will ich garnicht erst sprechen!

Aus der Vielzahl an Funktionalität, die das komplette Framework bietet, stechen zuerst die Utility-Funktionen heraus. Anstelle von document.getElementById() kann man ganz einfach $() verwenden. Das Utility $F hingegen liefert den Wert eines Form.Elements zurück. Anstelle von getElementsByTagName läßt sich $$ einsetzen. Allerdings kann man mit dieser Funktion nicht nur bestimmte Tags, sondern auch DOM-Elemente einer CSS-Klasse oder sogar Elemente, welches ein spezielles Attribut besitzen, finden. In Verbindung mit den Observer-Funktionaliäten wird die ganze Geschichte dann richtig interessant. Der Code in meinem Artikel Mit Analytics Clicks auf ausgehende Links messen veranschaulicht das – meiner Meinung nach – ganz gut.

Und das ist noch lange nicht alles! Vor einigen Tagen habe ich eine umfangreichere Intranet-Anwendung ausgeliefert. Die Vorgaben des Projekts machten den Einsatz von JavaScript unumgänglich. Auch wenn man die Umgebung in einem Intranet meist weitgehend reglementieren kann, kommen doch die immer wieder unterschiedlichsten Browser zum Einsatz. Hier hat das prototype.js-Framework, ohne das grössere Nacharbeiten nötig waren, komplett überzeugen können. Die integrierten Ajax-Methoden im Zusammenspiel mit dem Scriptaculous-Builder sind ein echter Segen, wenn man das als Atheist so sagen darf, und der Umfang des gesamten JavaScript war schlussendlich überraschend übersichtlich.

Have fun!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.