Im Internet wird viel über die Vor- und Nachteile von TypeScript diskutiert, und wie vorteilhaft es ist. Aber wie ist es im Vergleich zu BabelJs oder Traceur? Warum brauchen wir statische Typen in einer dynamischen Sprache? Ist es den Overhead wert? Eigentlich gibt es eine bessere Frage: Wann ist es den Aufwand wert? Nehmen wir zwei extrem unterschiedliche Beispiele.
Nehmen wir ein paar hundert Zeilen Code, wahrscheinlich ein Prototyp einer Idee, eine Demo oder etwas Ähnliches. Die Komplexität ist nicht sehr hoch, ein einzelner Entwickler kann das schaffen. In diesem Fall ist BabelJs vielleicht die bessere Wahl, weil es etwas mehr ES6-Funktionen hat. Sie möchten dies schnell und mit so wenig Aufwand wie möglich implementieren. Statische Typen in einen Code zu schreiben, der nicht gewartet wird, ist nicht sehr hilfreich. Der Vorteil von Babel ist jedoch vernachlässigbar. Die meisten ES6-Features sind auch in TypeScript enthalten, und die Kompilierung ist einfach einzurichten.
Riesige Projekte erfordern sehr unterschiedliche Denkweisen. Stellen Sie sich vor, ein Team von 10 oder mehr Entwicklern schreibt über 100 000 Zeilen Code. Der Code ist bereits in Produktion, wird aktiv unterstützt und weiterentwickelt. Es gibt eine Grenze dafür, wie viel Code ein Entwickler durchschauen kann. Wenn Sie diese Grenze überschreiten, laden Sie zu Fehlern ein, und die Kosten für einen Fehler sind im Vergleich zu einem kleinen Projekt enorm. Sie sollten Fehler wie die Pest vermeiden, denn sie tun weh, und zwar sehr weh. Ein Entwickler macht versehentlich einen Fehler. Das QA-Team bemerkt ihn. Die Veröffentlichung verzögert sich. Das Vertriebs- und Bereitstellungsteam hasst den Entwickler. Der Entwickler behebt den Fehler. Das QA-Team prüft ein zweites Mal auf Regression. Und je später der Fehler entdeckt wird, desto mehr Geld verbrennt er. Bugs in größeren Projekten verursachen größere Probleme, so dass jeder Kompilierzeitfehler des TypeScript-Compilers Geld spart. Die statische Typisierung hat natürlich einen gewissen Overhead, aber das ist Ihnen egal, denn die Wartbarkeit ist der Schlüssel. Vielleicht sind Sie ein gottgleicher JavaScript-Zauberer, der wartbaren Code ohne statische Typen schreibt, aber das spielt keine Rolle, weil Sie in einem Team arbeiten. Jedes Teammitglied ist auf einem anderen Niveau, so dass es unvermeidlich ist, dass selbst bei Code-Reviews suboptimaler oder nicht so gut lesbarer Code in die Codebasis gelangt. Das Wissensmanagement in großen Projekten ist allein schon eine Herausforderung, vor allem, wenn Sie einen neuen (Nachwuchs-)Entwickler im Team haben. Es ist einfacher, durch eine 100 Zeilen lange Schnittstelle zu sehen als durch 1000 Zeilen Code. Große Projekte sind nicht von Anfang an groß. Die Codebasis wird bereits einige Refactors durchlaufen haben, was mit statischen Typen (und deren IDE-Unterstützung) definitiv einfacher ist. Es ist so gut wie sicher, dass Refactoring ohne statische Typen unmöglich ist, oder man braucht Unmengen von Unit-Tests.
Statische Typisierung ist effektiv, wenn man sie überall einsetzt. Sie hat einen gewissen Overhead, aber sie hilft mehr und mehr, wenn der Code wächst.
Links
