© OneLineStock.com/Shutterstock.com
TypeScript von A bis Z – Teil 1

TypeScript – jeder Anfang ist einfach


JavaScript haftet in manchen Entwicklerkreisen, die mit „richtigen“ Programmiersprachen arbeiten, der Stallgeruch einer „Quick and dirty“-Skriptsprache an, deren Grundelemente – fast alles ist ein Objekt, ein Objekt ist eine Hash Map, Prototype Chains und vieles mehr – nicht einfach verständlich sind. Mit TypeScript ändert sich das.

JavaScript (JS) ist sehr weit verbreitet und es lassen sich damit sowohl client- als auch serverseitig sehr viele Aufgaben erledigen. Bis vor ein paar Jahren war es allerdings undenkbar, mit JavaScript größere Softwaresysteme zu entwickeln. Durch „Rich Internet Applications“, die z. B. dem Single-Page-Paradigma folgen (React, Angular, Vue), und durch den Erfolg von Node.js-Systemen hat sich das geändert. Allerdings gibt es nach wie vor den erwähnten Stallgeruch mit der Annahme, dass JavaScript-Systeme aufgrund der dynamischen Typisierung und der etwas anderen Grundkonzepte schwieriger zu verstehen und vor allem schwieriger zu warten seien. Das stimmt teilweise und wird mit TypeScript deutlich besser.

Etwas jammern: JavaScript sucks

In komplexeren Apps macht es keinen Spaß, Fehler zu suchen, die sich erst zur Laufzeit zeigen. Jeder Typo, den man übersieht, schlägt gnadenlos zu. Oder man vergisst beim Refactoring einer Methodensignatur, einige Aufrufe dieser Methode ebenfalls anzupassen, wodurch Schlimmeres als ein Laufzeitfehler passiert: Ein Argument wird plötzlich als ein anderes interpretiert, und solange es vom System konvertiert werden kann, verhält sich die App falsch, was erst nach aufwendiger Überprüfung von Ein- und Ausgabewerten auffällt. Ich werde hier nicht auf die Scheinalternative eingehen, jeden Parameter zur Laufzeit auf seinen Typ hin zu überprüfen. Und bitte glauben Sie mir: Unit-Tests sind kein Ersatz für statische Typisierung. Kennen Sie folgendes Phänomen? Sie hätten gerne gutes IntelliSense, aber die IDE kann die Variable, zu der Sie gerne die möglichen Properties angezeigt hätten, nicht eindeutig auflösen?

Ein sinnvoller Ansatz: nach JavaScript transpilieren

Genug gejammert – es gibt also viele Gründe, JavaScript nicht für die beste Sprache zu halten. Gleichzeitig ist sie eine der am weitesten verbreiteten Sprachen und vor allem aus der Webentwicklung nicht mehr wegzudenken. Anders Hejlsberg, Erfinder von Turbo Pascal und Delphi sowie Lead Architect von C#, dürfte dieser Widerspruch auch aufgefallen sein. Er und sein Team bei Microsoft hatten die Idee, die Flexibilität und Verbreitung von JavaScript zu nutzen und „syntaktischen Zucker“ darüber zu streuen, anstatt es zu ersetzen. So entstand ein Transpiler, der aus einer statisch typisierten Übermenge von JavaScript „normales“ JavaScript erzeugt, wobei die volle Flexibilität erhalten bleibt. Falls sich etwas nicht innerhalb der Typisierung ausdrücken lässt, kann man das Ergebnis eines Ausdrucks (Expression) immer als any deklarieren oder casten, was so viel wie „keine Transpiler-Überprüfungen“ bedeutet. Außerdem führte TypeScript schon von Beginn an Konzepte ein, die JS erst durch ECMAScript 6 bereitstellt, z. B. Klassen und Vererbung. Diese Konzepte bieten Entwicklern ein vertrautes Programmierparadigma.

Warum statische Typisierung etwas Gutes ist

„Let the compiler do the dirty work“ trifft den Punkt ganz genau: Jeder Fehler, den der Compiler – in diesem Fall Transpiler – zur Übersetzungszeit erkennt, bedeutet einen Laufzeitfehler weniger. Wie oben beschrieben, sind viele Fehler zur Laufzeit nicht direkt als Exception/Error erkennbar, sondern nur, wenn man sich die Ein- und Ausgabewerte der jeweiligen Funktion genau ansieht. Statische Typisierung bietet außerdem die Basis für echtes IntelliSense, bei dem die IDE aufgrund von Typinformationen erkennt, welche Member zu einem Objekt gehören. Ein umfangreiches Refactoring setzt ebenso Typinformationen voraus, ohne die es ansonsten im Wesentlichen zu einem „Search & Replace“ über viele Dateien hinweg degradiert. Es stimmt, dass sich manche Programmierkonstrukte ohne Typisierung schneller niederschreiben lassen, aber jede Überlegung, die man zur syntaktisch korrekten Formulierung investiert, macht sich später im Lifecycle mehrfach bezahlt.

Ein weiterer Nutzen statischer Typisierung wird sozusagen gratis mitgegeben, wenn Sie für den Client eine UI Templating Library verwenden, die nicht direkt auf HTML aufsetzt, sondern aus einem UI-Template Statements generiert, die zur Laufzeit DOM-Objekte erzeugen. Ein Beispiel dafür ist React. Die UI-Templates in React-JSX-Dateien sehen aus wie XHTML, werden aber von einem JSX-Compiler in JavaScript-Statements übersetzt. Und genau hier kommt der Mehrwert von TypeScript ins Spiel: Wenn diese Statements nicht nur in JavaScript, sondern in TypeScript vorliegen, kann sie der Transpiler vollständig überprüfen. Die TypeScript-Variante von JSX heißt TSX. Damit wird ein von Entwicklern seit Jahren gehegter Wunsch wahr: Nicht nur die Sprache ist statisch typisiert, sondern auch die Views/UI-Komponenten. Vorbei sind damit die Zeiten, in denen man erst zur Laufzeit bemerkt, dass man beim Data Binding eines UI Elements fristName statt firstName angegeben hat.

Erste praxisnahe Schritte – Vorbereitung mit npm

Wir beginnen gleich mit einem ersten TypeScript-Clientprogramm. Doch davor werden wir TypeScript so installieren, wie wir es in einem richtigen Projekt tun würden: mit einem Package Manager. npm (Node Package Manager) hat sich mittlerweile als führender Package Manager auch für Webclientprojekte durchgesetzt. Libraries wie Angular, React oder Vue lassen sich über npm bequem installieren. Zuerst installieren wir Node inklusive npm [1]. Danach erstellen wir package.json in Listing 1 und platzieren es in folgender Ordnerstruktur (die restlichen Dateien werden später noch erklärt):

  • TS01 (Rootfolder des Beispiels)

    • package.json

    • index.html

    • src

      • app.ts

      • customer.i.ts

      • customer.ts

      • customer.view.ts

      • tsconfig.json

Wir wechseln in den Ordner TS01 und rufe...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang