Warum ich heute jedes Node.js‑Projekt mit TypeScript starte
Ich bin 2015 in die Welt der JavaScript-Programmierung eingestiegen. Vorher waren typisierte Sprachen meine treuen Begleiter. Entsprechend war ich von Tag 1 an angetan von den Möglichkeiten, die mir TypeScript bot. Auch wenn die Toolchain damals noch komplizierter war, überwog für mich schon immer der Nutzen.
Typen als Lebensversicherung
Die wichtigste Erkenntnis eines jeden Entwickelnden ist der Moment, in dem klar wird, dass Codelesen wichtiger ist als Codeschreiben. Ab diesem Zeitpunkt wird der Code immer bewusster geschrieben. Stets mit dem Blick darauf, später zu verstehen, was und vor allem warum es so entwickelt wurde. Das muss gar nicht für andere sein. Das Future-Me kann frustriert auf die Zeilen Code blicken.
Natürlich gibt es meiner Meinung nach noch profanere Gründe, TypeScript zu nutzen. Neben der Verdeutlichung der Intention erleichtert TypeScript das Refactoring. Zusätzlich reduziert es die mentale Last, da der Codeeditor sinnvolle Vorschläge machen kann. Und in Zeiten von KI geht es über reine Autovervollständigung hinaus.
function getUser(id: number): User | null {
// ...
}
// Je nachdem, ob ich die Rückgabe von null erlaube,
// verdeutliche ich, wie ich die Nutzung der Methode geplant habe.
Architektur und Kommunikation
Im vorherigen Abschnitt habe ich den Aspekt bereits angerissen: Mithilfe der klaren Definition beschreibe ich meine Intention und damit die zugrunde liegende Modellierung. Sei es z. B. die Datenmodellierung oder die Schnittstellendefinition. Das sind wichtige Aspekte der Softwarearchitektur.
Weiterhin kommuniziere ich durch meine Typen mit meinen Kollegen (oder mit meinem Future-Me). Es ist also eine gewisse Form der Dokumentation. Eine Disziplin, die eher unbeliebt ist und doch entscheidend für eine gute Software ist.
interface User {
id: number;
name: string;
email?: string;
}
// Es ist klar, was "User" ist. Die E-Mail ist kein Pflichtfeld.
// Hier ließe sich diskutieren, ob "email: string | null" besser wäre.
// Hauptsache, es wird bei gleicher Intention überall identisch modelliert.
Mehr Tempo
Dank der verbesserten Unterstützung durch die Entwicklungsumgebungen beschleunigt TypeScript das Refactoring und die Weiterentwicklung. Müsste ich wählen, würde ich Test-Driven den Vorzug geben. Jedoch kann ich in der Regel beides haben und nutze es entsprechend.
Insbesondere beim Codelesen bin ich mit TypeScript schneller. Damit verbringe ich in der Regel 80 % meiner Zeit. Das schließt die Überlegungen ein, wie ich den Code anpasse oder weiterentwickle. Der Prozentsatz mag je nach Projektstatus variieren (anfangs ein größerer Anteil an Code schreiben) – auf lange Sicht verschiebt er sich dahin.
Fazit
Ich bin überzeugt, dass meine Entwicklungsqualität durch TypeScript besser ist als ohne TypeScript. Ich kenne einige gute Argumente gegen TypeScript, die jedoch auf meine Arbeitsweise nicht zutreffen. Das schnelle Feedback in Form von lesbarem Code oder IDE-Support überwiegt für mich. Der zusätzliche Grad an Komplexität in der Toolchain ist akzeptabel. Wie sich diese bei mir genau zusammensetzt, werde ich im Laufe des Monats beschreiben.
Wo spart dir TypeScript gerade konkret Nerven?
Schreib mir deine Gedanken zum Thema in die Kommentare oder
Lass uns unsere besten Bug-Storys austauschen