TypeScript für Marketing-Sites: Wann es sich lohnt, wann nicht

TypeScript ist der Standard für neue Next.js-Projekte. Aber „Standard" bedeutet nicht „immer richtig". Hier ist eine ehrliche Einschätzung, wann TypeScript für Marketing-Sites einen echten Nutzen hat — und wann es nur Overhead ist.

Das Argument für TypeScript

TypeScript löst eine spezifische Klasse von Problemen: Fehler, die aus der falschen Verwendung von Typen entstehen. Auf einer Marketing-Site sind das vor allem:

CMS-Daten. Wenn Blog-Posts, Case Studies oder Team-Mitglieder aus einem CMS kommen, wissen Sie ohne Types nicht, welche Felder existieren, welchen Typ sie haben oder ob sie optional sind. TypeScript erzwingt explizite Interfaces für diese Daten.

Komponenten-Props. Bei wiederverwendbaren Komponenten (Card, Button, Section) stellt TypeScript sicher, dass die richtigen Props übergeben werden. Ohne Types können Sie einer Komponente ein number übergeben, wo ein string erwartet wird — und den Bug erst im Browser sehen.

Refactoring. Wenn Sie eine Komponente umbenennen oder eine Prop entfernen, findet TypeScript alle Verwendungsstellen sofort. JavaScript lässt das unbemerkt bis zur Laufzeit.

Das Argument gegen TypeScript

Overhead für kleine Projekte. Eine fünfseitige statische Marketing-Site hat vielleicht 20 Komponenten, keine Daten-Fetching-Komplexität und einen einzigen Entwickler. TypeScript-Konfiguration, Typ-Definitionen für Bibliotheken und Build-Zeit sind realer Overhead für minimalen Nutzen.

Lernkurve. Wenn der Entwickler, der das Projekt übernimmt, JavaScript kann aber TypeScript nicht gut kennt, fügt TypeScript Reibung hinzu. any-Typen überall negieren den Nutzen.

Falsche Sicherheit. TypeScript prüft Typen zur Build-Zeit. Es schützt nicht gegen Laufzeit-Fehler mit API-Daten, falsche Logik oder UX-Probleme. Ein typisiertes Projekt mit schlechter Logik ist nicht besser als ein untypisiertes.

Die Entscheidungsmatrix

Nehmen Sie TypeScript wenn:

• Das Projekt hat CMS-Integration (Contentful, Sanity, Prismic)
• Es gibt mehre Entwickler oder das Projekt wird von jemandem übernommen
• Das Projekt hat mehr als 30 Komponenten
• Daten-Fetching von externen APIs vorhanden ist
• Das Projekt langfristig gewartet werden soll

Überspringen Sie TypeScript wenn:

• Statische Site ohne CMS (hartcodierter Inhalt)
• Ein einziger Entwickler der das Projekt nie übergeben wird
• Weniger als 15 Komponenten
• Kurze Lebensdauer des Projekts (Landing Page für eine Kampagne)

Wie wir TypeScript auf Kundenprojekten verwenden

Wir verwenden TypeScript standardmäßig — aber mit pragmatischen Regeln:

Interfaces nur für externe Daten-Boundaries. CMS-Daten, API-Antworten, Umgebungsvariablen. Interne Komponenten-Props typisieren wir, wo es sinnvoll ist, aber wir werden nicht dogmatisch.

satisfies statt as. satisfies prüft den Typ ohne ihn zu erzwingen, was mehr Fehler fängt als as-Casts.

Strikte Konfiguration von Anfang an. strict: true in tsconfig. Weniger Schmerz als später nachzurüsten.

Kein any außer in Migrationen. any macht TypeScript nutzlos. Wenn ein Typ unklar ist, verwenden wir unknown und narrowen explizit.

Die Typen, die auf Marketing-Sites am meisten helfen

// CMS-Daten Interface
interface BlogPost {
  title: string
  description: string
  publishedAt: string
  slug: string
  category: 'Technology' | 'Design' | 'Strategy' | 'Process'
  tags: string[]
  readingTime?: number
}

// Komponenten-Props mit strikten Varianten
interface ButtonProps {
  label: string
  href: string
  variant: 'primary' | 'secondary' | 'ghost'
  size?: 'sm' | 'md' | 'lg'
}

// Lokalisierung
type Locale = 'en' | 'fr' | 'de'

Diese drei Muster fangen 80 % der auf Marketing-Sites relevanten Typen-Fehler.

Was TypeScript nicht tut

TypeScript prüft keine Laufzeit-Daten. Wenn Ihr CMS ein Feld publishedAt als string liefert aber der Wert ungültig ist ("not-a-date"), hilft TypeScript nicht. Sie brauchen Runtime-Validierung (z.B. mit Zod) für externe Daten.

TypeScript prüft keine Accessibility, SEO, Performance oder Designqualität. Es ist ein Werkzeug für Typ-Korrektheit, kein Allheil.

Die ehrliche Empfehlung

Für moderne Next.js-Projekte: Starten Sie mit TypeScript. Der Setup-Aufwand ist minimal bei neuen Projekten, und die Vorteile zeigen sich schnell sobald das Projekt wächst.

Für Legacy-Migrationsprojekte: Migrieren Sie graduell. allowJs: true und schrittweise Umstellung ist besser als ein Big-Bang-Rewrite.

Für temporäre Kampagnen-Sites: JavaScript ist vollkommen in Ordnung. Pragmatismus über Dogmatismus.

---

Bauen Sie eine neue Marketing-Site und unsicher ob TypeScript, welches Framework oder welche Architektur? Starten Sie ein Gespräch — wir helfen bei der Tech-Entscheidung.