TypeScript: Nicht automatisch schlauer Code
Agenturen kennen die Szene: Kunde will Feature, Entwickler fragt nach Stack, irgendwer wirft „TypeScript“ in die Runde. Klingt schick, macht Eindruck – bringt aber selten per se bessere Software. Im Gegenteil: Die Typisierungspflicht und der ganze Build-Kram sind schnell mehr Ballast als Bonus, wenn das Setup nicht stimmt. Typisch bei knappem Budget oder engen Timings: TypeScript frisst Extra-Stunden, aber unterm Strich bleibt die Codequalität oft, wo sie war.
Die eigentliche Frage ist nicht: „TypeScript oder JavaScript?“ Sondern: Wann lohnt sich TypeScript wirklich? Und wann ist’s einfach nur ein weiteres Hindernis auf dem Weg zum Launch?
Teamgröße, Knowhow – alles andere als Randthema
Kleine Teams, Einzelselbständige, Leute, die JavaScript seit Jahren runterbeten: Die verlieren mit TypeScript meist mehr Zeit, als sie jemals aufholen. Einarbeitung? Dauert. Fehlermeldungen? Nicht selten kryptisch, gerade für Newcomer. Wer Typisierung aus PHP oder C# kennt, kommt klar. Wer nur mal kurz was zusammenhackt, kämpft. Und irgendwann wird’s dann doch wieder „any“ und „as unknown“ – und das war’s mit der Typensicherheit.
Anders bei gewachsenen Teams. Wer zu fünft oder zehnt am Frontend schraubt, freut sich über Typen, die im Editor Fehler anzeigen, Schnittstellen sichtbar machen und Refactoring weniger zum Glücksspiel machen. Je mehr Leute am Code, desto mehr lohnt die Investition in Typsystem, Build-Skripte und Tooling. Aber: Ein Team mit TypeScript-Erfahrung braucht’s trotzdem. Sonst bleibt der Effekt aus.
Budget, Tempo – selten auf dem Zettel
Agenturen stehen ständig unter Druck. Kunde wartet, Feature muss raus – und plötzlich soll erst mal Typisierung eingeführt werden? Ausprobiert. Ergebnis: Tickets bleiben liegen, weil erst das Buildsystem aufgesetzt werden muss, tsconfig.json nicht greift, oder die Toolchain auf dem alten Macbook spinnt. JavaScript läuft sofort. Kein Transpile, keine Typ-Defintionen, keine Zusatztools. Klar, das reicht selten für Großprojekte. Aber für 80 Prozent der Agenturjobs? Reicht.
TypeScript zieht Folgeaufwand nach sich: Build, Linter, Dependency-Pflege. Wer’s sauber halten will, muss regelmäßig ran. Sonst wird aus „wir tippen alles ordentlich“ schnell ein „who cares, Hauptsache deployed“. Fehler in der Config, inkompatible Versionen, Node-Updates – alles schon gesehen. Wer kein eingespieltes Team hat, fängt schnell an zu fluchen.
Wartung: Typisierung als Versicherung?
Bei großen Projekten mit wechselnden Leuten und ewiger Laufzeit: Ja, Typisierung hilft. Gerade bei Refactoring-Aktionen oder wenn neue Leute einsteigen. Fehler landen oft schon beim Tippen auf dem Bildschirm, nicht erst im Live-System.
Trotzdem: Auch mit JavaScript ist wartbarer Code möglich. Klare Standards, Code-Reviews, Tests – das bringt langfristig mehr als eine Typisierung, die am Ende eh niemand pflegt. TypeScript ersetzt keine Team-Disziplin. Wer das glaubt, wird irgendwann von Legacy-Code überrascht, der trotz .ts-Endung alles falsch macht.
Technik und Infrastruktur – oft unterschätzt
Nicht jeder Hoster mag TypeScript. Auf Shared Hosting? Meist keine Chance, weil kein Node, kein Build möglich. Ältere CI/CD-Pipelines? Plötzlich läuft der Build nicht mehr, weil npm 20 irgendwas nicht will. Deployment wird komplexer, weil immer erst nach JavaScript transpiliert werden muss. Klingt banal, nervt aber spätestens beim dritten Hotfix.
In Foren tauchen regelmäßig Threads auf: Build bricht ab, Skripte fehlen, Tooling inkompatibel. Wer das vorher nicht einplant, steht bei Release-Tag gerne mal mit leeren Händen da. Infrastruktur muss passen. Sonst wird TypeScript schnell zum Zeitfresser.
Fazit: Kein Dogma draus machen
Am Ende bleibt’s bei ein paar einfachen Fragen:
- Kennt das Team TypeScript aus der Praxis – oder ist’s nur Deko auf dem Tech-Stack?
- Ist wirklich Zeit fürs Onboarding und den Build-Prozess eingeplant?
- Geht es um ein Produkt mit Lebenszyklus oder einen schnellen Website-Launch?
- Gibt’s Reviews und Tests, damit Typos und Fehler auch wirklich auffallen?
TypeScript ist Werkzeug. Nicht Religion. Für viele Agenturjobs reicht plain JavaScript völlig aus. Wenig Leute, wenig Zeit, wenig Wartung – keine Typen nötig. Bei großen Teams, langen Laufzeiten und ordentlich Infrastruktur: Dann kann TypeScript Sinn machen. Aber nur dann. Und auch nur, wenn alle mitziehen.
In der Realität wird TypeScript oft verkauft, weil’s modern klingt. Nicht, weil’s passt. Ein ehrlicher Blick aufs Team und die Anforderungen spart am Ende mehr Zeit als jede Tool-Diskussion. Und meistens auch ein paar graue Haare.
bye
mo
Anhänge
Zuletzt bearbeitet: