Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Webseite zu analysieren. Außerdem geben wir Informationen zu Ihrer Verwendung unserer Webseite an unsere Partner für soziale Medien, Webung und Analysen weiter. Unsere Partner führen diese Informationen möglicherweise mit weiteren Daten zusammen, die Sie ihnen bereitgestellt haben oder die sie im Rahmen Ihrer Nutzung der Dienste gesammelt haben. Sie akzeptieren unsere Cookies, wenn sie "Cookies zulassen" klicken und damit fortfahren diese Webseite zu nutzen.

Cookies zulassen Datenschutzerklärung

Typescript 2.0

Warum sich der Einsatz von Typescript in Ihrem Team lohnen könnte.

Coding

An Frontend-Entwicklung ohne den Einsatz von Javascript ist heute gar nicht mehr zu denken. Nicht nur Webanwendungen, sondern auch mobile Apps (react-native) und Backend Applikationen (node.js) werden mittlerweile mit JS geschrieben.

Es ist eine der meistbenutzten Sprache weltweit und immer mehr Entwickler kommen damit in Kontakt. Sollte es aber das erste mal sein, dass jemand eine untypisierte Sprache, wie JS, benutzen muss, kann es doch etwas zur Verwirrung führen.

Aber was heißt typisiert?

Programmiersprachen wie Java oder C++ sind objektorientiert und definieren neben Objekt-Klassen, für jedes Attribut eines Objektes, aber auch sonst für jede Variable im Code, einen Typ. Z.b. die Variable X soll also ein Typ Integer (eine runde Zahl) sein. Dieser Variable lassen sich ab jetzt nur noch runde Zahlen zuweisen. Im Vergleich dazu kann man bei Javascript, aber auch bei anderen untypisierten Sprachen wie Ruby, Python oder PHP, der Variable X zuerst einen Text zuweisen und in der nächsten Zeile eine Zahl und der Code ist weiterhin valide.

Mit den neuen Features von ES6 hat sich Javascript zu einer sehr sauber zu benutzenden Sprache entwickelt. Wer die Neuerungen von ES6 noch nicht kennt, kann sich auf dieser Seite alle wichtiges anschauen. Man kann für JS einige Packages benutzen um auch Typisierung aufzulegen, aber wenn man wirklich eine richtige objektorientierte Umgebung möchte, dann ist Typescript heute die beste Wahl.


Typescript Language


Bei zauberware entwickeln wir seit Jahren mit Ruby, Python und Javascript, sowohl für das Backend (Node.js) als auch für das Frontend (react.js, react-native). Richtig programmieren gelernt hat man allerdings damals mit typisierten Sprachen. In unserem Team mussten wir alle durch die harte Schule: Java, C, C++. Der erste Kontakt mit Python, Ruby und JS war wie eine Erleuchtung: Endlich frei, endlich schnell und dynamisch. Nicht-typisiert heißt nicht, dass es keine Vorzüge von Objektorientierung gibt: In Ruby gibt es bei uns kein Objekt ohne eine Klasse dahinter. Aber irgendwie hat sich eine Distanz zu Sprachen wie Java und C++ aufgebaut, die sich jetzt durch Typescript bei mir wieder verringert hat.

Also, welche Vorteile kann der Einsatz von Typescript bringen?

Der Code ist schneller zu verstehen

Benutzt man in einem Projekt Code, den man nicht selbst geschrieben hat, stellen sich sofort ein paar wesentliche Fragen: Welche Parameter darf ich für die Funktion oder Komponente benutzen? Was ist der Rückgabewert? Welche externen Objekte werden benutzt? Was haben diese Objekte für Attribute oder Methoden?

Eine einzige geöffnete JS Datei kann diese Fragen erstmal nicht direkt alle beantworten. Dazu muss man schon genau die benutzten Module oder die Funktionen öffnen und sich anschauen was dort passiert. Sollte man es nicht verstehen ist die häufigste Methode das berühmte console.log(e), was auch laut witzigen Twitter-Threads das Debugging Tool für JS-Entwickler ist. Reicht ein console.log immer noch nicht, muss im schlimmsten Fall die EntwicklerIn jemanden finden, der einem den Code erklärt.

Mit dem Einsatz von Typescript sind diese Probleme vorbei. Jedes Objekt und jede Methode hat klar definierte Argumente und Rückgabewerte. Diese werden mir auch von meiner IDE vorgeschlagen und direkt validiert.

Neuer Code ist einfacher zu implementieren:

Der Standardweg um z.B. eine neue Komponente zu erstellen sind die folgenden:

  1. Template einer Komponente wird erstellt und im Konstruktor die Argumente definiert, sowie die Business Logik geschrieben.
  2. Werden externe Objekte benutzt, wie z.B. ein Nutzer-Objekt, mache ich mich auf die Suche im Code wo es schon einmal benutzt wurde, damit ich die Struktur sehe.
  3. Die Komponente wird im eigentlich Projekt mit den Argumenten eingebaut.
  4. Gleichzeitig wird ein Unit-Test erstellt, in dem erstmal nur die Komponente mit den Argumenten auf ein “ich-kann-mich-rendern” getestet.
  5. Man testet die Komponente direkt mit Browser-Refresh und dem Unit-Test.
  6. Es wird solange am Code gearbeitet bis mit refresh und console.log keine Unauffälligkeiten mehr entdeckt werden.

Im Vergleich dazu der Weg für Typescript:

  1. Template einer Komponente wird erstellt und im Konstruktor die Argumente mit Typen definiert, sowie der Rest der Logik geschrieben.
  2. Wenn externe Objekte wie aus dem Beispiel das Nutzer-Objekt benutzt wird, kann man es einfach mit der IDE nachschauen, teilweise oder ganz als Interface benutzen.
  3. Komponente wird im eigentlich Projekt mit den Argumenten eingebaut.
  4. Der Unit-Test beschränkt sich jetzt nur noch auf die Business-Logik, denn durch die Typen kann ich mir Tests mit verschiedenen Argumenten sparen.
  5. Fertig!

Refactoring von Quellcode ist einfacher

Bei einem alten Code ein Refactoring zu machen ist immer auch mit Fehlersuche verbunden. Wo wird meine Komponente oder Funktion überall benutzt? Wer erwartet welche Werte von mir als Rückgabe? Der normale Weg ist oft eine Suche über das gesamte Projekt. Dann ändert man ggf. die Argumente und hofft nichts kaputt gemacht zu haben.

Mit Typescript wird die Sache vereinfacht. Ändere ich mein Interface, meine Funktion oder meine Komponente, dann weiß die IDE sofort über das ganze Projekt, wo etwas nicht mehr stimmt. Ich bekomme die Fehler gesagt, bevor ich sie mir in der Browser-Konsole anschauen muss.

Weniger Fehler

Die console.log(e)-Debugging-Sache hat mich sehr beschäftigt und auch wir im Team benutzen sehr häufig einfach diese Methode um festzustellen, was eigentlich los ist. In vermutlich 50% der Fälle hätte uns der Einsatz von Typescript das erspart, da man oft erst nach Zuruf des Kollegen "Da hast du den falschen Wert reingegeben. Er braucht ein Integer, kein String" das Problem gelöst hat.

Keine boilerplate Tests

Eine Typescript Komponente zu erstellen dauert auf jeden Fall länger, als mit normalen JS. Die Zeit spart man hier aber später, da man keine dummy-Unit-Tests mehr erstellen muss, die einfach nur auf de richtigen Einsatz von Properties schauen. Das ist durch die Typisierung jetzt abgesichert.

Es ist einfacher Quellcode zusammenzuführen

Wir verbringen sehr viel Zeit beim mergen von größeren Änderungen an unseren Projekten. Durch Unit-Tests kann man eigentlich sicher sein, dass alles noch funktionieren sollte, aber sind alle Frontends zu 100% getestet? Ja, das ist auch unser Ziel, aber die Realität sieht wohl anders aus, ich vermute auch bei Ihnen im Team. Ich muss also noch einmal alles per Hand mi Browser testen, damit ich wirklich sicher sein kann, dass der PR richtig gemerged wurde.

Typescript und die Rückmeldungen in der IDE sind bei PRs eine enorme Hilfe und vermeiden es, fehlerhaften Code zu mergen.

Einfacher für Neulinge

Die Lernkurve bei Typescript ist natürlich etwas höher als bei Standard ES6. Bringt man aber ein Verständnis für objektorientierte Programmierung mit, dann ist es nur eine Gewöhnung an die neue Syntax. Hat man Typescript verstanden, dann ist es vor allem als neue EntwicklerIn in einem Projekt perfekt um sich zu orientieren und man kann Code schreiben, der schonmal grundsätzlich valide ist.

Typescript nimmt hier demjenigen, der das Code-Review macht, enorm viel Zeit ab.

Typescript bringt den richtigen Workflow

Typescript zwingt einen bei der Entwicklung sich vorab Gedanken darüber zu machen was genau die Komponente oder Funktion können soll, welche Argumente akzeptiert werden, was für Interfaces benutzt werden und was zurückgegeben werden soll. Allein beim Schreiben des Codes folgt man schon den Prinzipien von Test Driven Development. Gibt man jetzt noch einen Unittest zur Business-Logik hinzu, erhält man sauberen und nicht mehr fehleranfälligen Code und kann zudem noch mit Stolz verlauten lassen: Wir machen TDD in unseren Frontends.

Fragen, die wir uns stellen oder uns gestellt wurden:

Dauert es es nicht ewig Typescript im Team einzuführen?

Ich würde sagen Nein, denn es gibt sehr gute Blogposts, Videos und Kurse über Typescript und die Community ist mittlerweile riesig. Wichtig ist aber glaube ich, im Team abzutasten wie es mit objektorientierter Programmierung aussieht. Ein studierter Informatiker lernt das im 1. Semester und sollte jemand über Umwege ein Programmierer geworden sein und schon erfolgreich JS programmieren, dann hat er das Konzept von OO-Programmierung auch schnell verstanden. Man sollte es einfach bei einem Projekt ausprobieren. Man kann Typescript und JS auch parallel in einem Projekt programmieren.

Seid Ihr bei zauberware 100% Typescript?

Nein, das sind wir nicht. Wir haben gerade angefangen es im Team zu etablieren und setzen es in neuen Projekten ein. Es sind auch noch nicht alle Fans der Technologie. Neue Technologie probieren wir natürlich alle gerne aus, entscheiden dann aber im Team gemeinsam, ob wir sie langfristig einsetzen möchten oder nicht. Aktuell sind wir also in der Testphase.

Ist Typescript auch für Node.js zu empfehlen?

Wir werden TS nicht auf dem Server einsetzen, da wir dort nicht die Problematik mit 1000-verschiedenen Argumenten haben wie bei unseren Frontend-Komponenten. Außerdem ist ein Zwischenschritt notwendig um die TS-Dateien in JS-Dateien umzuwandeln. Im Frontend haben wir den Schritt sowieso schon in unserem Entwicklungsprozess von daher ist es kein Mehraufwand. Wir werden das Thema aber weiterhin beobachten.

Ist Typescript zukunftssicher?

Für die nächsten Jahre sieht es erstmal nicht so aus, als ob das Ecma T39 Komitee das “Static Type System” für JS einführt. Das würde natürlich Typescript obsolet machen. Aber bis es so weit ist, gibt es dann auch sicher eine Möglichkeit die Typescript-Dateien wieder JS-Dateien umzuwandeln.

Ursprüngliche Frage: Warum sich der Einsatz lohnen könnte?

Weniger Fehler während der Entwicklung und nach einem Release bedeutet ganz klar und einfach:

  1. Weniger Bugs
  2. Glückliche Nutzer
  3. Glückliche Kunden
  4. Glückliche Product Owner
  5. Glückliche Entwickler

Der zeitliche Aufwand das Team auf TS umzustellen wird später auch dadurch gespart, dass man viel weniger auf Fehlersuche ist.

Also BITTE JA, testen Sie TypeScript bei ihrem nächsten JS Projekt aus und sammeln Sie eigene Erfahrungen.

Typescript Statistiken

Popularität:

Typescript Popularität

Quelle: https://2018.stateofjs.com/jav...

Was andere Entwickler an Typescript lieben:

Typescript am meisten geliebt

Quelle: https://2018.stateofjs.com/javascript-flav...

Was andere Entwickler an TypeScript nicht mögen:

Typescript am meisten gehasst

Quelle: https://2018.stateofjs.com/javascrip...

Ich hoffe ich konnte euch beim Thema Typescript weiterhelfen. Wer direkt ausprobieren möchte empfehle ich den schnellen Kurs bei freecodecamp.org oder schaut sich direkt auf https://www.typescriptlang.org/ um.



Teile diesen Artikel:

zauberware logo