Warum Du TypeScript lernen solltest. 

Dennis: Willkommen zu einer neuen Podcast-Episode, vielleicht kennst du mich ja schon aus früheren Episoden. Mein Name ist Dennis. Ich bin Softwareentwickler bei consistec. Und heute habe ich euch einen Kollegen von mir mitgebracht, Lucas. Lucas, vielleicht kannst du dich kurz vorstellen.

Lucas: Hallo, ich bin auch Softwareentwickler bei consistec. Ich arbeite seit drei oder vier Jahren mit TypeScript und davor mit Java.

Dennis: Ja, du hast es schon erwähnt TypeScript, das heutige Thema wird sich um TypeScript drehen. Das ist die Sprache, für die du dich sehr begeisterst. Und wir wollen den Leuten heute erklären, warum TypeScript? Was ist TypeScript und warum wir denken, dass es für viele Softwareentwickler und besonders für Frontend-Entwickler interessant ist, TypeScript zu lernen. Vielleicht kannst du uns einen einen kleinen Überblick darüber geben, was wir heute besprechen wollen.

Lucas: Ja, ich möchte die Zuhörer davon überzeugen, dass es sich auf jeden Fall lohnt, TypeScript zu lernen. Wenn man bereits JavaScript kennt, ist es super einfach und bringt enorme Vorteile.

Dennis: Ja, und um die Einzigartigkeit von TypeScript als Sprache zu erklären, eine stark typisierte Sprache. Und wir werden später auch erklären, was das bedeutet. Wir wollen heute diskutieren und erklären warum es interessant ist, die Zeit zu investieren und nicht nur JavaScript, sondern auch TypeScript zu lernen. Vielleicht fangen wir also an und erklären, was TypeScript ist? Und was ist es im Vergleich zu, zum Beispiel, JavaScript?

Lucas: Richtig. Ich denke, jeder, der schon einmal JavaScript geschrieben hat, kann mir nachfühlen, dass es sehr unangenehm ist. In JavaScript muss man jedes Mal, wenn man einen bestehenden Code verwenden will, also eine Funktion aufruft, muss man den Code durchgehen und prüfen, welche Parameter es gibt, wie viele Parameter es sind oder wie sie aussehen sollen. Um sicherzugehen, dass alles funktioniert, muss man all diese Alter oder was auch immer man geändert hat, durchgehen. TypeScript löst das durch die Einführung von Typisierung, starker Typisierung. Das ist alles, weil JavaScript ist keine typisierte Sprache. Es hat überhaupt keine Typen. Also, was hat TypeScript gemacht? Es fügt Typen zu JavaScript hinzu. Und TypeScript ist einfach ein Superset von JavaScript. Das heißt, es macht alles, was JavaScript tut und erlaubt es, Typen zu definieren.. Sie können also Beschränkungen in Code hinzufügen, die besagen, dass diese Funktion nur mit diesen bestimmten Arten von Dingen aufgerufen werden kann, während in JavaScript kann man das nicht so machen.

Dennis: Du meinst also, sie kann nur mit einem Leistungsmesser vom Typ Integer aufgerufen werden, zum Beispiel?

Lucas: Ganz genau. Man kann definieren, dass die Funktion mit einem Objekt codiert werden muss, das diese bestimmte Felder hat. So können Sie immer sofort sehen, wenn Sie diese Funktion sehen, Sie verwenden wollen, was Sie ihr geben müssen, anders als in JavaScript, musst du dich nicht um die Implementierung kümmern.

Dennis: Bei JavaScript kann man einfach alles eingeben. Und wenn der Code dann läuft, also zur Laufzeit, funktioniert er entweder oder er funktioniert nicht. Also, ich werde einfach später herausfinden, ob das, was ich geschrieben habe, tatsächlich passt.

Lucas: Genau. Das heißt, mit TypeScript eliminieren diese ganze Klasse von potenziellen Fehlerquellen Fehlern, diese typbezogenen Fehler, die man zur Kompilierzeit und nicht zur Laufzeit bekommt. Man muss sich nicht mehr darum kümmern, wenn der Compiler einem direkt sagt wo der Fehler ist.

Dennis: In gewisser Weise ist es also nur ein weiteres Werkzeug für den Entwickler, diese alte Typisierungssyntax. Sie hilft Code in der Zukunft zu schreiben, denn es gibt dieses frühe Feedback. Du rufst die Funktion hier mit Parameterwerten auf. Sie passt nicht in die Typdefinition der Funktion.

Lucas: Ja, genau. TypeScript hat eigentlich keinen Einfluss auf die Laufzeit. Es ist also rein für den Entwickler. Damit kann man sehen, wie die Dinge verwendet werden sollen.

Dennis: Vielleicht kannst du auch ein bisschen erklären, wie das funktioniert. Wir haben alle eine Vorstellung davon, dass es um Frontend-Entwicklung geht, sozusagen das Gesicht derWebsite. Aber wo passt TypeScript in dieses ganze Konzept, was machen wir damit?

Lucas: Richtig. Browser führen nur JavaScript aus. Das ist eine unbestreitbare Tatsache, daran können wir nichts ändern. Aber wenn wir TypeScript und all diese Typisierungen verwenden wollen, bedeutet das, dass wir TypeScript in JavaScript transpilieren müssen. TypeScript in JavaScript transpilieren, bevor wir es im Browser ausführen können.

Dennis: Für unsere Zuhörer bedeutet Transpilierung also, dass man von einer Programmiersprache in eine andere eine andere Programmiersprache auf dem gleichen Niveau übersetzt. Wenn man also eine Programmiersprache auf hohem Niveau hat, Programmiersprache wie TypeScript hat und in JavaScript transpilieren will, muss man in eine Sprache transpilieren, die das gleiche Niveau hat. Es handelt sich also nicht um eine Programmiersprache mit niedrigem Niveau wie zum Beispiel C.

Lucas: Richtig. Im Grunde übersetzt man nur den Code. Und wenn man TypeScript in JavaScript transpiliert, sind all diese netten Typisierungsfunktionen weg. Das Zeug existiert also nur in der Entwicklungszeit.

Dennis: Wir haben also im Grunde nur JavaScript-Code.

Lucas: Genau, nur reines JavaScript.

Dennis: Es ist also im Grunde eine Erweiterung von JavaScript um eine Syntax, in der man Typen definieren kann. Und das ist auch etwas, was wir jetzt erklären wollen, aber als ein Typisierungssystem und eine Programmiersprache, vielleichtkannst du in einem einfachen Satz erklären, was das eigentlich bedeutet. Was bedeutet es, eine stark typisierte Sprache zu haben?

Lucas: Genau. Eine stark typisierte Sprache ist eine Sprache, in der alles, was man tut, explizit erlaubt sein muss durch die Typen, die man verwendet, erlaubt sein muss. In einer Sprache wie JavaScript gibt es also keine Typisierung.

Dennis: JavaScript wäre also eine dynamische Typsprache, d.h. die Typüberprüfung findet zur Laufzeit und nicht zur Kompilierzeit, wie bei einer Typsprache statt, richtig?

Lucas: Ja, genau. In der Praxis, wenn man JavaScript entwickelt, gibt es keine Typisierung überhaupt keine, man hat nichts geschrieben und muss nicht alle Zeitalter kompilieren, um herauszufinden, ob es funktioniert oder nicht, zur Laufzeit. Bei einer kompilierten Sprache hingegen, einer stark typisierten Sprache wie Java, stellt der Compiler sicher, dass alles was Sie tun, auch wirklich mit den Typen die Sie verwenden, erlaubt ist.

Dennis: In der Praxis bedeutet das also, wenn ich meine IDE oder meinen VS-Code öffne und programmieren will wenn ich eine dynamische Typsprache wie JavaScript oder Python oder so programmiere, dann werde ich einfach herausfinden, ob das, was ich geschrieben habe, funktioniert, ob das Objekt die Methode hat, die ich zur Laufzeit aufgerufen habe, wenn ich den Code ausführe. Wenn ich aber zum Beispiel TypeScript oder Java programmiere, die statisch typisierte Sprachen sind typisierte Sprachen sind, finde ich das schon zur Kompilierzeit heraus. Ich bekomme also sofort von meiner IDE, hey, du versuchst, die Methode greetings bei einer Objektinstanz einer Person auszuführen und diese Person hat diese Methode nicht. Also können Sie das nicht tun.

Lucas: Richtig. Das ist der größte Vorteil von typisierten Sprachen, man eliminiert eine ganze Klasse von potentieller Fehler. Man fängt sie zur Kompilierzeit ab, weil man weiß, wo sie sind, statt sie zur Laufzeit finden zu müssen, was sehr viel mühsamer ist. Der Nachteil, den man ist, dass es mehr Aufwand bedeutet, die Typen von allem zu definieren, die beweglichen Elemente.

Dennis: Ja. Und in gewisser Weise gibt einem die Sprache ein bisschen früher Feedback über Fehler, die man möglicherweise gemacht hat, aber nur Fehler, die man in Bezug auf den Typ gemacht hat. Man kann also immer noch Programmcode schreiben, der aus einer Million anderer Gründe nicht funktioniert. Aber zumindest kann Ihr Sprachcompiler sagen, dass du die Typen richtig verwendet hast. Sie haben mir also gesagt, dies ist die Typdefinition einer Person, diese Person hat ein Attribut Name, Nachname, sie muss diese Methode haben. Und jetzt kann der kann der Compiler für mich prüfen, ob ich diese Person-Objektinstanz korrekt in meinem Code verwende, oder ob ich eine Methode aufgerufen habe, die es bei einer Person-Objektinstanz nicht gibt.

Lucas: Richtig. Je mehr potentielle Fehler der Compiler für dich eliminiert, desto weniger musst du dich mit denen beschäftigen. Auf lange Sicht spart man also Zeit. Es ist besonders hilfreich, wenn du Code refactorst. Sie haben vorhandenen nicht typisierten Code, den Sie ändern wollen, insbesondere wenn du die Signaturen von Funktionen oder die Typen von irgendetwas ändern willst. Wenn die verwendete Sprache nicht typisiert ist, musst du im Grunde jede einzelne Verwendung im gesamten Projekt überprüfen, um sicherzugehen, dass es noch überall passt.

Dennis: Ja, das ist eine interessante Idee. Eine weitere Sache, die ich an Typsprachen mag ist, dass sie auch teilweise selbstdokumentierend sind. Wenn ich zum Beispiel eine Funktion schreibe, die einen Parameter mit dem Namen Person hat, weiß ich in einer dynamischen Typsprache wie Python vielleicht nicht, ob dies der Name der Person ist oder ob es sich in einer typisierten Sprache wie TypeScript wirklich um eine Objektinstanz vom Typ "Person" handelt? Ich kann das am Funktionskopf erkennen, weil er mir sagt, dass der Parameter "Person" vom Typ "Person" ist, oder zum Beispiel vom Typ "string". Das nimmt mir die Verantwortung ab, auch zu dokumentieren, was dieser Parameter tatsächlich ist. Es macht es einfacher für mich, ich muss es nicht in den Parameternamen kodieren oder es in einen Doc-String schreiben.

Lucas: Auf jeden Fall. Je weniger explizite Dokumentation man braucht, um den Code tatsächlich zu verstehen, desto besser, oder? Das macht es offensichtlicher. Wenn du zum Beispiel eine Funktion siehst, die eine Art von Möbeln nimmt und ihr eine andere Art von Parametern gibt, welche Transformationen passieren dann mit den Daten, die du ihr gibst?

Dennis: Ja, so sehe ich das auch. Ich denke, es ist immer besser, expliziteren Code zu schreiben und weniger Dokumentation zu schreiben. Denn am Ende stellt der Interpreter oder Compiler nicht sicher, dass deine Dokumentation korrekt ist. Man kann nicht den Funktionskopf ändern, aber man kann vergessen, die Dokumentation zu ändern, die dir sagt, dass dieser Parameter diesen Typ hat. Das ist typischerweise in Python der Fall, wo man eine bestimmte Syntax hat, wie man die Typen von Parametern von Funktionen im Doc-String dokumentieren kann. Und dann ändern Sie den Parametertyp, aber Sie vergessen, den Doc-String zu ändern, und dann glauben die Leute, ah okay, es wird mit diesem Typ aufgerufen, aber in Wirklichkeit ist es nicht so. Und das ist in der Praxis ziemlich knifflig, und passiert ziemlich schnell.

Lucas: Und deshalb muss man bei Docstrings immer darauf achten, dass man immer beide parallel bearbeitet, wenn man eine Änderung an einem macht, muss man den anderen aktualisieren, man muss das manuell synchronisieren. Bei Typen hingegen gibt es keine Möglichkeit, das nicht zu tun, es ist im Grunde nur eins, man kann nicht das eine ändern und das andere nicht.

Dennis: So, jetzt haben wir irgendwie schon erklärt, was die Vorteile oder die Motivation sind zwischen Typisierungen und wie TypeScript mit JavaScript zusammenkommt und das es im Grunde eine Erweiterung ist. Und eine weitere Sache, über die ich mit dir sprechen möchte ist, dass TypeScript sehr speziell in der Art und Weise ist, wie es Typisierung implementiert. Man könnte also argumentieren, dass TypeScript eine dynamisch typisierte Sprache sein kann, und gleichzeitig eine ästhetische Typsprache, es ist eine Art Hybrid. Man kann zum Beispiel das Schlüsselwort "any" in TypeScript verwenden, um dem Compiler mitzuteilen, dass ich zum Beispiel eine Variable oder einen Parameter hier habe, dessen Typ ich nicht kenne, aber ich möchte auch, dass du ihn komplett ignorierst. So wird dies im Grunde ein Parameter, der überhaupt nicht typisiert ist. Ich kann damit machen, was ich will, so wie ich es zum Beispiel in JavaScript tun könnte.

Lucas: Richtig. Nun, die Sache ist die, dass Typen in TypeScript im Grunde nur eine Illusion sind, weil sie nur in der Entwicklungszeit existieren, richtig? Im Endeffekt kann man TypeScript nicht direkt verwenden, weil der Browser wird nichts außer JavaScript ausführen. Also muss man es in JavaScript übersetzen. Und dadurch werden die Typen eliminiert. Sie sind also nur hilfreich für den Entwickler während der Entwicklung.

Dennis: Sie sind eigentlich nur ein Werkzeug, das der TypeScript-Compiler verwendet, um die Typenprüfung durchzuführen. Aber danach sind sie einfach verschwunden. Denn wie du schon sagtest, wir übersetzen in JavaScript. Eine weitere Sache, die ich an TypeScript wirklich mag, wir haben beide mit Java gearbeitet und Java ist ziemlich langatmig. Es ist sehr stark typisiert und sehr eigenwillig wie man bestimmte Dinge tun kann. Also allles muss einen Typ haben. Und in TypeScript ist man flexibler. Man hat also die Möglichkeit zu sagen, hey, ich habe ein beliebiges Schlüsselwort verwendet und sage: okay, der Typ dieser Objektinstanz oder dieses Parameters ist nicht interessant. Wir wollen da keine Typisierung erzwingen. Aber man kann auch mit den Typen machen, weil sie in TypeScript separat definiert werden, man kann sie kombinieren. Also kann man etwas erstellen, dass wir Schnittmengen- und Vereinigungstypen nennen. So könnte man zum Beispiel sagen, dieser Parameter, den ich habe, dieser Parameter "foo", könnte eine Person sein, er könnte ein Buchhalter sein. Es könnten also mehrere Dinge sein, die wir Vereinigungstypen nennen. Andererseits könnte man auch sagen dieser Parameter "foo" ist gleichzeitig eine Person und ein Buchhalter. Und dann bedeutet das, dass er alle Attribute der Person und alle Attribute des Buchhalters hat. In anderen Sprachen wie Java müsste man eine neue Klasse erstellen, um diesen neuen Typ zu beschreiben.

Lucas: Richtig. Wie ich schon sagte, gibt es Typen in TypeScript nicht zur Laufzeit, sondern nur zur Entwicklungszeit. Und das erlaubt dir zunächst einmal zu wählen, wie stark typisiert der Code ist. Du musst nicht komplett typisiert wie Java wählen, sondern du kannst wählen, was genau du typisiert haben willst, was sich wie JavaScript verhalten soll, wie streng deine Typdefinitionen sind. Und zweitens erlaubt es dir, alle möglichen interessanten Dinge mit Typen zu tun, alle Arten von Operationen mit Typen, die man in anderen Sprachen nicht machen kann, weil sie zur Laufzeit existieren würden, richtig? Man kann also, wie du sagtest, Vereinigungstypen haben, wo man zwei Typen hat und man ein Objekt erstellt, das alle Felder beider Typen enthält, hat man immer noch eine Möglichkeit, diese neue Zeit auszudrücken, wie A und B, richtig? Eine meiner Lieblingsfunktionen, um ehrlich zu sein sind Tupel in JavaScript oder TypeScript, die im Grunde als einfaches Array ausgedrückt werden. Aber zunächst einmal kennen wir die Länge dieses Arrays und wir kennen den Typ eines jeden Elements in dem Array, richtig? Und in den letzten Versionen von TypeScript kann man auch einen Namen zuweisen. So, war das eine sehr nützliche Möglichkeit, Tupel dynamisch zu erstellen, ohne Typen explizit zu definieren, so wie man es in Java tun müsste.

Dennis: Ja, es kombiniert sozusagen das Beste aus zwei Welten. JavaScript ist also eine Sprache, die einem eine Menge Flexibilität gibt. In Java kann ich zum Beispiel ein beliebiges Objekt erstellen, ich öffne einfach die Anführungszeichen und ich erzeuge ein Objekt und kann ihm beliebige Attribute geben. Und jetzt mit TypeScript kann ich eine Schnittstelle definieren. Und nicht nur einen Typ über die Schnittstelle an das Objekt anhängen, das ich erstellt habe gibt mir eine enorme Menge an Flexibilität. Und das hilft mir auch, weniger Code zu schreiben, so seltsam es klingt, denn in Sprachen wie Java ist das Typisierungssystem sehr umfangreich, man muss man viel so genannten Boilerplate-Code schreiben. Obligatorischer Code, den man schreiben muss um bestimmte Ziele zu erreichen. Und in Sprachen wie Python, zum Beispiel, die eine dynamischen Typisierungssprache Sprache ist, kann ich eine Menge Dinge mit weniger Code tun als in Java. Und jetzt ist die coole Sache mit TypeScript. TypeScript geht auch in diese Ecke, es ist immer noch eine stark typisierte Sprache, aber Es ist immer noch eine stark typisierte Sprache, aber es eliminiert eine Menge des Boiler- Plate Codes, weil man immer noch die Flexibilität von JavaScript hat. Und das gefällt mir sehr gut daran.

Lucas: Meiner Meinung nach ist das einer der größten Vorteile von TypeScript. Es macht es sehr einfach, alle Arten von Typen auszudrücken. Und natürlich könnte man auf die ausführliche Java-Art eine Klasse definieren mit all ihren Feldern, Methoden und Implementierungen definieren. Oder wir könnten einfach eine Schnittstelle definieren oder die Felder und nur Typen. Oder man könnte einfach einen Typ als Kombination mit Operationen von anderen Typen definieren, z.B. Typ A und eine Teilmenge der Felder von Typ B, zum Beispiel.

Dennis: Die Stärke von TypeScript ist also die Wiederverwendbarkeit der Typen, die man definiert. Die man natürlich in gewisser Weise auch in Java hat, aber TypeScript gibt einem einfach ein riesiges Toolset an die Hand: Wiederverwendung und Komposition und Kombination von Typen, die man bereits hat. Und das ist wirklich schön, weil man am Ende weniger Schnittstellencode schreibt. Und tatsächlich mehr Code, der tatsächlich die Sache erledigt. Okay. Also, wir haben bereits über eine Reihe von Dingen im Typisierungssystem gesprochen. Eine weitere Sache, die ich sehr schön finde und über die ich gerne sprechen würde, sind optionale Typen. Vielleicht kannst du den Zuhörern ein wenig erklären, was undefinierte Typen bedeuten und was optionale Typen wirklich sind.

Lucas: In Ordnung. Vorab möchte ich darauf hinweisen, dass in Java jeder Typ nullbar ist. Wenn du einen Parameter des Typs "foo" hast, prüft er, ob dieser tatsächlich definiert ist. Man kann dem Compiler sagen, dass dieser immer definiert sein wird. Wohingegen in TypeScript, standardmäßig nichts bekannt ist. Wenn es definiert ist, dass ein Parameter den Typ x hat, ist er immer x, er kann nicht null sein. Aber man kann auch definieren, dass der andere Typ x oder undefiniert ist, was bedeutet, dass man x definieren kann, wenn man will, man muss es aber nicht. Oder man kann sagen, dass es null ist, was die meisten Leute so verstehen, dass es keinen Wert hat. Das ist ein sehr feiner Unterschied, aber sehr nützlich in der Praxis.

Dennis: Du hast also diese Differenzierung. In Java könnte der Nullwert für ein Objekt oder eine Variable  bedeuten, dass jemand keinen realen Wert angegeben hat oder dass der reale Wert im Grunde der leere Wert ist, der Nullwert. Und dann ist TypeScript getrennt. Man hat also den Typ "undefined", der sagt, okay, hier hat jemand wirklich keinen Wert für den Parameter angegeben. Und du hast den Wert null, der wirklich sagt, dass das der leere Wert ist. Und das ist ziemlich interessant und es ist auch interessant, wie TypeScript das in die Sprache einbaut. Man hat also diesen Fragezeichen-Operator, also man schreibt eine Funktion und hat einen Parameter "foo". Und wenn man hinter den Namen "foo" ein Fragezeichen setzt, teilt man dem TypeScript-Compiler mit, dass der Wert für foo ein echter Wert sein kann, oder er kann undefiniert sein. Und das hat auch Auswirkungen auf Ihren Code. Du kannst also eine Option in TypeScript wählen, die als strikte Nullprüfung bezeichnet wird, was bedeutet, dass, wenn du dich mit undefinierten Parametern oder Variablen umgibst, müssen du explizit prüfen, ob der Wert derzeit undefiniert ist, wenn man etwas damit machen will. Und das ist wirklich interessant, denn es beseitigt ein großes Problem, das wir in Programmiersprachen haben, wo man einen Nullzeiger bekommt. Es gibt Ausnahmen, wenn man auf einen Wert zugreift, der null ist,  typischerweise passiert das in Java sehr oft, weil der Nullwert für alles verwendet werden kann. Und TypeScript ist sehr explizit und kann Ihnen sagen, okay, hier, dieser Wert kann wirklich undefiniert sein, du musst sicherstellen, dass er nicht undefiniert null ist.

Lucas: Ganz genau. Das wiederum eliminiert eine ganze Klasse von potentiellen Problemen, richtig? Wenn du in deiner Funktion einen beliebigen Parameter des Typs X erhältst, weißt du, dass er eigentlich immer funktioniert. Man muss nicht mehr prüfen, ob er definiert ist. Und das Interessante daran ist, dass das Zulassen eines Typs undefiniert zu sein, nichts anderes ist als eine Typvereinigung des angegebenen Typs und undefined ist, was an und für sich auch ein Typ in TypeScript ist.

Dennis: Man könnte also, anstatt diesen Fragezeichenoperator zu schreiben, der eine Art "syntaktischer Zucker" der TypeScript-Sprache ist, könnte man auch explizit schreiben, dass es sich um den tatsächlichen Typ des Parameters handelt zum Beispiel "String" oder "undefiniert".

Lucas: Ja, das ist fast dasselbe. In den neuesten Versionen von TypeScript gibt es eine kleine Unterscheidung. Das Fragezeichen bedeutet, dass der Parameter optional ist, was bedeutet, dass er im Objekt enthalten sein kann oder nicht. Während "type" oder "undefined" bedeutet, dass er im Objekt mit dem Wert undefiniert ist. Ein kleiner Unterschied, aber er kann manchmal relevant sein.

Dennis: Also Lucas, wir haben jetzt viel über die TypeScript-Spracheigenschaften gesprochen. Die letzte Sache, die ich kurz ansprechen möchte, wir haben ja schon ein bisschen darüber gesprochen mit dem District Nine Checking ist, dass man den TypeScript-Compiler tatsächlich für seinen Anwendungsfall konfigurieren kann.

Lucas: Richtig. Man kann diese beiden Flags in der Konfiguration haben, eine implizite "any" und "strict null" Prüfung, mit denen man physikalisch konfigurieren kann, ob man diese strikte Nullprüfung will oder ob du willst, dass es sich wie Java verhält, also ohne die Garantie, dass die Typen immer nicht nullbar sind. Und das "no implicit any", das Ihnen verbieten würde, irgendwelche Parameter zu haben, ohne irgendwelche Typ-Annotationen, die standardmäßig "any" sind. Das wird also das Verhalten von JavaScript sein.

Dennis: Es wird also nicht sagen: Hey, ich habe eine Variable deklariert. Und wenn ich keinen Typ dahinter schreibe, ist es implizit irgendeine Notiz, wenn ich sie auf false setze, dann muss ich wirklich allem einen Typ zuweisen. Und das muss ich es explizit sagen. Und das erste war, dass, wenn ich dieses Fragezeichen hinter dem Parameter habe, und er kann undefiniert sein, und ich bin durch den TypeScript-Compiler gezwungen, wirklich zu prüfen, ob der Wert undefiniert ist, bevor ich etwas damit machen kann. Ja, und das ist etwas, das wirklichdenn in Sprachen wie Java kann man den Compiler normalerweise nicht nach seinen Bedürfnissen konfigurieren Bedürfnisse konfigurieren, was man mit TypeScript tun kann. Und ich denke, das gibt dem Ganzen einen netten Touch, einen netten einen Hauch von Flexibilität.

Lucas: Nun, das liegt wiederum daran, dass die Typen nur in der Entwicklungszeit existieren. Also, wir haben nicht wirklich Beschränkungen, wie wir die Typen umwandeln können, bevor sie kompiliert werden, weil sie überhaupt nicht kompiliert werden. Man kann also im Grunde keine Einschränkungen machen oder man kann sie einfach das tun lassen, was man will, wie auch immer man es für richtig hält.

Dennis: Ja, denn am Ende wird es ja irgendwie zu JavaScript-Code. Und das ist die Aufgabe des TypeScript-Compilers bzw. gibt dir die Möglichkeit, eine solche Konfiguration zu implementieren und sie an deine Bedürfnisse anzupassen.

Lucas: Ja, genau.

Dennis: So, jetzt haben wir einen wirklich guten Blick auf TypeScript. Jetzt möchte ich dich wirklich fragen, würdest du TypeScript für jedes Projekt verwenden oder für welche Projekte würdest du es verwenden?

Lucas: Ich persönlich würde, außer für die kleinsten Ansätze, immer TypeScript verwenden. Es überwiegt für mich der Vorteil der Typisierung immer den zusätzlichen Aufwand, erstens den Code zu transpilieren und Typen zu spezifizieren. Das ist für mich einfach ein Riesenplus.

Dennis: Ja, ich sehe das ganz ähnlich. Gerade wenn man heute ein Projekt beginnt, weiß man nicht, wie groß es werden wird. Und auf lange Sicht zahlt es sich immer aus, diese Art von Informationen zu haben, es macht die Arbeit mit dem Code in der Zukunft einfacher. Und normalerweise schreibt man den Code nur einmal, aber man muss ihn im Idealfall für immer pflegen und mit ihm arbeiten, oder sagen wir, für ein paar Jahre oder? Langfristig gesehen ist es also eine Investition in Ihren Programmiercode, eine Typsprache zu verwenden. Ich denke, eine Sache, die wir erwähnen sollten, ist es für jeden oder sollte jeder einfach sein Frontend-Projekt mit TypeScript beginnen? Und ich denke, was die Leute verstehen sollten, ist sie sollten zuerst JavaScript lernen, weil TypeScript, wie er sagte, eine Obermenge von JavaScript ist. Es fügt also mehr Syntax zu JavaScript hinzu. Und es macht Sinn, zuerst die Grundlagen von JavaScript zu lernen und wenn man damit vertraut ist, kann man das Typisierungssystem von TypeScript lernen, und dann kann man im Grunde sein "toolbelt" erweitern und dann TypeScript Code schreiben und die Vorteile der Flexibilität von JavaScript, aber auch die Typisierung von TypeScript nutzen.

Lucas: Richtig. Erstens, zurück zu deinem ersten Punkt. TypeScript ist speziell so konzipiert, dass es nicht viel Aufwand erfordert, um es in einem bestehenden JavaScript-Projekt zu verwenden. Man kann also ein kleines Projekt beginnen mit JavaScript beginnen, kein Problem. Und dann kann man einfach, wenn man sich später dazu entschließt, einfach TypeScript einfügen. Sie müssen keine Typen anwenden, richtig? Es ist kein Paket, es muss andere Typen akzeptieren.

Dennis: Das ist eine interessante Idee. Man kann also mit JavaScript beginnen und das Projekt zu TypeScript weiterentwickeln.

Lucas: Ja, man kann es einfach einführen, wann immer man will, wie ich schon sagte, indem man einfach eine

JavaScript-Datei von Js in .ts umbenannt wird, ist sie bereits als TypeScript gültig. Es ist sehr einfach zu machen.

Dennis: Das ist sehr interessant. Ich denke, es ist auch interessant zu wissen, dass man in TypeScript jede JavaScript-Bibliothek verwenden kann, richtig? Man muss also nicht unterscheiden, ob dies eine Bibliothek ist, die in TypeScript geschrieben ist, oder eine Bibliothek, die in JavaScript geschrieben ist. Und ich kann einfach die Bibliothek in TypeScript und jede beliebige JavaScript-Bibliothek verwenden, was wirklich toll ist, denn JavaScriptist immer noch der Standard in der Frontend-Entwicklung und es gibt eine Menge Open-Source-Projekte dafür.

Lucas: Ja, richtig. Man kann jede JavaScript-Bibliothek genauso weiterverwenden. Es ändert sich nur, wenn man zu typisierten Bibliotheken wechselt. Bibliotheken, die eine natürlich veröffentlichte Typisierungsdatei haben, dann können Sie tatsächlich die spezifischen exportierten Mitglieder aus der Bibliothek importieren.

Dennis: Wenn man also eine JavaScript-Bibliothek hat, die keinen spezifischen typisierten Teil der Bibliothek für TypeScript hat, dann hat das zur Folge, dass bei der Verwendung von TypeScript und dem Import der JavaScript-Bibliothek, alle Typen in der JavaScript-Bibliothek beliebig sind. Wir kennen also einfach die Typen nicht und der TypeScript-Compiler kann keine Typüberprüfung durchführen. Aber man kann die Bibliotheken trotzdem benutzen, die Methoden und alles was da drin ist.

Lucas: Richtig. Und dieser Punkt ist einfaches JavaScript. TypeScript wird damit nichts anfangen können.

Dennis: Ja. Aber viele Bibliotheken haben heutzutage schon diese separate Bibliothek mit den Typen für das Hauptprojekt. Man kann also auch die Echtzeitinformationen haben, wenn man mit diesen Bibliotheken arbeitet. Und es ist auch ziemlich einfach, eine separate Bibliothek mit den Typinformationen neben einem bereits existierenden JavaScript-Projekt zu erzeugen. Es ist wirklich sehr flexibel gestaltet, wie es zusammenkommt.

Lucas: TypeScript ist heutzutage schon sehr weit verbreitet. Ich kann mich nicht erinnern, wann ich das letzte Mal eine Bibliothek verwendet habe, die nicht schon einige Typen hat. Aber selbst in diesem Fall ist es ziemlich trivial, die Typen selbst zu definieren, oder? Man kann einfach eine .dts-Datei mit allen Typen erstellen, wie sie eine Bibliothek verwendet.

Dennis: Ja, das war wirklich interessant mit dir, Lucas, ich glaube, wir sind wirklich schonn, ziemlich tief in die Bits von TypeScript eingetaucht. Und ich denke, wir konnten den Leuten einen Ausblick geben, warum wir konstant sind, TypeScript wirklich schätzen und es in unseren Frontend-Projekten verwenden. Und was eigentlich der Vorteil der Verwendung für uns als Organisation, aber auch als Entwickler ist. Okay, Lucas, wir sind schon fast am Ende unseres Podcasts angelangt. Vielleicht kannst du für unsere Hörer zusammenfassen, worüber wir heute gesprochen haben.

Lucas: Genau. Mein Fazit wäre, dass es sich auf jeden Fall lohnt, TypeScript zu lernen, wenn man JavaScript bereits kennt. Es bietet enorme Vorteile. Es macht die Entwicklung in vielerlei Hinsicht müheloser, vor allem beim Refactoring des Codes und vor allem auch bei sehr großen Basen, wo man einfach nicht den Überblick über andere Typen behalten kann. Wenn du noch kein JavaScript hast, musst duTypeScript verwalten, das im Grunde nur eine Erweiterung von JavaScript ist. Und der zusätzliche Aufwand den die Verwendung von TypeScript in einem Projekt mit sich bringt, ist es zumindest für mich persönlich immer wert.

Dennis: Das kommt mit der Erfahrung, sobald man mit dem Konzept von JavaScript und TypeScript vertraut ist. Das Schreiben von TypeScript geht dann ganz leicht von der Hand.

Lucas: Im Grunde nur JavaScript++.

Dennis: Ja. Vielen Dank, dass du Gast im Podcast warst.

Lucas: Danke, dass ich dabei sein durfte.

Dennis: Auf Wiedersehen.

Lucas: Auf Wiedersehen.

Das war's für heute. Wir hoffen, dass Ihnen diese Folge gefallen hat und dass Sie nun eine Vorstellung davon haben, wie Sie TypeScript in Ihren Entwicklungsprozess integrieren können. Weitere Links finden Sie in unseren Show Notes. Und wenn Sie sich für die wunderbare Welt der Softwareentwicklung interessieren, würden wir uns freuen, wenn Sie und abonnieren. Am zweiten Juni sind wir mit einem weiteren interessanten Thema zurück. Bis dahin alles Gute und bleiben Sie gesund.