Boilerplates und Frameworks

Es ist gerade eine tolle Zeit für Webentwickler. Überall sprießen Frameworks und Boilerplates für jedes erdenkliche Einsatzgebiet aus dem Boden. Man muss eigentlich nur noch zugreifen und sich die gewünschten Sachen zusammenklicken. Eigentlich eine schöne Sache, aber irgendwie auch doch wieder nicht.

Boilerplates

Das HTML5 Boilerplate hat den großen Anfang gemacht und bietet eine super Anlaufstelle für die Best-Practices, wenn ich eine neue Webseite beginne. Problematisch ist, dass das Standardtemplate in vielen Fällen aber einfach "blind" übernommen wird. Getreu dem Motto: "Super, da hat ja jemand schon die ganze Arbeit für mich erledigt." Statt sich mit den vorhanden Features auseinanderzusetzen, finden sich teilweise Anweisungen um das Boilerplate wieder zu überschreiben. Das ist knapp am Ziel vorbeigeschossen.

Die Entwickler hinter dem Boilerplate, allen voran Paul Irish, haben als Intention die Best Practices zu vereinen und muntern dazu auf, auch mal länger auf der Entfernen-Taste zu bleiben. Ich bevorzuge hier allerdings den anderen Weg: Die Dinge, die ich brauche rausziehen und in ein wesentlich einfacheres Boilerplate überführen (mein persönliches basiert auf dem von Harry Roberts alias csswizardry).

Twitter's Bootstrap ist ein Boilerplate für gesamte Webapps und ist dementsprechend umfangreich. Ein Blick in den Code lohnt sich auf jeden Fall, insbesondre auch was CSS und JS betrifft.

Frameworks

Frameworks werden idealerweise so eingesetzt wie sie kommen. Kein rumfuhrwerken, höchstens außenrum bauen. Einfach nur, um sich die Option offen zu halten, später auf eine neue Version es Frameworks umzugraben. Ich verwende beispielsweise jQuery als grundlegendes Framework für so ziemlich alle JavaScript-Geschichten. Würde ich anfangen direkt in jQuery Dinge zu ändern, wäre ich beim nächsten Release, das vielleicht fatale Bugs behebt, aufgeschmissen.

Zugegeben: jQuery ist da ein eher schlechtes Beispiel, weil es sehr ausgereift ist. Templating Frameworks eigenen sich besser als Beispiel (unabhängig davon, ob sie überhaupt sinnvoll sind): Es gibt ein paar große Frameworks und dutzende Micro-Frameworks, die meist nur einen kleinen Anwendungsfall abdecken. Der typische Ablauf sieht dann so aus: Man suche sich ein so kleines Framework, das ungefähr passt und baut das erstmal ein. Gerne kommen dann auf einmal Fälle, in den sich das Framework einen Ticken anders verhalten soll. Der schnellste Lösungsweg führt viele dann doch dazu, das Framework so aufzubohren, dass es den eigenen Vorstellungen entspricht. Der Vorteil der Kompatibilität ist dahin.

Viel zu selten finden (sinnvolle) Anpassungen wieder den Weg zurück in das eigentliche Framework, vor allem da bei kleineren Frameworks schnell das eigene Aufbohren fast so viel Code umfasst wie das gesamte Framework.

... aber warum nicht gleich alles selbst machen?

"Jeder gute Programmierer macht das alles selbst." – Oder so ähnlich. Es gibt einen Grund für Best Practices und ich persönlich wäre beispielsweise nie auf die Idee gekommen, welche Image Replacement Methode denn jetzt die beste sei. Bei Frameworks ist es ähnlich: Ich persönlich habe weder Lust noch Zeit, sicherzustellen, dass mein selfmade Framework auf sämtlichen Plattformen so funktioniert, wie es soll, wenn es schon zig weiterentwickelte Frameworks gibt.

mehr dazu:

Lesenswert zu diesem ganzen Thema auch Stop solving problems you don't have yet und In defense of reinventing wheels.