Warum keine CMS oder Frameworks?

Die Erfahrung hat gezeigt, daß sowohl Content-Management-Systeme (CMS) und/oder komplexe Frameworks (egal ob PHP, Java oder anders basiert) kein Garant für eine "lebendige" Website sind. Eigentlich ist sogar das Gegenteil der Fall, da damit es eine ganze Menge Probleme behaftet sind, die im folgenden andisskutiert werden.

Komplexität

Aufgrund der Komplexität vieler Frameworks werden viele potentielle Webseiten-Maintainer/Ersteller davon abgehalten, neue Inhalte einzupflegen bzw. alte zu aktualisieren oder sogar neue Techniken/Technologien einzusetzen. Sprich, viele unsere Mitglieder sind definitiv in der Lage, Webseiten zu erstellen! Allerdings haben sie i.d.R. nur sehr wenig Zeit, sich in komplexe Sachen einzuarbeiten bzw. fehlen entsprechende Grundlagen (z.B. Kenntnisse in PHP) oder sogar das notwenidge Expertenwissen, um erforderliche Anpassungen vornehmen zu können.

Altlasten

OK, das Problem könnte evtl. durch entsprechendes Content-Management-System (i.w. CMS) kompensiert werden. Das Problem ist aber, daß es leider noch immer kein solches gibt. Erschwerend kommt hinzu, daß alle CMS durchweg durch Altlasten geprägt sind und somit die Nutzung zeitgemäßer Techniken automatisch ausgeschlossen wird.

Ein Beispiel: Viele CMS Entwickler können sich nicht von dem Gedanken lösen, daß produzierte Webseiten auch von uralten Browsern wie MSIE 4, Netscape 4 oder Opera 6 genau so wie in modernen Browsern angezeigt werden müssen. Das hat zur Folge, daß zum Layouten nicht Cascading Style Sheets (CSS) sondern Tabellen oder andere Tags in Kombination verschiedenen Attributen (wie z.B. <p fontsize=+2 color=red> statt <h2>) mißbraucht werden. Dies wiederum impliziert jede Menge Probleme/potentielle Fehlerquellen (z.B. öffnende, schließende, fehlende bzw. falsch positionierte Tags), als auch einen außerordentlich hohen Aufwand, wenn mitgelieferte "Standard-Layouts" angepaßt werden müssen (selbst wenn die jeweils notwendigen Experten-Kenntnisse vorhanden sind).

Ebenso entsteht ein großes Problem, wenn das bisher eingesetzte CMS/Framework plötzlich gegen ein moderneres ausgetauscht bzw. gänzlich in Rente geschickt werden soll. Eine automatische/programmatische Übernahme in das neue System ist nicht möglich, sprich es ist wieder jede Menge Aufwand aka Handarbeit notwendig, um die Website wiederzubeleben ...

Datenbanken

Ein ähnlich gelagertes Problem stellen Datenbanken (DB) dar. Moderne Datenbanken wie Sybase, Oracle oder mySQL beherrschen beispielsweise FOREIGN KEYs. Da CMS bzw. Framework-Entwickler aber gern das hochgesteckte Ziel erreichen möchten, daß ihr System mit allen gängigen Datenbanken funktioniert, werden solche nützlichen Feature gar nicht erst genutzt, sondern "nachprogrammiert", was nicht nur die Komplexität des Systems erhöht sondern auch eine Menge Fehlerpotential (sogennante point of failures) sowie unnötigen Overhead mit sich bringt.

Problematisch ist bei der Benutzung einer konventionellen DB natuerlich auch die Migration auf eine andere, z.B. aufgrund von Implikationen bzgl. Skalierung, Simplifizierung, Lizenzen. Wieso? Naja, wer mit verschiedenen Datenbanken gearbeitet hat weiß, das z.B. timestamp nicht unbedingt als Millisekunden seit 1. Januar 1970 hinterlegt sein muß und für die korrekte Konvertierung/Übernahme aus einer anderen DB i.d.R. keine Werkzeuge zur Verfügung stehen (obwohl das manchmal auch behauptet wird und sogar zu 95% funktioniert ...). Aber hallo? Muß ein Webadmin unbedingt ein DB-Spezialist sein?

Performance/Ressourcen

Nächste Frage, die sich unmittelbar mit dem Einsatz von CMS/Frameworks stellt, ist die Frage nach der Performance und den Bedarf an Ressourcen.

Wahrscheinlich leuchtet jedem ein, daß die dynamische Erzeugung von Seiten i.d.R. zusätzliche Performance sowie Ressourcen (z.B. Arbeitsspeicher aka RAM) dem jeweiligen Server abverlangt. Beispiel sind eine oder mehrere Datenbank-Abfragen bzw. Umwandlung der Ergebnisse von Abfragen in ein entsprechendes Format oder HTML-Fragment, was ganz einfach beim Servieren von statischen Seiten nicht erforderlich ist. Wie stark sich die Dynamik auf das Serververhalten auswirkt, hängt sicherlich von der verwendeten Technologie ab. Daß hier aber ein Overhead entsteht, liegt auf der Hand. Das selbiger oftmals sogar unnötig ist, steht ebenfalls außer Frage, denn wenn man sich die meisten Webseiten ansieht, ist deren Inhalt a priori statisch und läßt sich durch Anwendung moderner Techniken wie z.B. CSS durchaus ebenso personalisieren, wie es oft mit dem Einsatz dynamisch generierter Seiten versucht wird.

Installation/Work @Home

Schauen wir uns im Alltag um, ist es keine Seltenheit, daß viele Webseiten oftmals am Heimrechner aka Home-PC oder Laptop, sprich offline entstehen.

Werden nun CMS/Frameworks benutzt, ist es u.U. gar nicht möglich Web-Inhalte komplett offline zu pflegen/erstellen. Hier bleibt nur die unbefriedigende Variante, Vorabversionen (Drafts) vorzubereiten und später, im online-Modus per copy-and-paste einzupflegen. Das ist nicht nur doppelte Arbeit, sondern außerordentlich unbefriedigend für den Autoren selbst, da selbiger keine Möglichkeit hat um nachzuprüfen, ob und wie sich die Inhalte in die komplette Website einfügen, geschweige denn, gewissen navigatorische Elemente bereits beim Erstellen einbetten zu können.

Eine Alternative dazu könnte sein, das jeweile Framework/CMS auf dem Home-PC/Laptop zu installieren. Dann haben wir hier wieder das Problem, das entsprechende Vorraussetzungen nicht befriedigt werden können (z.B. fehlende DB), die Installation viel zu schwierig/komplex ist und/oder das gleiche Setup wie auf dem Produktionssystem aufgrund mangelhafter Dokumentation nicht reproduzierbar ist...