TypeScript: strikte Typen gegen Telefon-Tickets

Würdigung — Bugs, die Mandanten anrufen lassen#

Eine kaputte Adress-Anzeige auf der Kontakt-Seite, ein Insight-Link, der einen 404 produziert, eine Datenschutzerklärung, die nach einer Code-Änderung halb leer rendert — das sind die Fehler, die Mandanten direkt sehen, und die dann als verärgerter Anruf zurückkommen. Die Ursache liegt fast nie in spektakulärem Versagen, sondern fast immer in einer kleinen Inkonsistenz: ein Feld umbenannt, aber nicht überall mitgezogen; ein Datentyp leicht geändert, aber an einer Stelle übersehen.

TypeScript adressiert genau diese Klasse von Fehlern. Indem es jedem Datenobjekt einen klaren Vertrag gibt („eine Insight-Artikel-Definition hat ein slug-Feld, ein title-Feld, ein tags-Array …") und jede Code-Stelle, die ein solches Objekt anfasst, gegen diesen Vertrag prüft, macht Inkonsistenzen vor dem Live-Gehen sichtbar — nicht beim Besucher.

Was ist TypeScript? Großmutter-Test#

JavaScript ist die Sprache, die Browser ausführen — und sie ist dynamisch typisiert: Eine Variable, die heute eine Zahl ist, kann morgen ein Text sein, und niemand sagt etwas. Das ist beim schnellen Schreiben praktisch und beim Warten gefährlich. TypeScript legt sich darüber: Es lässt einen Entwickler explizit angeben, welche Typen wo erwartet werden, und ein Compiler prüft das vor dem Build.

Großmutter-Test: TypeScript ist wie eine Person im Sekretariat, die jede Auftragsbestätigung gegen die Vorgaben prüft, BEVOR der Brief raus geht — „dieses Formular braucht ein Datum, hier steht aber ‚gestern' — bitte korrigieren". Wenn die Korrektur nicht passiert, geht der Brief gar nicht erst raus.

Bei strikten Einstellungen (die wir bei fahoch2.de fahren) sind die Prüfungen besonders eng: nichts darf unbedeutend bleiben, nichts darf implizit „irgendein Typ" sein, keine Felder dürfen unausgefüllt durchrutschen. Diese Strenge ist anfangs etwas mehr Tipparbeit — und zahlt sich nach den ersten Refactorings sofort aus.

Was strikte Typisierung konkret verhindert#

Drei Fehler-Klassen, die in untyplich gepflegten Sites häufig vorkommen — und die bei uns durch den Typ-Check vor dem Build gestoppt werden:

• Feld-Umbenennung, halb durchgezogen. Wenn ein Datenfeld umbenannt wird (adresseAlt → adresse), aber an drei Stellen nicht mitgezogen wurde, läuft eine untypisierte Site weiter — und zeigt an diesen Stellen einfach gar nichts an. TypeScript listet die drei Stellen mit Datei und Zeile auf und blockiert den Build, bis sie behoben sind.
• Funktionen mit zu wenig oder zu vielen Argumenten. Eine Funktion, die früher zwei Parameter brauchte und jetzt drei braucht, wird in untypisiertem Code mit zwei Parametern aufgerufen — und produziert dort unbemerkt Quatsch (typischerweise: undefined-Werte in der Anzeige). TypeScript verlangt, dass jeder Aufruf zur Signatur passt.
• Tippfehler bei Feld-Namen. Aus tags versehentlich tag getippt — JavaScript liest dann undefined und tut so, als wäre alles in Ordnung. TypeScript sagt sofort: „Die Eigenschaft tag gibt es auf diesem Typ nicht. Meintest du tags?"

Das wirkt nach Mikro-Problemen — bis sich solche Mikro-Probleme zu fünf gleichzeitigen Mini-Bugs auf einer Live-Site summieren und niemand mehr weiß, welcher zu welcher Änderung gehört.

Drei Beispiele aus dem fahoch2.de-Repo#

Wo TypeScript bei uns nachweislich gegriffen hat:

• Insight-Cluster-Mapping. Wir haben in src/data/insight-clusters.ts eine Tabelle, die jedem Insight-Slug eine Rubrik zuweist. TypeScript ist so eingerichtet, dass diese Tabelle nicht auf einen Slug verweisen darf, der gar nicht existiert. Beim Schreiben eines neuen Insights hätten wir die Slug-Schreibweise an einer der beiden Stellen einmal falsch gehabt — der Build war sofort rot, mit klarer Fehlermeldung. Eine Minute später war die Inkonsistenz behoben.
• Schema.org-Erzeugung pro Insight-Seite. Die Funktion, die das JSON-LD-Schema pro Insight zusammenstellt, erwartet bestimmte Felder (headline, datePublished, author). Als wir die Insight-Struktur um ein optionales updated-Feld erweitert haben, hat TypeScript an drei Stellen geprüft, ob alle Konsumenten damit umgehen können — und uns an einer Stelle darauf hingewiesen, dass wir den Fall „kein updated-Datum vorhanden" abfangen müssen. Hätten wir das in JavaScript übersehen, wäre das Schema-Markup einzelner Insights kaputt gewesen.
• Rubrik-Landingpage-Generierung. Die Routen /insights/rubrik/<id> werden aus der Cluster-Liste erzeugt. TypeScript stellt sicher, dass jede der sieben Cluster-IDs einen Anzeige-Namen und eine Beschreibung hat — fehlt eines, bleibt der Build rot. Das hat uns einmal gerettet, als wir einen neuen Cluster eingerichtet hatten und die Anzeige-Beschreibung vergessen hätten.

In allen drei Fällen wäre der Fehler entweder erst Wochen später aufgefallen (über ein Telefon-Ticket eines aufmerksamen Mandanten) oder gar nicht — und hätte unsichtbar Qualität gekostet.

Was TypeScript NICHT ersetzt#

Drei Dinge, an denen TypeScript bewusst keine Hand anlegt:

• Inhaltliche Korrektheit. Ein Insight-Artikel kann typisch korrekt sein (title ist ein String, tags ein Array) und trotzdem inhaltlich falsch oder berufsrechtlich problematisch sein. Dafür gibt es den fa2-lektor-Skill, den Voice-Linter und die menschliche Endprüfung.
• Bedeutungs-Verständnis. TypeScript prüft Strukturen, nicht Sinn. Wenn jemand das Feld published als Datum „im Jahr 3026" einträgt, ist das typisch korrekt — und semantisch unsinnig. Solche Logik-Prüfungen gehören in andere Schichten (Validierung beim Import, Tests).
• Sicherheits-Lücken. TypeScript härtet Code nicht gegen XSS, SQL-Injection oder veraltete Abhängigkeiten ab. Dafür sind Security-Header (CSP/HSTS-Insight), npm audit und CloudflareCloudflare · zum GlossarUS-Anbieter für CDN, WAF, DDoS-Schutz und Turnstile — Privacy-by-Design-Ausrichtung. (WAF-Insight) zuständig.

Die Stärke von TypeScript liegt also klar umrissen: strukturelle Konsistenz von Daten und Funktionen über die ganze Site hinweg. Genau dort liegt der häufigste Fehler-Mechanismus, der Mandanten anrufen lässt.

Warum das gerade für Kanzleien zählt#

Eine Kanzlei-Website lebt typischerweise mehrere Jahre, ändert sich nur in Wellen (Datenschutzerklärung-Update, neue Stadt-Landingpage, neuer Insight-Artikel, Personen-Foto auf der Team-Seite), und überlebt mehrere Bearbeiter-Wechsel. Genau diese Konstellation — wenige große Refactorings über Jahre, viele kleine Hände — ist das Szenario, in dem strikte Typisierung am meisten leistet. Sie macht Refactorings sicher, weil sie die Folgen einer Änderung sofort aufzeigt; sie macht Bearbeiter-Wechsel weicher, weil ein neuer Mitspieler die Datenstrukturen am Typ-Vertrag ablesen kann.

Wie wir es bauen#

Bei jedem neuen Projekt fahren wir die strikten TypeScript-Einstellungen (strict: true, noImplicitAny: true, strictNullChecks: true) ab dem ersten Code-Strich. Wer das später nachzieht, hat einen schmerzhaften Aufholtag — wer von Anfang an strikt bleibt, hat die Mehrarbeit über das Projekt gleichmäßig verteilt und nie eine Lücke, die sich gefährlich anfühlt. Im Build ist der Typ-Check die allererste Stufe — was hier scheitert, kommt gar nicht erst zum Bundle-Schritt.

Für eine strukturierte Bewertung der Wartbarkeit Ihrer aktuellen Site (Stack, Typisierung, Refactoring-Lage) empfehlen wir den Hebel-Audit (890 €, bei Mandanten-Boost-Beauftragung innerhalb von 60 Tagen voll anrechenbar).

Zusammenfassung#

TypeScript ist eine Sprach-Erweiterung über JavaScript, die jedem Datenobjekt und jeder Funktion einen klaren Typ-Vertrag gibt — und vor dem Build prüft, ob alle Code-Stellen diesen Vertrag einhalten. Strikte Einstellungen verhindern die häufigste Fehler-Klasse, die Mandanten als Telefon-Ticket erreicht: halb durchgezogene Feld-Umbenennungen, Funktionsaufrufe mit falschen Parametern, Tippfehler in Feld-Namen. Drei konkrete fahoch2.de-Beispiele zeigen, wo der Typ-Check uns Fehler gespart hat (Insight-Cluster-Konsistenz, Schema-Erzeugung, Rubrik-Routing). TypeScript ersetzt keine inhaltliche Lektorat-Arbeit, kein Sinn-Verständnis und keine Sicherheits-Härtung — es ist eine fokussierte Schicht für strukturelle Konsistenz. Für Kanzlei-Sites, die mehrere Jahre und mehrere Bearbeiter überstehen müssen, ist genau diese Schicht der Hebel, der Wartung über die Zeit dramatisch günstiger macht.

Quellen#

• TypeScript Handbook — Introduction — abgerufen 2026-06-05
• TypeScript — Strict Mode Options — abgerufen 2026-06-05
• MDN — JavaScript Data Types and Data Structures — abgerufen 2026-06-05

Disclaimer: Beschreibung der tatsächlichen TypeScript-Konfiguration von fahoch2.de (strict-Modus) zum Zeitpunkt der Veröffentlichung. TypeScript ist eine bewusste Stack-Entscheidung; andere Stack-Wahlen (z. B. JavaScript mit JSDoc-Typen oder reine Validierungs-Schichten) erreichen ähnliche Effekte über andere Wege.