Weniger cool ist (ebenfalls von Resig angemerkt), dass die Javascript Bibliothek prototype die Funktion im “offiziellen” Namespace implementiert hat, ohne zu testen, ob diese Methode bereits vorhanden ist. Wird prototype also im Firefox 3 eingesetzt wird die native getElementByClassName Funktion durch eine 11x langsamere Nachimplementierung überschrieben.

So viel zum Thema Design von Javascript Bibliotheken.

Des weiteren wird es künftig drei größere Teilprojekte geben: dojo core für die low level API, dijit wird die widget engine und die wichtigsten widgets beinhalten und dojox ist der platz für eher experimentelle(?) module wie dojo.storage und dojo.chart.

Mehr Info.

Es gibt da draussen Lösungen verschiedenster Ausprägung: Tuning der Kernfunktionalität (Objekte, DOM, Event handling, XMLHttpRequests: z.B. prototype, jQuery, base2), UI bezogen mit und ohne Widgets (z.B. script.aculo.us), YUI), Spezielle Aufgaben (Lightbox, JSJaC) oder aber umfangreiche Lösungen, die eine möglichst große Bandbreite abdecken (Dojo toolkit, prototype + script.aculo.us).

Fraglich ist, ob man eher auf eine möglichst umfangreiche Lösung bauen sollte oder eine Mischkultur aus Mini Bibliotheken, bzw. Module aus verschiedenen Bibliotheken setzen sollte. Dazu hier mal einige Überlegungen:

Monokultur

• Keine Kompatibilitätsprobleme (siehe http://erik.eae.net/archives/2005/06/06/22.13.54, selbst erfahren mit prototype und JSJaC)
• Weniger Code, da Basismodule (mylib.base) nicht redundant sind
• Mehr Code, da eine Komplettlösung, vor allem wenn sie nur eingeschränkt modularisierbar ist (durch Buildmechanismen) – aufgebläht sein kann
• Einfacher aktuell zu halten (Entwicklung verfolgen, eine Codebase)
• Abhängigkeit vom Erfolg, der Weiterentwicklung der Bibliothek
• Falls Contrbution: einfacher, weil nur ein Projekt

Mischkultur

• Spezialbibliotheken bieten bessere Lösungen für bestimmte Aufgaben, da Autoren Experten auf diesem Gebiet sind (UI, DOM). Umgekehrt werden ggf. an große Bibliotheken weniger gute/gut gepflegte Lösungen angeflanscht
• Weniger Code, wenn Lösungen sich ergänzen, nicht redundant sind
• Mehr Code …
• Inkompatibel, wenn Javascript Objekte erweitert werden
• Mehr Möglichkeiten
• Höherer Aufwand für Beobachtung und Aktualisierung der einzelnen Lösungen

Eines der Hauptprobleme meines Erachtens: Basisfunktionen müssen immer vorhanden sein, hier gibt es schnell Redundanz (getElementsByClassName, inArray). Ich bin mir selbst nicht sicher, was ich grundsätzlich bevorzugen soll. Vermutlich würde ich die Entscheidung jeweils von der aktuellen Problemstellung im Projekt abhängig machen. Je kleiner, vorhersehbarer es ist bezüglich der Funktionalität, desto eher würde ich auf eine Mischkultur setzen.

Passend zum Thema hat Dean Edwards einige Regeln für Autoren von Javascript Bibliotheken aufgeschrieben, welchen ich sehr zustimme.

Was mein Ihr?