Das hier beschriebene Werkzeug betreibe ich selbst. Ich verdiene daran; berücksichtigen Sie das beim Lesen. Ein Vergleich mit fremden Werkzeugen findet in diesem Beitrag nicht statt – dafür fehlt mir die Erhebung, und ich bin Marktteilnehmer.
Die Frage ist nicht, ob flaches HTML schneller und sicherer ist. Das ist es. Die Frage ist, was man dafür aufgibt – und darüber steht in solchen Beiträgen meist nichts.
Was wegfällt
Eine Website, die als fertige HTML-Dateien ausgeliefert wird, hat zur Laufzeit keine Datenbank, keine Skriptsprache und keine Erweiterungen von Dritten. Damit entfallen nicht einzelne Angriffswege, sondern ganze Klassen davon:
- Einschleusung über Eingaben. Es gibt keine Abfrage, in die sich etwas einschleusen ließe.
- Verwundbare Erweiterungen. Es gibt keine, die zur Auslieferungszeit liefe.
- Aktualisierungen unter Druck. Eine Sicherheitslücke im Generator betrifft den Bauvorgang, nicht die ausgelieferte Website.
- Lastspitzen durch Seitenerzeugung. Es wird nichts erzeugt. Der Server reicht Dateien durch.
Was das kostet
Der Teil, der in Werbetexten fehlt, und er ist nicht klein:
- Keine Redaktionsoberfläche, in der Dritte ohne Einweisung arbeiten
- Kein Ökosystem fertiger Erweiterungen
- Keine fremde Dokumentation, keine Gemeinschaft
- Kein Warenkorb, kein Anmeldebereich, keine Kommentare ohne Zusatzaufwand
- Jeder Fehler ist der eigene – es gibt niemanden, der ihn vorher gefunden hat
- Ganze Fehlerklassen entfallen statt abgesichert zu werden
- Auslieferung so schnell, wie der Server Dateien lesen kann
- Kein Wartungsfenster für die ausgelieferte Website
- Die Ausgabe ist vollständig bestimmt – gleicher Eingang, gleiches Ergebnis
- Sicherung und Umzug sind ein Verzeichnis
Der Punkt, der am meisten wiegt
„Jeder Fehler ist der eigene" klingt nach Stolz und ist in Wirklichkeit die härteste Position auf der Kostenseite. Bei einem verbreiteten System hat jemand anderes den Fehler vor einem gefunden, beschrieben und behoben. Beim eigenen Werkzeug findet man ihn im Betrieb – und der Zeitpunkt, zu dem man ihn findet, sucht sich nicht aus, ob er passt.
Genau daraus besteht ein guter Teil dieses Blogs: Es sind Fehler, für die es keine fremde Antwort gab.
Wann sich das nicht lohnt
- Viele Redakteure. Wer Inhalte von Personen ohne technischen Hintergrund pflegen lässt, braucht eine Oberfläche – und ein bestehendes System hat eine bessere, als man selbst bauen wird.
- Warenkorb oder Anmeldebereich. Das ist der Gegenentwurf zu statischer Auslieferung, nicht eine Ergänzung davon.
- Kurze Laufzeit. Der Aufwand amortisiert sich über Jahre, nicht über ein Projekt.
- Keine Bereitschaft, es selbst zu pflegen. Ein eigenes Werkzeug ohne dauerhafte Pflege ist schlechter als ein fremdes mit fremder Pflege.