nicht angemeldet
Mich stört an diesen „Frameworks“ (unsinniger Name übrigens) - ganz abgesehen von der Code-Qualität -
a) die schiere Größe, die man den Nutzern zumutet (das sind tw. sogar minified 70-130kB und mehr, und zwar für _jede_ Site)
Das ist einfach eine Rechnung, die man machen muss - früher hat man genauso viel in Spaghetticode geschrieben. Wenn man Bibliotheken richtig einsetzt, wird dafür der eigene Code sehr klein. Und bestenfalls nutzt man externe CDNs, sodass Standardbibliotheken auch nicht auf jeder Site neu geladen werden müssen.
b) der Versuch, alle "Probleme" lösen zu wollen und damit überdimensionierte JS-Libraries zu kreieren, von denen meist nur max. 5-10% wirklich benötigt werden
Bibliotheken lösen nicht alle Probleme, sondern die häufigsten, die einem beim DOM Scripting begegnen. Manches braucht man häufiger, manches seltener. Im Allgemeinen würde ich aber sagen, dass z.B. jQuery die Standardaufgaben der heutigen üblichen JavaScript-Anwendung abdeckt.
Sicherlich könnte man das weiter auf das Wichtigste eindampfen, aber eine Bibliothek ist eben eine Software, die verschiedenen Anforderungen genügen soll. Alleine dass eine Software mehr Features hat als ich gerade (!) benötige, ist kein Argument gegen sie.
c) das, was David Mark im Prototype-Thread mit »It is horribly inefficient. Even the lowest level code is tangled up
in syntactic sugar«. bezeichnet, nur um einen gewissen pseudo-elegant wirkenden Schreibstil hinzubekommen.
Was heißt Effizienz?
JavaScript-Bibliotheken legen viel Wert auf Performance und Standardaktionen sind sehr stark auf Performance optimiert. Überhaupt wissen wir das, was wir heute über JavaScript-Performance wissen, vor allem aus der Entwicklung von Bibliotheken. Das bekommt man zu Fuß nur hin, wenn man wirklich sehr, sehr viel Detail-Know-How hat. Das ist weder sinnvoll noch möglich für normale JavaScript-Entwickler.
Der Schreibstil ist nicht pseudo-elegant, sondern abstrakt. Solchen lesbaren Code sollte man in jedem Fall programmieren - ob nun mit eigenen Mitteln (erfordert wiederum viel Erfahrung) oder fremder Hilfe.
Wen man schon Fremdcode nutzt (und wer tut das nicht?) dann wenigstens modular aufgebaute Libraries, wie z.B. Fork (das ich immer noch nicht getestet habe) oder ... (Name vergessen, ich versuche morgen mal, es zu finden)
Der Spaß z.B. bei jQuery ist doch das einheitliche Konzept von Knotenlisten und Chaining, bei Prototype und Mootools die »erweiterten« Elementobjekte.
FORK:
var finds = FORK.Dom.getElementsByClass('orange', {
root: document.getElementById('div'),
tag: 'li'
});
for (var i = 0; i < finds.length; i++) {
FORK.Style.setStyle(finds[i], 'width', '123px');
}
Wenn ich mir selbst ein Helferscript schreibe, dann doch nicht eins, wo ich immer noch Spaghetti-Code wie den obigen schreiben muss. Gut, das ist halt sehr stark von YUI beeinflusst, wobei es in YUI zumindest so ginge:
YAHOO.util.Dom.setStyle(YAHOO.util.Selector.query("div li.orange"), 'width', '123px');
Hingegen:
Mootools: $$('div li.orange').setStyle('width', '123px')
jQuery: jQuery('div li.orange').css('width', '123px')
Das API, die ich mir auch selbst bauen würde. Der Clou von Frameworks (für mich zumindest) ist, dass sie prototypische Erweiterung nutzen (Prototype, Mootools) oder zumindest ein Wrapper-Objekttyp bieten, wie die Knotenlisten bei jQuery, die wiederum alle Element-Methoden besitzen. Den Umweg über knotenliste.each(function () { ... }) oder invoke() bei Prototype finde ich nicht ganz so komfortabel, aber immerhin nicht schlecht.
Mathias
Struppi