10 gute Gründe Web-Frameworks zu vermeiden
Dies ist eine freie Übersetzung des Blogartikels Top 10: Reasons To Avoid Component Libraries von
Dan Yoder. Übersetzt mit freundlicher Genehmigung des Autors.
Letztens las ich einen interessanten Kommentar zu einem Blog Eintrag bei Ajaxian bezüglich der starken Verbreitung von Komponenten Bibliotheken bzw. Web-Frameworks (wie z.B. YUI, TIBCO, usw.):
Dion meinte dazu:
Manchmal fühle ich mich ein bisschen schlecht wenn sich die Leute hier und da über eine neue Komponente freuen, wenn im Gegensatz dazu schon hunderte davon in Frameworks wie TBCO, Backbase oder Oracle ADF stecken![]()
Nun gut, hier sind 10 Gründe, warum Dion sich deshalb nicht so schlecht fühlen sollte
- HTML ist besser als ein eigene
Markup
Sprache. Das trifft vor allem dann zu wenn das eigene Markup sowieso auf
XML
basiert, was ja meistens der Fall ist. Einige unter uns bevorzugen
wahrscheinlich auch ein Markup das sich über eine eindeutig definierte
Schnittstelle (z.B. über
CSS) nur dann „einklinkt“ wenn man es auch wirklich benötigt.
- Meine handverlesenen
Komponenten sind schneller geladen und werden schneller ausgeführt. Wie Dion
bereits erwähnte umfassen manche der Frameworks hunderte von Komponenten.
Schön und gut, aber der Nachteil daran ist das man die nicht benötigten,
überflüssigen Komponenten nicht so einfach entfernen kann ohne gleich die ganze
Stabilität des Frameworks zu beeinflussen. Des Weiteren, unterscheidet sich die
Qualität der Umsetzung speziell im Bereich der Performance manchmal erheblich.
Sorry, aber meine Webseiten sollten auch bei einer etwas langsameren DSL Leitung
noch schnell laden.
- Desktop ähnliche Oberflächen waren in den 90’er Jahren in. Wir sollten deshalb nicht weiter versuchen Web-Anwendungen wie Desktop-Anwendungen aussehen zu lassen. Außerdem sind viele der neuen Richtlinien (Guidelines), die sich in letzter Zeit für die Web-Entwicklung herausgebildet haben, denen der Desktop-Oberflächen weit überlegen. Macht also einen Schritt vorwärts und nicht einen zurück.
-
Ich will nicht deine
Entwicklungsumgebung (IDE) benützen. Ich hab bereits meine eigene. Und
Eclipse ist zwar viel besser als eine
proprietäre IDE aber manche von uns
wollen Sie trotzdem nicht benützen. Zusammenfassend will ich damit sagen, wenn
dein Framework eine bestimmte IDE erwartet ist das ein Problem für mich.
- Ich benötige keinen tollen Drag and Drop GUI Builder. Das ist zu viel des Guten. Ich arbeite nun schon seit etlichen Jahren mit HTML, es ist simpel und das meiste erstelle ich sowieso aus Vorlagen. Ich will meine Oberfläche selber definieren können und deine Bibliothek nur dann einbinden wenn sie benötigt wird.
-
Das KISS-Prinzip (Halte
es einfach) gilt immer noch für Web-Anwendungen obwohl manche denken
unbedingt ein „super auto sorting filtering live editing grid“ haben zu müssen.
Aber die meisten brauchen so etwas nicht. Manchmal ist eine einfache Liste mit
ein paar übersichtlichen Optionen für das Bearbeiten einfach besser. Den Erfolg
dieser Herangehensweise kann man auch an bekannten Web-Anwendungen (z.B.
Flickr oder
YouTube, usw.) sehen.
- Die Richtlinien für die Web-Entwicklung sind noch nicht ausgereift. Manchmal denke ich wir sind erst am Anfang. Dabei haben einige Bibliotheken bereits großartiges Design das den aktuellen „best practices“ (siehe Prototype) folgt, allerdings gibt es auch andere die schon veraltet sind bevor sie überhaupt veröffentlicht werden. Selectors sind hier ein gutes Beispiel, denn dank der relativ neuen und schnellen CSS3 Umsetzung haben sich diese zu einer mächtigen Methode entwickelt um Objekte und Events an HTML zu binden. Das hat die „best practices“ für den Umgang mit dem DOM dramatisch verändert.
-
„Sehr schön, aber wir haben bereits eine.“ Wie bereits erwähnt benötige ich nicht alle deine
Komponenten und ich will auch nicht deinen kompletten Framework-Kern dafür
einbinden müssen. Selectors sind da wieder ein gutes Beispiel. Mit der Umsetzung
der Selectors in Prototype bin ich sehr zufrieden, deshalb will ich keine zweite
laden müssen, aber ich kann deine Implementation nicht einfach entfernen ohne
dass dein Web-Framework „kaputt“ geht.
-
Sich an Standard halten
ist gut. Danke dass Ihr mich vor HTML, CSS und JavaScript „beschützen“ wollt
aber irgendwie kann ich mich mit der Tatsache das der Code, den ich schreibe,
von der weiteren Unterstützung der von der Community abhängt nicht anfreunden.
Du könntest zum Beispiel in ein oder zwei Jahren entscheiden dass dir
Web-Anwendungen nicht mehr so wichtig sind. Sicher — du hast deine Bibliothek
als Open Source veröffentlicht, aber wer treibt die Entwicklung voran wenn du
nicht mehr dabei bist?
- Dein Framework hat immer noch keinen WYSIWYG HTML Editor!? So ziemlich alles was du machen kannst, kann ich besser (mit der Hilfe von vielen talentierten Open Source Entwicklern da draußen). Aber da sind immer noch ein paar Dinge die du wahrscheinlich besser machen könntest, aber du tust es nicht. Also warum sollte es mich kümmern?
Mein Kommentar:
Also ich finde Dan’s Artikel toll, er beschreibt einige Probleme mit größeren Web-Frameworks die bei der üblichen Euphorie unter den Tisch fallen. Ich will allerdings keineswegs alles schlecht reden, denn ein gutes Framework kann einem allemal sehr viel Arbeit ersparen. Am besten man beschäftigt sich erstmal mit der Materie bevor man überstürzt eine Entscheidung trifft. Und letztendlich muss dann jeder für sich selbst entscheiden wie er dazu steht
(Ha! da bin ich mal wieder fein raus *g*)
Jonas
Also ich finde Dan’s Artikel toll, er beschreibt einige Probleme mit größeren Web-Frameworks die bei der üblichen Euphorie unter den Tisch fallen. Ich will allerdings keineswegs alles schlecht reden, denn ein gutes Framework kann einem allemal sehr viel Arbeit ersparen. Am besten man beschäftigt sich erstmal mit der Materie bevor man überstürzt eine Entscheidung trifft. Und letztendlich muss dann jeder für sich selbst entscheiden wie er dazu steht
Jonas





