TypeScript Entwicklung als Subscription

Warum TypeScript nicht verhandelbar ist

JavaScript war jahrzehntelang die Sprache des Webs. Dann kam TypeScript und hat alles verändert. Heute nutzen über 78% aller professionellen Web-Entwickler TypeScript. Microsoft, Google, Airbnb, Stripe, Slack, alle haben ihre Codebases auf TypeScript migriert.

Wir entwickeln seit 2018 ausschließlich in TypeScript. Kein einziges neues Projekt in JavaScript. Der Grund ist einfach: TypeScript macht Code besser. Messbar besser.

Die Zahlen sprechen für sich

38% weniger Bugs laut einer Studie von Airbnb nach der Migration zu TypeScript
15% höhere Entwicklerproduktivität durch Autocomplete und Inline-Dokumentation
60% weniger Debugging-Zeit weil Typfehler beim Kompilieren statt in Produktion gefunden werden
2x schnelleres Onboarding neuer Entwickler weil die Typen als lebende Dokumentation dienen

Was TypeScript konkret löst

Ohne TypeScript:

Ein API-Feld wird umbenannt, aber drei von sieben Frontend-Komponenten verwenden noch den alten Namen. Der Fehler wird erst in Produktion bemerkt, wenn ein Kunde einen Bug meldet.

Mit TypeScript:

Das Feld wird umbenannt, der Compiler markiert sofort alle sieben Stellen. Der Entwickler fixt alles in fünf Minuten, bevor der Code das Laptop verlässt.

Das ist kein theoretisches Beispiel. Das passiert in JavaScript-Projekten täglich. In TypeScript-Projekten nie.

TypeScript über den gesamten Stack

Frontend mit React und Next.js

TypeScript transformiert die React-Entwicklung. Props werden typisiert, Hooks sind generisch, Context-Provider garantieren die richtige Datenstruktur.

Komponentenprops: Nie wieder vergessene Required-Props
Event Handler: Typsichere Events ohne any-Casts
API Responses: Zod-Validierung an der Boundary, danach volle Typsicherheit
Routing: Type-safe Routes mit TanStack Router oder Next.js App Router

Backend mit NestJS

Node.js Backend mit NestJS ist von Grund auf für TypeScript gebaut. Dependency Injection, Decorators, Guards, alles ist typsicher.

DTOs: Input-Validierung mit class-validator und automatische OpenAPI-Generierung
Prisma: Type-safe Database Queries. SQL-Fehler zur Compile-Zeit statt Runtime
GraphQL: Code-First Approach generiert das Schema aus TypeScript-Klassen
Config: Typisierte Umgebungsvariablen mit Joi oder Zod-Validierung

Geteilte Typen zwischen Frontend und Backend

Der größte Vorteil von TypeScript über den gesamten Stack: geteilte Typen. Eine Änderung am API-Response-Typ propagiert automatisch ins Frontend. Kein manuelles Synchronisieren von Interfaces.

packages/
├── types/           # Geteilte TypeScript-Typen
│   ├── user.ts      # User-Interface, von API und UI genutzt
│   ├── order.ts     # Order-Types mit Status-Enum
│   └── api.ts       # API Response/Error Types
├── validators/      # Zod-Schemas (Runtime + Type)
│   ├── user.ts      # Validierung + Typ-Inference
│   └── order.ts
└── utils/           # Geteilte Utility-Funktionen

JavaScript zu TypeScript Migration

Viele unserer Kunden kommen mit bestehenden JavaScript-Codebases zu uns. Die Migration ist eine unserer Kernkompetenzen.

Unsere Migrationsstrategie

Wir migrieren nie alles auf einmal. Das ist ein Rezept für Chaos. Stattdessen:

Phase 1: Foundation (Woche 1-2)

tsconfig.json einrichten mit strict: false (ja, wirklich)
.js Dateien in .ts umbenennen (TypeScript akzeptiert implizites any)
Build-Pipeline anpassen
CI/CD validiert TypeScript-Kompilierung

Phase 2: Boundaries First (Woche 3-6)

API-Typen definieren (Request/Response)
Datenbank-Modelle typisieren (Prisma einführen)
Externe Library-Typen installieren (@types/*)
Shared Interfaces für die wichtigsten Datenstrukturen

Phase 3: Strict Mode (Woche 7-12)

strict: true aktivieren
any systematisch eliminieren (ESLint no-explicit-any)
Generics einführen wo sinnvoll
Discriminated Unions für State-Management

Phase 4: Advanced (laufend)

Zod für Runtime-Validierung mit Typ-Inference
tRPC für End-to-End Typsicherheit
Branded Types für IDs (UserID ist nicht OrderID)
Template Literal Types für String-Patterns

Typische Migrationsdauer

Projektgröße	Dateien	Dauer	Kosten (Subscription)
Klein	50-100	4-6 Wochen	1-2 Monate Minimum 50
Mittel	100-500	8-16 Wochen	2-4 Monate Scale 150
Groß	500+	3-6 Monate	3-6 Monate Advanced 300

Wichtig: Migration passiert immer parallel zum Feature-Betrieb. Ihr Produkt steht nicht still. Mehr dazu: Technical Debt abbauen.

Monorepo-Setup mit Turborepo

Sobald Frontend und Backend TypeScript sprechen, ist ein Monorepo der logische nächste Schritt. Geteilte Typen, gemeinsames Linting, ein einziger CI/CD-Run.

Warum Monorepo?

Aspekt	Polyrepo	Monorepo
Geteilte Typen	NPM-Pakete publishen, versionieren	Direkter Import, immer aktuell
Code Review	Separate PRs in verschiedenen Repos	Ein PR mit Frontend + Backend Änderung
CI/CD	Separate Pipelines, Abhängigkeiten manuell	Eine Pipeline, Turborepo cached intelligent
Onboarding	5+ Repos clonen, verstehen, konfigurieren	`git clone` + `npm install`, fertig
Refactoring	Cross-Repo Refactoring ist ein Albtraum	IDE-Rename über alle Packages

Unsere Monorepo-Struktur

root/
├── apps/
│   ├── web/          # React/Next.js Frontend
│   ├── api/          # NestJS Backend
│   └── mobile/       # iOS/Android Projekte
├── packages/
│   ├── types/        # Geteilte TypeScript-Typen
│   ├── validators/   # Zod-Schemas
│   ├── ui/           # Shared React Components
│   ├── config/       # ESLint, TSConfig, Prettier
│   └── utils/        # Geteilte Utilities
├── turbo.json        # Turborepo Task-Config
└── package.json      # Workspace Root

Turborepo Vorteile

Remote Caching: CI baut nur was sich geändert hat. 80% schnellere Builds
Task Dependencies: build wartet auf types, test wartet auf build
Parallel Execution: Unabhängige Tasks laufen gleichzeitig
Pruned Deployments: Docker-Images enthalten nur die benötigten Packages

Zod: Runtime-Validierung trifft Typsicherheit

TypeScript-Typen existieren nur zur Compile-Zeit. Zur Laufzeit sind sie weg. Das ist ein Problem an jeder Boundary: API-Eingaben, Webhook-Payloads, Umgebungsvariablen, lokale Storage-Daten.

Zod löst dieses Problem. Ein Zod-Schema ist gleichzeitig Validierung (Runtime) und Typ (Compile-Zeit).

Wo wir Zod einsetzen

API-Input Validierung: Jeder Request wird validiert bevor er die Business-Logik erreicht
Environment Variables: Fehlende oder falsche Config fällt beim Start auf, nicht um 3 Uhr nachts
Form Validation: React Hook Form + Zod = typsichere Formulare mit einem Schema
External API Responses: Wir validieren was von Dritten kommt, bevor wir es verwenden
Database Seeds: Testdaten werden gegen das Schema validiert

tRPC: End-to-End Typsicherheit ohne Schema

tRPC eliminiert die API-Schicht komplett. Kein REST, kein GraphQL, keine Client-Generierung. Der Client ruft Server-Funktionen auf als wären sie lokal.

Wann tRPC sinnvoll ist

Kriterium	tRPC	REST/GraphQL
Nur TypeScript Clients	Ideal	Unnötiger Overhead
Drittanbieter konsumieren die API	Nicht möglich	Notwendig
Schnelle Prototypen	Extrem schnell	Mehr Setup
Große Teams mit API-Contracts	Möglich	Etablierter
Mobile Clients (Swift/Kotlin)	Nicht nutzbar	Notwendig

Unsere Empfehlung: tRPC für interne Tools und Prototypen. GraphQL oder REST für APIs die von Mobile Apps oder externen Partnern konsumiert werden.

TypeScript Best Practices die wir durchsetzen

Strikte Compiler-Optionen

Wir aktivieren strict: true und gehen noch weiter:

noUncheckedIndexedAccess: Array-Zugriffe können undefined sein
exactOptionalProperties: Unterscheidung zwischen undefined und "nicht vorhanden"
noPropertyAccessFromIndexSignature: Dot-Notation nur für bekannte Properties

ESLint-Regeln

@typescript-eslint/no-explicit-any: Kein any, niemals
@typescript-eslint/no-non-null-assertion: Kein ! Operator
@typescript-eslint/strict-boolean-expressions: Keine truthy/falsy Checks auf Non-Booleans
@typescript-eslint/consistent-type-imports: import type für reine Typen

Code Patterns

Discriminated Unions statt Status-Strings mit optionalen Feldern
Branded Types für IDs (UserId ist nicht OrderId)
Result Types statt Exceptions für erwartbare Fehler
Const Assertions für Literal Types und Enums
Generics mit Constraints statt Overloads

TypeScript in der Praxis: Reale Projektbeispiele

SaaS-Dashboard mit geteilten Typen

Ein B2B-Kunde kam mit einem JavaScript-Monolith: React Frontend, Express Backend, keine Typen, häufige Runtime-Fehler in Produktion. Unsere Migration:

Woche 1-2: Prisma eingeführt, Datenbank-Schema als Single Source of Truth
Woche 3-4: API-Layer mit Zod typisiert, automatische OpenAPI-Generierung
Woche 5-8: Frontend schrittweise migriert, Component Props typisiert
Woche 9-12: Strict Mode aktiviert, letzte any-Typen eliminiert

Ergebnis: Runtime-Fehler in Produktion sanken um 78%. Feature-Velocity stieg um 40% weil Refactoring sicher wurde.

E-Commerce mit tRPC

Ein Startup wollte schnell iterieren. Wir setzten Next.js mit tRPC ein:

API-Änderungen waren sofort im Frontend sichtbar
Kein OpenAPI-Schema pflegen, kein Client generieren
Zod-Validierung im Backend, Typ-Inference im Frontend
Time-to-Market für neue Features: 60% schneller als mit REST

Mobile Backend mit Shared Types

Eine Mobile App (SwiftUI + Kotlin) brauchte ein typsicheres Backend. Wir generierten Swift- und Kotlin-Types aus dem OpenAPI-Schema das NestJS automatisch aus den TypeScript-DTOs erzeugte. Eine Änderung am Backend-Typ löste automatisch Client-SDK-Updates aus.

Häufige Fragen zu TypeScript

Verlangsamt TypeScript die Entwicklung?

In den ersten zwei Wochen: ja, minimal. Danach: nein, es beschleunigt sie. Die Zeit die Sie beim Typisieren "verlieren" sparen Sie zehnfach beim Debugging, Refactoring und Onboarding neuer Entwickler. Jeder erfahrene Entwickler der von JavaScript zu TypeScript gewechselt hat, bestätigt das.

Brauche ich TypeScript für ein kleines Projekt?

Ja. Gerade kleine Projekte wachsen oft unerwartet. Eine spätere Migration ist teurer als von Anfang an TypeScript zu nutzen. Das Setup dauert 15 Minuten, die Vorteile halten jahrelang.

TypeScript oder JavaScript für mein Team?

Wenn Ihr Team JavaScript kann, kann es TypeScript in zwei Wochen lernen. Die Lernkurve ist flach, der ROI enorm. Wir empfehlen jedem Team den Umstieg. Tipps zum Teamaufbau: React Entwickler finden.

Was kostet TypeScript-Entwicklung?

TypeScript ist keine separate Leistung, es ist in allem was wir tun enthalten. Jedes Projekt, ob React, Next.js oder Node.js, wird in TypeScript entwickelt. Ab €2.495/Monat als Subscription. Details: Freelancer vs Agentur vs Subscription.

Kann ich meinen bestehenden JavaScript-Code migrieren lassen?

Absolut. Das ist eine unserer häufigsten Aufgaben. Siehe unsere Migrationsstrategie oben. Wir migrieren schrittweise, ohne den laufenden Betrieb zu unterbrechen. Parallel dazu bauen wir Technical Debt ab.