TypeScript.

Hallo, lieber Kay, und herzlich willkommen an alle da draußen zu einer neuen Folge von unserem Webcafé.

Und Kay, du hast mir empfohlen, dass ich mich mal hinstellen soll für den Podcast. Das habe ich jetzt auch gemacht. Und du sagst, du wirst dadurch dynamischer und frischer. Und ich hoffe, dass er sich das jetzt bei mir auch so einstellt. Ja, hallo Felix, hallo Menschen da draußen, hallo stehender Felix. Ich bin ganz gespannt. Und wir werden jetzt in neue Sphären der Unterhaltung aufsteigen. Ja, kannst du denn im Stehen auch gut Tee trinken? Ich stehe ja immer tatsächlich bei der Podcast-Aufnahme, auch wenn ich es bis jetzt nicht so an die Glocke gehangen habe. Aber ja, ich kann auch Tee trinken. Ist das eine Überleitung?

Ja. Ich habe eigentlich damit gerechnet, dass du mich fragst, was ich trinke. Weil hätte ich dir gesagt, weiß ich auch nicht so genau. Was ich weiß, ist, dass ich hier ein Teeglas mit einem Sieb vor mir stehen habe. Und etwas, das aussieht wie einfach eine Handlaub. Okay. Und Freunde haben aus Albanien einen Tee mitgebracht. Einen alpinen Tee. Und ich habe das jetzt gerade mal übersetzt. Das ist anscheinend ein Tee, der besteht nur aus Rosen-Oregano. Okay. Und ich habe keine Ahnung, was das ist. Ich habe den im Regal gesehen. Das sind wirklich so dünne Ästchen mit so getrockneten Blüten dran. Und die stecken hier jetzt so drin, als würden sie darauf erwarten, angezündet zu werden.

Und ich kann dir weder sagen, was das ist, noch was das soll. Wie es schmeckt, kann ich dir sagen. Ich habe nicht nur schon ein paar Schlücke getrunken. Moment. Kann ich hier? Aber das ist ja ASMR, oder wie heißt das? Ja. Und es schmeckt wie, weiß ich jetzt nicht, Tee. So kräuterig, fruchtig? Ja, so Richtung Kamille, Pfefferminz. So ein bisschen, ganz, ganz, ganz klein. Ein bisschen so ein Minzaroma, hätte ich gesagt. Aber weiß nicht. Die Farbe ist schön. So ein Bernstein, wie mir das hier entgegen funkelt. Hört sich aber sehr gut an. Kann ich anders sagen. Aber was hast du, Felix? Ja, ich habe tatsächlich auch einen Tee aus dem Ausland dabei.

Und zwar habe ich in der allerersten Folge, wenn ich mich richtig erinnere, von Kops einen Tee dabei gehabt. Und zwar war das der Himmlergott. Einer meiner Lieblingstees aus Schweden. Und jetzt habe ich auch von Kops, also so heißt die Marke, einen Tee, der heißt Sörgarzte.

Spreche ich bestimmt ganz falsch aus. Aber so ähnlich wird es jedenfalls geschrieben. Und die schreiben selbst auf ihrer Website, natürlich auf Schwedisch. Ich versuche es jetzt mal rüber zu bringen. Schwedtee mit Smag, Afrabarber, Jörgup, Och Passionsfrucht. Schon fast zu verstehen, oder? Klingt so ein bisschen auch wie Niederländisch. Wenn man sich anstrengt, kommt man da schon hinter, was die wollen. Das stimmt. Und übersetzt ist das dann ein schwarzer Tee mit Geschmack von Rhabarber, Erdbeer und Passionsfrucht. Und so ähnlich schmeckt er auch. Also es ist ein schwarzer Tee, aber deutlich fruchtiger.

Passt jetzt zum sommerlichen Wetter. Wir haben es heute über 30 Grad hier in Köln. Und ja, deswegen heute mal dieses Gebräu. Ich finde das ja gut, dass wir die Teefahne oder Heißgetränkfahne oben halten, auch bei solchen sommerlichen Temperaturen. Ja, ich habe letztens schon überlegt, ob ich einfach mal eine Cola Zero mitbringen soll. Früher oder später wird das auch mal passieren. Aber für heute war der Tee das Richtige, weil ich auch ein bisschen wach werden muss noch. Jetzt kommen wir mal zu unserem Thema. Und zwar haben wir uns heute was richtig Schönes vorgenommen, nämlich TypeScript. und wollen so ein bisschen darauf eingehen, einerseits, was TypeScript überhaupt ist,

wie sich TypeScript von JavaScript unterscheidet, warum wir TypeScript bei uns mehr oder weniger ausschließlich einsetzen. Ja, und ich würde sagen, wir starten mal durch, indem du uns erzählst, Kay, was TypeScript überhaupt ist. Oh, tja, da kriegst du mich direkt mit einer Frage. Ich kann das jetzt so aus dem Kopf freestylen, weil so die Historie und den Werdegang und die eigentliche Definition habe ich ein bisschen anders angegangen. Aber TypeScript ist, jetzt kriege ich die Vokabeln hoffentlich richtig, ein Superset von JavaScript. Das bedeutet, JavaScript ist zu 100% TypeScript, aber TypeScript kann mehr als JavaScript.

Und wie der Name schon sagt, liegen diese Mehranteile, die TypeScript mitbringt, hauptsächlich beim Thema Typisierung. Wir wissen, JavaScript ist eine komplett untypisierte Programmiersprache, ursprünglich ja so eine Skript-Sprache gewesen. Und das bedeutet, der Inhalt einer Variable kann sich zu jeder Zeit ändern. Da kann ich mal einen String reinsprechen, mal eine Nummer oder sonst irgendwas. Und TypeScript versucht, oder was heißt versucht, ist sehr erfolgreich darin, die Konzepte von einer typisierten Sprache, wie man sie vielleicht aus den C-Sprachen oder Java kennt, auch auf JavaScript anzuwenden, um nachhaltigere Software zu bauen,

sage ich mal insgesamt. Das fand ich jetzt schon eine ganz gute Zusammenfassung. Ich habe dazu zwei Punkte. Das eine, das hast du erwähnt, dass JavaScript eben dynamisch typisiert ist, wie man so schön sagen kann. Also die Typen können sich auch dann zur Laufzeit verändern. Und TypeScript ist eben statisch typisiert. Und du sagst jetzt, dass TypeScript ein Superset von JavaScript ist. Und deswegen JavaScript, oder das ist vielleicht eine Frage, die ich daran anschließe, ist JavaScript immer auch gültiger TypeScript-Code? Ja. Und das ist gleichzeitig eine Fangfrage, Kay. Und du bist mir direkt ins offene Messer gelaufen.

Weil wenn du zum Beispiel in den Code schreibst, eins, also als Zahl, gleich, gleich, gleich, eins in Anführungszeichen, dann ist das gültiger JavaScript-Code, der, ich weiß gar nicht, gibt der True aus? Tja, das wäre jetzt die nächste Frage. Die geht an unsere Hörer und Hörerinnen raus. Ja, mit drei Gleichheitszeichen ist ja schon ein Typvergleich. Ja, klar, hast natürlich völlig recht. Ja, genau. Also würde der False ausgeben, genau. Und in TypeScript ist das aber ein Fehler, der da lautet, this comparison appears to be unintentional because the type, number and string have no overlap. Und es gibt wirklich einen Error und ja, ist halt fehlhaft.

Ja, ist jetzt die Frage, ob das schon Programmiersprache-Abhängigkeiten sind oder einfach das, was TypeScript soll, nämlich so Checks für dich zu machen. Ja, stimmt. Letztlich ist es ja in JavaScript auch nicht so irre sinnvoll, das zu schreiben. Richtig. Es prüft noch keiner. Ja, ja. Und da können wir eigentlich, ich weiß gar nicht, ob das der richtige Zeitpunkt ist, da schon einzusteigen, aber das ist ja genau der Grund, warum wir TypeScript unter anderem einsetzen, weil wir eben genau solche Dinger im Code direkt als Fehler bekommen, einen direkten Hinweis bekommen und nicht erst zur Laufzeit,

wenn es dann irgendwann mal kracht. Das ist ja eben genau einer dieser Sachen. Aber was ich damit sagen will, das ist auch nicht das einzige Beispiel, was es gibt. Es gibt noch mehrere. Man kann nicht einfach einen JavaScript-Code nehmen, den in die TypeScript-Datei reinpacken und da funktioniert es fehlerfrei, sondern da muss man schon mal hier und da auch was anpassen. Oh, das ist aber spannend, dass du das sagst. Da würde ich nachher noch mal Tagente schlagen, wenn es ums Thema Umziehen geht von JavaScript zu TypeScript. Können wir gerne darauf eingehen. Du hast jetzt eben die Historie angerissen, dass du da nicht so brandaktuell bist,

wie das sich entwickelt hat. Ich habe mir das im Vorhinein noch mal ein bisschen aufbereitet und grundsätzlich auch ganz gerne so verfolgt, wie sich JavaScript einerseits entwickelt hat, seitdem es sich entwickelt, muss man sagen, und dann andererseits auch TypeScript. Und weißt du, wie lange es JavaScript schon gibt und wo das herkommt? Ja, JavaScript, da steckt ja auch im Namen schon Java. Das war doch, da habe ich ein Referat drüber gehalten. Das war auf jeden Fall schon zu Netscape-Zeiten, glaube ich. Oh, geil. Sehr gut. Und ein JavaScript, das ist ja, also können wir ja abbiegen, JavaScript ist Trademarkt von Oracle wegen Java

und deswegen heißt es offiziell ECMAScript und solche Sachen. Ja, ja, also da sind, glaube ich, viele richtige Sachen drin. Also, wir können es mal so einordnen. 1997 wurde der erste ECMAScript-Standard veröffentlicht, also ES1 heißt das dann. JavaScript selbst wurde schon zwei Jahre vorher, glaube ich, veröffentlicht, hieß damals auch ein Livescript, wurde dann um Java, das dann ziemlich populär war, ein bisschen zu pushen oder um die Sprache selbst zu pushen, wurde es dann JavaScript umbenannt. Genau, und wurde dann als ES1 1997 veröffentlicht und kommt ursprünglich, wie du richtig gesagt hast, von Netscape.

Also, das hätte ich auch nicht gewusst, wenn ich mich nicht vorbereitet hätte. Und ab 1997 ist dann eigentlich im JavaScript auch nichts richtig passiert, eine ganz, ganz, ganz lange Zeit. Und ich weiß das selbst, als ich angefangen habe mit Programmieren, da war ich, wann muss das gewesen sein, sagen wir mal so 2003 oder 2004. Und da weiß ich, dass JavaScript noch ziemlich verrufen war. Also, mein Bruder hatte zum Beispiel auch ein Plugin darauf, dass JavaScript den Browser unterbindet. Ich weiß gar nicht, ob er es heute noch hat, muss ich mal nachfragen. Weil das eben so ein bisschen als evil galt und, ja,

dass man damit böse Sachen machen konnte. Und früher hat man dann ja so Space gemacht, wie rechte Maustaste verbieten oder irgendwelche ALAT-Popups und so weiter. Und, ja, deswegen eigentlich ziemlich verrufen. Und so richtig aus der Deckung ist JavaScript dann ja erst 2009 gekommen, wo dann ECMAScript 5, also ES5, veröffentlicht wurde. Und das war das erste Update, wo mal wieder richtig neue Features kamen. Da kamen dann so Sachen wie eine JSON-Unterstützung, Array-Methoden hier mit Map4Each-Filter, die wir heute ja eigentlich ständig verwenden. Und das so ein bisschen darauf zurückzuführen, dass es so lange gedauert hat,

dass Microsoft und Mozilla sich so ein bisschen gestritten haben, während Mozilla sehr viel an der Sprache ändern wollte. Also ab 1999 kam dann ES3 raus, hat aber keine wahnsinnigen Features gebracht. Und dann wollte Mozilla richtig die ganze Sprache umkrempeln und eben coole neue Sachen einbringen. Und Microsoft wollte das aber eher so inkrementell machen. Und dann konnten die sich nicht so richtig einigen. Und Ende vom Lied war, sie haben sich darauf geeinigt, eine Version 3.1 zu machen. Und eigentlich nur kleine Verbesserungen zu machen. Da ist dann letztlich tatsächlich diese ES5 draus geworden.

ES4 wurde nie veröffentlicht. Also ist geskippt worden. Und genau, dann hatten wir jedenfalls ES5. Und witzigerweise hat dann Microsoft für sich selbst erkannt, oh, irgendwie reicht uns das nicht, was JavaScript kann. Und dann hat Microsoft ja angefangen, TypeScript zu entwickeln. Und das muss so um 2010 rum gewesen sein. Veröffentlicht wurde es dann ja 2012. Und ab da hat JavaScript dann ja wirklich einen Raketenstart hingelegt. Dann kam nämlich 2015 eben Eggmark-Script 2015 raus, ES6. Diese Bezeichnung ist halt total verwirrend. Aber ich glaube, ich halte mich mal für diesen Podcast an diese ES-Nummern.

Und dann nehmen wir mal ES6. Also quasi die JavaScript-Version. Und da sind dann richtig viele Sachen gekommen, die in TypeScript vorher auch schon drin waren. Also diese Sachen wie Let und Const, Error-Funktionen, Klassen, Promises, Maps, Sets und so weiter und so fort.

Also seit ES6 ist JavaScript ja wirklich, sag ich mal, eine Programmiersprache. Ja, und dann ist es wirklich so inkrementell gekommen, dass eigentlich TypeScript immer vorgelegt hat. Und JavaScript so ein, zwei Jahre später die Sachen adaptiert hat, die TypeScript auch gemacht hat. Und inzwischen gibt es ja seit 2017 dann Sync-Await im JavaScript oder so Helfer-Funktionen wie Object.Entries, Object.Values. 2018 sind dann Spread-Operatoren dazu gekommen. Also ich zähle jetzt nicht alles auf. Und dann geht das so weiter. Und 2022 ist dann zuletzt die ES13-Version rausgekommen. Und die hat beispielsweise die Add-Funktion für Arrays und Strings eingeführt.

Vorher musstest du ja zum Beispiel, wenn du das letzte Element von einem Array auslesen wolltest, da musstest du ja immer so ein Array, da hast du diese eckigen Klammer gemacht, Array.length-1 und hast auf das letzte Element zugegriffen. Und jetzt kannst du halt Array, also einen Array.add und dann minus 1 und dann bist du direkt da und hast du es ein bisschen praktischer. Aber natürlich ist da jetzt schon viel passiert und ja, ausentwickelt ist es vielleicht nicht. Aber die Funktionen sind natürlich nicht mehr so praktisch, wie das dann mit ES6 2015 eingeführt wurde, wo wirklich, also das war wirklich so die Geburtsstunde

des modernen JavaScript, würde ich sagen. Oh, da war jetzt viel Stoff dabei, Ferdig. Das war mir gar nicht auch alles so präsent. Dann nochmal danke für die Zusammenfassung. Ja, was ich ganz spannend finde, ist wirklich auch, was JavaScript inzwischen von TypeScript adaptiert hat, dass TypeScript wirklich die Sachen vorlegt. Also ein klasse Beispiel sind optionale Parameter. Die sind dann seit 2015 in ES6 eingeführt worden und TypeScript hatte die halt, soweit ich weiß, jetzt auch in Version 1.0, also 2012 dann schon drin. Und dann kannst du halt in JavaScript, in dem Funktionskopf letztlich, dann mit gleich und irgendeinem Wert halt

einen optionalen Parameter angeben. Und vorher musstest du ja immer, das habe ich früher immer gemacht mit diesem, also du hast den Parameter ganz normal in der Funktion angegeben und hast dann im Code was gemacht wie if type of gleich undefined und dann hast du das Ding gesetzt und hast quasi so einen Default-Wert dafür gesetzt. Das war halt immer ziemlich sperrig und fühlte sich nicht richtig an. Das sind natürlich tolle Funktionen, die TypeScript dann eigentlich vorgelegt hat. Async await, habe ich eben schon gesagt, auch so eine Geschichte, Klassen und so weiter und so fort. Junge, Junge, Felix.

Da hast du aber richtig Überstunden gemacht. Ja, wenn man irgendwas spannend findet, dann macht das ja auch Spaß, sich damit zu beschäftigen. Genau. Kay, mach du doch mal einen Punkt, was die Unterschiede zwischen JavaScript und TypeScript heute so sind oder vielleicht nimmst du dir einen Punkt raus, der dir besonders wichtig erscheint. Oh, sehr gerne. Da komme ich jetzt zum Kerngegenstand meines Referats, der ehrlicherweise weniger ein Punkt für TypeScript ist, sondern eher ein Punkt für typisierte Programmiersprachen generell. Also das gilt auch für Java oder PHP inzwischen ja auch. Die machen ja auch immer mehr mit Typisierung,

wo es vorher nicht notwendig war. Vielleicht nochmal einen Schritt zurück. Wir haben das gerade nochmal angesprochen, aber das ist wichtig für die Unterscheidung. Wenn man sich eine ganz einfache Variable vorstellt in JavaScript, dann ist die Variable von dem Typ dessen, was ich da reintue. Soll heißen, wenn ich da einen String rein tue initial, dann ist die Variable vom Typ String. Wenn ich da eine Nummer rein tue, dann ist sie vom Typ Nummer und im Laufe des Codes kann sich das auch relativ frei wieder ändern. Das bedeutet, JavaScript ist eine Programmiersprache, die ausschließlich über Implementierung funktioniert.

Und was TypeScript jetzt macht, ist, es bringt noch eine zusätzliche Ebene in den Code, nämlich eine Abstraktionsebene. Das bedeutet, eine Variable ist nicht das, was es ist, sondern das, was sie sein soll. Und das kann ich vorher definieren. Da sage ich zum Beispiel, die Variable x ist vom Typ Number und dann ist völlig egal, was ich in der Implementierung, also rechts vom Gleichheitszeichen, da tatsächlich reintue. Die Variable ist vom Typ Number und man kann es nie wieder ändern. Das ist ganz vereinfacht gesagt, dieses Konzept von Abstraktion versus Implementierung. Bei nur JavaScript ist es quasi dynamisch,

das hast du vorhin gesagt. Und bei TypeScript sage ich vorher, was es ist und dann kann es nie wieder was anderes sein. Wenn ich versuche, da was anderes reinzutun, gibt es einen Fehler. Das heißt, mit TypeScript haben wir diese schöne Trennung und das ist im Code, wenn man darauf achtet, auch wirklich schön hervorgehoben durch dieses einfache Gleichheitszeichen, dass wir auf der linken Seite vom Gleichheitszeichen die Abstraktion haben und das ist üblicherweise so eine Signatur bestehend aus dem Namen von irgendwas und dessen Typ und auf der rechten Seite von dem Gleichheitszeichen ist die Implementierung

und dann hat man links x gleich Number und rechts muss man sich dann in der Implementierung darum kümmern, dieser Abstraktion gerecht zu werden. Das ist jetzt für so einfache Variablen vielleicht erstmal trivial, dass man sich denkt, okay, was ist denn da jetzt der Sinn dahinter? Richtig spannend wird es erst, wenn man das größer und weiterdenkt, weil nur mit JavaScript, wenn man da versucht zu beschreiben, wie die Anwendung funktioniert und welche Sachen da zusammenspielen, dann muss man in den Code rein und sich die einzelnen Stellen anschauen und gucken, okay, hier werden Objekte gebaut, die sehen so und so aus,

dann kommen die hier rein und dann wird das und das mit denen gemacht oder sowas. Und mit TypeScript haben wir die Möglichkeit, wie gesagt, wieder durch diese Abstraktion, eine Ebene oben drüber zu setzen und dann sind wir schon fast auf der Höhe von so einem ER-Diagramm, wo wir nur mit TypeScript und Interfaces beschreiben, welche Models haben wir, wie stehen die in Relation zueinander, wie arbeiten die miteinander und so kann man auf einmal aus diesem puren Code, den man hat, eine Ebene rausziehen, wo man wie bei einer Datenbank und dessen ER-Diagramm ganz abstrakt schauen kann, wie die Zusammenhänge

innerhalb des Codes sind. Du willst jetzt ganz konkret dann eben darauf hinaus, dass man zum Beispiel Interfaces definieren kann für ein Objekt da, ne? Genau, da sind wir wieder bei unserem Thema, glaube ich, zweite Podcast-Folge Entities, dass es meiner Einschätzung nach der höchste Wert einer Anwendung ist, wenn man Entities aus der realen Welt im Code implementieren kann. Also das heißt, wenn wir versuchen, einen Shop abzubilden, dann denken wir uns nicht Dinge aus, sondern schauen in der realen Welt, okay, es gibt Produkte und die haben diese und jene Eigenschaften und die stehen im Zusammenhang

mit anderen Dingen und die versuche ich im Code abzubilden und da hilft uns TypeScript mit eben Interfaces, wo ich definieren kann, letzten Endes, wo ich Objekte definieren kann mit diesen und jenen Eigenschaften und diesen und jenen Typen, die sie haben. Und eben auch durch die Benennung von anderen Types, wie die im Zusammenhang miteinander stehen. Wenn man sich so Beispiele im Internet anguckt von TypeScript, dann findet man ja oft Beispiele mit diesen primitiven Datentypen, also zum Beispiel Number oder String dann, wie du es gesagt hast, oder vielleicht noch ein Array. Und da wird meist noch nicht ganz

so deutlich dran, was einem die Typisierung überhaupt bringt, weil dass ich jetzt ein Number und String mal ein bisschen durcheinander bringe, das kann schon mal zu Fehlern führen, aber richtig interessant wird es ja wirklich, wenn ich zum Beispiel aus einer API eine bestimmte Datenstruktur bekomme und das gegen TypeScript laufen lassen kann und dann mir sicher bin, welche Typen von Daten da auch drin sind. Da ist ja das, wo dann die Vorteile wirklich ins Spiel kommen. Oh, da muss ich dir jetzt ein bisschen korrigieren, weil TypeScript ist ja eine Build-Time-Sprache und niemand, also insbesondere der Browser,

kann mit TypeScript nichts anfangen. Deswegen gibt es dann zwischen einen Compile-Step, der TypeScript in JavaScript umwandelt und da ist dann die komplette Typsicherheit rausradiert und während so ein API-Call ja zu Runtime passiert, kann es eben durchaus passieren, dass man sich in TypeScript so versucht abzubilden, was wohl aus der API rauskommt, aber in der Realität wurde dann heimlich die API geändert, in TypeScript ist das nicht reflektiert und dann läuft das gegeneinander. Das ist völlig richtig, was du sagst und gehe ich auch mit. Ich meine das ein bisschen anders, dass ich im Code eben ja

ein Objekt erwarte aus einer API raus und das Objekt schon typisiert habe. Ich will jetzt nicht zu sehr darauf eingehen, aber dass ich im Code zumindest mal mit dem, was ich erwarte, gut arbeiten kann, dass das dann tatsächlich ankommt, das muss natürlich die API sicherstellen, das ist natürlich klar. Und die Idee durch diesen abstrakten Interface ist es dann eben, wie gesagt, dass ich das im Code sicherstellen kann und wenn man sich dann mal so ein Facebook vorstellt, dann gibt es ein Interface, das heißt User und da steht dann Nutzername und E-Mail drin und dann gibt es ein Interface Posts und in der realen Welt

ist ja der Zusammenhang zwischen User und Post, dass ein User einen Post erstellen kann und ein Post hat einen Autoren, der wiederum ein User ist. Und auf TypeScript kann ich das dann eben so darstellen, dass ich sage, ich habe dieses Post-Interface, das beschreibt ein Objekt, dieses Objekt hat eine Eigenschaft Autor meinetwegen, das ist wiederum ein Objekt und da steht dann Nutzername und Pass, Passwort wahrscheinlich nicht, Nutzername und E-Mail oder sowas vielleicht drin, und die Idee ist eben jetzt nicht, dass ich an der Stelle zufällig dasselbe Objekt nochmal nachbaue, wie ich das User-Objekt habe,

sondern dass ich da das User-Interface tatsächlich wiederverwende, sodass in dem Post-Interface eine Referenz auf das User-Interface ist, weil so kann ich dann nämlich ganz elegant mit GoToDefinition und solchen Browser-Navigation oder Editor-Navigationselementen durch meine Anwendung springen und die Zusammenhänge herstellen und was zum Beispiel auch geht, ich weiß nicht, ob du das wusstest, Felix, wenn man das sauber macht, dann kann man in richtig krassen Editoren, wie zum Beispiel PHPStorm, hergehen und sich aus der Codebase nur anhand der Interfaces sowas wie ein ER-Diagramm rausgenerieren lassen.

Also da wird dann wirklich der ganze Code durchscannt nach Interfaces, wie die zusammenhängen und daraus dann versucht, so ein Diagramm zu erstellen, eben um, wie bei einem ER-Diagramm bei Datenbanken, die Zusammenhänge der Anwendung auf TypeScript-Ebene zu sehen, was nur durch JavaScript im Code nicht sichtbar wäre. Okay, ich halte ja meist nicht so viel von diesen automatisch generierten Sachen, auch wie Dokumentationen, aber würde ich mir mal angucken. Also es ist halt ganz hilfreich, um zu verstehen, dass man so wirklich die abstraktesten Zusammenhänge in der Anwendung deutlich machen kann.

Und ich bin dann auch ein großer Fan davon, wenn man sagt zum Beispiel so eine User-ID ist ja üblicherweise vom Typ String oder sowas, dass ich dann dafür tatsächlich auch einen Alias mache. Also der heißt dann vielleicht User-ID und ist vom Typ String, also eigentlich ein ganz normaler Primitive. Aber wenn ich jetzt konsequent durch die ganze Anwendung hindurch diesen Alias verwende, wenn ich irgendwas mit der User-ID mache, obwohl es ein Primitive ist, kann ich dann super gut im Code schauen, wo wird denn überhaupt alles mit diesem User interagiert. Wenn ich bei der User-ID String reinschreibe

und dann irgendwo bei einer Funktion, weiß ich nicht, getAvatar for User-ID oder sowas, auch ein String als Types, dann ist der Zusammenhang zwischen denen nicht klar, weil es beides so generische Primitives sind. Aber wenn ich an beiden Stellen diesen Type-Alias habe, dann kann ich super gut im Code dazwischen hin und her springen und sehen, wo im Code das alles verwendet wird. Ich hoffe, dass es, klar, ich gestikuliere hier so wild. Auf jeden Fall. Das dreht sich ja alles so ein bisschen darum, dass der Code auch verständlicher wird und das ist eben auch einer der Riesenvorteile von TypeScript

und zwar auf zwei Ebenen. Einerseits, oder vielleicht sogar auf drei Ebenen. Einerseits wird er für den Programmierer selbstverständlicher, also man kann natürlich seinen eigenen Code besser lesen und besser verstehen, was man gemacht hat. Es können aber andere Programmierer auch viel schneller in den Code reinkommen, also beispielsweise, wenn ich bei einer Funktion ein Objekt übergebe und da habe ich ein Interface dazu, dann habe ich schon ungefähr einen Eindruck davon, was könnte da hinterher drinstehen und nicht zuletzt ist es aber auch eine geniale Hilfe für den Editor zu verstehen, für die IDE

zu verstehen, was will denn der Programmierer überhaupt von mir und die IDE kann ja wirklich dann auch logische Sachen schließen und einem sehr, sehr hilfreiche Tipps geben, die bei JavaScript vielleicht erst zur Laufzeit zu einem Error führen würden, die dann hier im Editor schon abgefangen werden. Genau, diese Code Completion und Compiling Errors bei TypeScript, das ist natürlich so der naheliegendste Vorteil, wenn man dran denkt, aber ich finde eben diese Abstraktion ist noch eine Stufe höher und ein weiterer Vorteil ist auch, dass mit TypeScript Fehler an der Stelle sichtbar werden, wo sie entstehen

und nicht da, wo sie irgendwo als Folge entstehen. Wenn man zum Beispiel eine Variable hat und da irgendwo einen String reinspeichert und dann hat man irgendwo im Code weiter unten so eine String-Funktion wie toUpperCase und dann funktioniert das super gut und wenn ich aber oben dann in der Variable statt einen String eine Nummer reinpacke, dann ist unten im Code irgendwo ganz versteckt an einer ganz anderen Stelle, wirft es dann auf einmal einen Fehler, weil der versucht toUpperCase auf eine Nummer anzuwenden. Und wenn ich aber oben schon hingehe bei der Variablen-Definition und sage, das ist hier ein String

und dann versuche, da eine Nummer reinzuschreiben, dann fliegt es mir direkt an der Stelle um die Ohren, wo der Fehler entsteht. Und weiter unten mit diesem toUpperCase ist dann weiter alles grün, weil TypeScript weiß, da soll ein String kommen und dann geht auch immer davon aus, dass da ein String ist. Das sind jetzt ja alles Vorteile und vor allem eben Richtung Typisierung. Ich finde, was TypeScript oder was man bei TypeScript eben oft vergisst, ist das, was ich eben schon ein bisschen angesprochen habe, dass TypeScript eigentlich auch coole, ich sage mal in Einführungsstrichen, JavaScript-Funktionen hat,

die es in JavaScript selbst noch nicht gibt. Das heißt, TypeScript ist eigentlich ein bisschen weiter vorne, dass man einen moderneren Code schreiben kann. Das finde ich auch einen oft vergessenen Vorteil von TypeScript und gleichzeitig, um dann so ein bisschen zu den Nachteilen zu kommen, könnte man das auch als Nachteil interpretieren, nämlich in dem Sinne, dass TypeScript ja erst kompiliert werden muss, damit daraus ein gültiges JavaScript entsteht, was dann der Browser interpretieren kann und das führt natürlich dazu, dass man einen Zwischenschritt machen muss. Jetzt kennen wir das historisch ja aus der Web-Entwicklung

eigentlich schon seit Ewigkeiten, dass wir auch JavaScript immer kompiliert haben, dass dann da irgendwie ein Webpack oder sowas dazwischen war weil wir dann natürlich cooles ES6 schreiben wollten, aber die Browser wie ein Internet Explorer konnten dann halt nur ältere JavaScript-Versionen und da musste man sich das kompilieren lassen und bei TypeScript ist es eben heute so. Andere Browser, die heute aktuell sind, also sagen wir jetzt Firefox, Chrome und Edge, wobei selbst der Opera Mobile inzwischen schon die neuesten JavaScript-Versionen unterstützt. Worauf ich hinaus will, ist, die unterstützen alle

heute ECMAScript 2022, also ES13 sind wirklich top aktuell. Das heißt, ich könnte, wenn ich jetzt rein in JavaScript entwickle und nicht einen Internet Explorer von der halt nicht mehr maintained wird von Microsoft, den wir jedenfalls auch bei unseren Projekten nicht mehr unterstützen, wenn ich das nicht machen wollte, dann kann ich wirklich brandaktuelles JavaScript in der neuesten Version schreiben, muss mir das nicht kompilieren lassen. Jetzt kann man sich natürlich da auch die Frage stellen, wie sinnvoll ist das, weil wir das ja vielleicht auch minifreien wollen und so weiter. Aber an sich

habe ich jetzt mit TypeScript da einen Zwischenschritt, was ein Nachteil sein könnte, TypeScript zu schreiben. Jetzt bist du schon einfach zu den Nachteilen gesprintet, das glaube ich ja gar nicht. Hast du noch mehr Vorteile? Ja, klar. Wir haben eine Liste ja erst halb durch hier. Oh, dann schieß los, schieß los. Junge, Junge. Behalte den Gedanken, der hat nämlich, das stimmt nämlich grundsätzlich, vielleicht, wenn wir das kurz abschließen wollen. Compile Step kommt dazu. Du hast auch recht, dass das durch Webpack oder sowas schon passiert. Man muss dazu sagen, das gilt hauptsächlich für den Browser,

weil wenn man so im direkten Serverumfeld unterwegs ist, bei Node muss man das auch noch machen, aber so andere Runtime-Engines wie Bun oder Deno, die können inzwischen tatsächlich natives TypeScript, da fällt also dieser Compile Step weg. Was ich hier meine, bringen wir mal wieder zurückscrollen, wo du jetzt schon... Ja, das tut mir leid, ich bin so dynamisch heute, weil ich im Stehen bin. Dann galoppiere ich hier so durch mein Skript. Aber wenn du mehr Vorteile von TypeScript hast, gerne. Wir wollen ja Leute auch gerne davon überzeugen, TypeScript zu verwenden, weil wir ja wirklich davon überzeugt sind

und das auch in der täglichen Arbeit merken, dass es wirklich eigentlich nur Vorteile bringt. Sehr gerne. Also was ich noch immer wieder als großen Vorteil feststelle, ist, wenn man mit externen Bibliotheken arbeitet, die man sich über MPM reinholt und wenn die schon eine TypeScript-Definition on board haben, was entweder die meisten Pakete modernerweise schon haben oder es sonst diese wunderbaren AddTypes-Repositories gibt, wo man sich nur die Typ-Definition für andere Pakete unterladen kann, dann kann man auch supergut entwickeln. Nämlich man kann dann einfach durch Autocomplete sich anschauen,

was bietet denn dieses Package so an Funktionen und Objekte und Klassen und weiß ich nicht was an, wo ich ohne diese Type-Definition vielleicht umständlich erst die Dokumentation konsultieren müsste, wenn sie vollständig ist oder direkt im Quellcode irgendwie rumtouren, um mir da zusammenzureimen, wie man das wohl verwendet. Mit TypeScript wird mir das einfach vom Editor vorgeschlagen. Das erweitert so ein bisschen das, was ich eben gesagt habe, mit dass fremde Programmierer deinen Code auch besser verstehen und das bezieht sich natürlich auch auf Code, den wir anderen zur Verfügung stellen oder andere dann eben auch uns.

Ganz genau. Und da spielt eben auch rein Thema Code-Reviews, dass so Type-Hints auch total nützlich sind, wenn man den Code anderer Leute liest, entweder im Editor direkt oder auch in zum Beispiel der GitLab-Seite, wo nicht noch vielleicht so fancy Hints von der IDE eingeblendet werden. Und wenn ich dann so eine Funktion nur hart in irgendeinem Text sehe und da aber schon Number dabei steht, muss ich gar nicht wissen, was die fancy Funktion dahinter unbedingt anstellt, weil ich direkt im Type sehe, was am Ende dabei rauspurzelt. Und so kann ich mich mit der Funktion dann nur beschäftigen, wenn mich wirklich interessiert,

was sie macht. Und wenn es mich nur interessiert, wie damit weitergearbeitet wird, kann ich mich am Typ orientieren. Und was auch noch ein großer Vorteil ist, das übersieht man schnell, aber durch TypeScript spart man sich eine Menge von Checks, die man irgendwo hart im Code hinterlegen müsste. Du hast das vorhin eingangs gesagt, wie man das am Anfang bei JavaScript gemacht hat. Da musste man bei jedem Parameter, den man in der Funktion bekommt, noch in JavaScript testen, if type of a gleich Number, dann wirfst ein Error oder sowas. Und das sind sehr, sehr viele Checks, die uns jetzt TypeScript abnimmt,

dadurch, dass es durch dieses Kompilieren, durch diesen Build-Step solche Fehler direkt für uns abfängt. Wir müssen uns dann nur noch darum kümmern, dass solche Runtime-Probleme wie zum Beispiel API-Calls abgerufen werden. Ja, was da jetzt interessant dran ist, ohne wieder springen zu wollen, da sind eigentlich zwei Sachen drin. Wenn ich nämlich google, was die Vor- und Nachteile von TypeScript und JavaScript sind, dann sind da unter anderem zwei Punkte immer aufgeführt. Und das eine ist, dass TypeScript mehr Code ist, also dass man immer Code schreiben muss. Jetzt sagst du ja, wenn wir zum Beispiel

diese Type-Checks nicht mehr machen müssen, dann haben wir ja an der Stelle zumindest mal einen kürzeren Code. Natürlich muss man die Types dann auch schreiben und vielleicht ein Interface schreiben, aber insgesamt vielleicht gleicht sowas das dann auch aus und man schreibt mehr sinnvolleren Code, würde ich sagen. Und das andere ist, dass ja viele immer sagen, dass TypeScript komplizierter zu verstehen ist, einfach, weil mehr Code da ist und man muss sich ein bisschen mit dem Syntax dann auch vertraut machen oder mit der Syntax vertraut machen. Aber ich finde, das Verständnis ist eigentlich ja besser,

wenn die Types dabei stehen. Das heißt, den Punkt kann ich auch so nicht unbedingt stehen lassen, dass TypeScript komplizierter ist, sondern es ist vielleicht sogar einfacher. Also nur, weil man Types dabei schreibt, heißt das ja nicht unbedingt, dass es wirklich auch einen Mehrwert hat. Und häufig genug bei neuen Entwicklern, insbesondere die mit TypeScript neu anfangen, die gehen häufig danach und schreiben die Types nach dem, was da schon drin steht oder was sie da, was für eine Funktion sie verwenden oder sonst irgendwas. Das ist jetzt ein bisschen abstraktes, ein bisschen abstraktes Konzept,

aber wenn man halt nur auf Teufel komm raus irgendeinen Type da reinschreibt, um dem Computer oder dem JavaScript Code gerecht zu werden und Fehler zu vermeiden, dann wird es tatsächlich schon kompliziert. Und der Trick und was ich dann auch allen entwickelnden Menschen immer Rate ist, versuch dich wirklich bei TypeScript darauf zu konzentrieren, das als separaten Schritt zu sehen, den du vor der eigentlichen Entwicklung machst. Nämlich, idealerweise, wenn das funktioniert, wenn du die Aufgabe anfängst, überleg dir erstmal, was für Types du für diese Aufgabe brauchst, was für Interfaces vielleicht,

mit welchen Entities, die es schon gibt, du arbeitest, welche Funktionen du brauchst und wie die sinnvollerweise aussehen können. Also, Bescheidere Signatur, Name, Parameter und Rückgabewert. Und erst wenn du dir das überlegt hast, dann gehst du hin und schreibst deinen Code. Statt andersherum den Code zu schreiben, so wie du es gerne hättest und dann die Types so zu bauen, dass sie zu deinem Code passen. Und das ist tatsächlich inzwischen ein eigener Schritt, den wir in so einer Aufgabe haben, dass die Kolleginnen und Kollegen, wenn sie eine neue Aufgabe bekommen, sich erstmal auf abstrakter Ebene,

nämlich auf Type-Ebene, Gedanken machen müssen, wie sie die Aufgabe umsetzen, um dann das zu besprechen und dann erst mit der Implementierung loszulegen. Weil es hat sich herausgestellt, in den Code-Reviews, die gravierendsten Anmerkungen und die auch die kompliziertesten Umbaumaßnahmen dann wieder erfordern, die ließen sich alle darauf zurückführen, dass am Anfang schon diese Type-Zusammenhänge nicht sinnvoll waren. Und da irgendwelche Entities gebaut wurden, die so nicht funktioniert haben oder eine Signatur für eine Funktion gebaut wurde, die vielleicht nicht super ist oder sowas. Und durch diesen extra Schritt

konnten wir das bisher ganz okay minimieren. Jetzt musst du mir noch eine Sache sagen, die mir jetzt in den Kopf gekommen ist, während du das erzählt hast. Und zwar haben wir ja zumindest mal eine Zeit lang, oder vielleicht machen wir es auch heute noch so, Types zum Teil weggelassen. Also primitive Types. Machen wir das immer noch? Es ist ja so, in TypeScript muss ich ja nicht einen Type angeben. Ich kann einen Type angeben. Da gehen wir jetzt schon richtig tief rein in die Art und Weise, wie wir tatsächlich Type-Definitionen machen. Und wir gehen inzwischen tatsächlich immer hin und sagen, jede Variable

muss einen Typ haben. Ah, okay. Und zwar auch entgegen den Default-Einstellungen von TypeScript. Da ist nämlich dieses Implicit-Type-Vererben aktiviert. Und der beschwert sich, wenn du einen Primitive nochmal extra typisierst. Aber wir sagen eben genau, deswegen habe ich das am Eingang gesagt, dieses Schöne mit diesem Gleichheitszeichen, dass die Trennung zwischen Abstraktion und Implementierung ist. Und ich möchte immer auf der linken Seite des Gleichheitszeichens die komplette Abstraktion dessen haben, was ich haben möchte. Und das heißt üblicherweise Name von irgendwas plus seinen Typ. Und auf der rechten Seite

die Implementierung. Und das ist dann bei so Primitives möglicherweise ergibt sich das automatisch, aber dann wieder vorhin das Beispiel mit dem ToUpperCase mit so einem Primitive, den kann ich auch ändern und dann fällt mir das erst irgendwo unten auf. Was wir tatsächlich auch deswegen machen, ist, wir sagen, dass alle Funktionen, die wir schreiben, sind Arrow Functions, die wir in einem Variablen-Namen speichern, statt Named Function mit diesem klassischen Function bla bla bla und dann in den Klammern. Eben weil man durch diese Syntax auf der linken Seite von dem Gleichheitszeichen die komplette Funktion

typisieren kann, sprich wieder den Namen der Funktion in Form von einer Variable plus seine Parameter plus den Rückgabewert. Das ist komplett alles links vom Gleichheitszeichen. Und auf der rechten Seite vom Gleichheitszeichen habe ich dann die tatsächliche Arrow Function, die sich dieser Abstraktion untertan machen muss. Wobei das ja nicht mal unbedingt TypeScript spezifisch dann ist, sondern das könnte man ja ein Stück weit zumindest auf JavaScript übertragen. Genau, aber das ist eben der Grund, warum wir Arrow Functions überall vorschreiben, auch per Linting-Rule, statt Named Functions zu machen,

was genauso ginge. Ja. Hast du noch weitere Vorteile von TypeScript, die du hier im Podcast nennen möchtest? Mit den Vorteilen bin ich jetzt, glaube ich, tatsächlich durch. Ich gehe nochmal schnell meine Liste lang, aber ja, also ja auch schon ein langer Monolog. Ja, ja. Ich überlege die ganze Zeit, was die Nachteile sind. Ja, die Nachteile sind eben, dass man sich wirklich vorher Gedanken über die Abstraktion machen muss, statt einfach irgendwas reinzuschreiben und dass es tatsächlich schon deutlich komplizierterer Code ist, wenn man es nicht gewohnt ist. Aber das ist halt mit jeder Sprache so.

Ja, aber dann frage ich mich, muss man sich nicht sowieso Gedanken über seinen Code machen? Ja. Und das geht so in diese Richtung von einfacher zu verstehen. Aber ich denke, mit einem JavaScript, was nicht typisiert ist und was viele Sachen einfacher macht und wo man eigentlich auch mehr Fehler machen kann, das versaut ja letztlich gerade auch so Anfänger im Programmieren, dass die eben genau über solche Sachen sich keine Gedanken machen müssen. Eigentlich müsste das ja ein Vorteil von TypeScript sein, dass es dazu anricht, sich vorher Gedanken zu machen oder auch beim Schreiben des Codes Gedanken zu machen.

Womit arbeite ich hier eigentlich? Das finde ich nämlich auch, genau. Also es gibt tatsächlich ein paar Bibliotheken, die jetzt bewusst wieder diesen Schritt weg von TypeScript gehen. Ich glaube, Svelte war zumindest da mal so ein prominentes Beispiel, die für ihre interne Codebase TypeScript nicht mehr verwendet haben. Aber was sie dann stattdessen gemacht haben, und hier nochmal als kleiner Tipp, die haben dafür JS-Doc verwendet. Das heißt, Kommentare bei den Variablen und Funktionen und so weiter bei, die auch diese Typisierung in dem Code niederlegen. Also die haben sich nicht von der Typisierung verabschiedet,

sondern nur von TypeScript als konkreter Variation davon. Was man ja sogar ein Stück weit nachvollziehen kann. Und gerade, wie ich das erzählt habe, mit den neueren JavaScript-Versionen, dass eben diese Vorteile, dass man in TypeScript auch moderneren Code schreiben konnte, die hat, oder der Vorteil hat sich ja so ein bisschen erledigt dadurch, dass JavaScript ja mit vielen Sachen auch nachgezogen ist. Und dann kann man so einen Ansatz schon auch verstehen. Wollen wir jetzt noch kurz darauf eingehen, wie man denn so eine Codebase, so eine bestehende Codebase umziehen kann, wenn man jetzt total Feuer und Flamme

durch unser Referat hier ist. Ja, das habe ich tatsächlich, glaube ich, noch nie gemacht. Also ich habe entweder immer direkt mit TypeScript angefangen oder die Sachen bei JavaScript gelassen, die Legacy-Sachen. Ich habe es noch nie umgezogen. Hast du das in der Praxis schon mal gemacht? Ich habe es schon ein paar Mal gemacht, genau. Und der größte Vorteil daran ist tatsächlich, was wir eingangs auch erwähnt haben, dass JavaScript-Code immer gültiger TypeScript-Code ist. Außer im JavaScript-Code sind eh schon Fehler, aber dann sind sie da so oder so, egal ob es JavaScript oder TypeScript dran steht,

so wie dieser Vergleich, den du eingangs erwähnt hast. Und deswegen ist es eigentlich erstmal total einfach, das umzuziehen, nämlich man installiert sich TypeScript als Compiler, benennt jede Datei in .ts um und dann hat man 100% validen TypeScript-Code. Und dann kann man tatsächlich Schritt für Schritt und Use Case für Use Case hergehen und da Typen nachziehen, wo es gerade sinnvoll ist. Und am sinnvollsten, das habe ich auch schon gesagt, sind es meiner Meinung nach diese großen Zusammenhänge innerhalb der Anwendung darzustellen. Also Interfaces für die Entities, die ich habe und da den Zusammenhang

herstellen. Dann kann ich direkt im Code, wenn ich die irgendwo erwähne, sehen, hier ist jetzt ein Objekt, das sieht nicht zufällig aus wie das User-Objekt an der anderen Stelle, sondern TypeScript sagt mir, das ist wirklich dasselbe zu 100%. Das, was ich in einem unserer größeren Projekte mitgekriegt habe, das ihr ja auch auf TypeScript umgestellt habt, ist, dass man ja nicht unbedingt hingeht und sagt, ich nehme jetzt ein JavaScript-Projekt und migriere das auf TypeScript und muss dann jede Variable typisieren und jedes Objekt mit einem Interface versehen und so weiter, sondern man kann ja eigentlich auch hingehen

erstmal ein TypeScript-Projekt draus machen ich glaube, man kann sogar TypeScript und JavaScript-Dateien auch mischen und dann die neuen Funktionen auf TypeScript bauen, das heißt, in den neuen Funktionen von den neuen Features profitieren, dann vielleicht auch mal ein altes Objekt mit einem Interface ausstatten oder ein neues Interface hinzuzufügen und dass man so sukzessive das Ganze auf TypeScript umstellt und immer, wenn man irgendwo dran ist, dann ein Refactoring macht von der Datei, das ist natürlich ein Weg, der, ja, ich sag mal, auch wirtschaftlich deutlich gangbarer ist, als wenn man jetzt

sich wochenlang Zeit nimmt, ein Riesenprojekt zu migrieren. Genau, das stimmt. Und wenn man dann so große Bausteine hat, die man wiederverwendet, das sind ja zum Beispiel irgendwelche React-Komponenten, so Buttons oder sowas, die man mal selber gebaut hat und die aber keine Type-Definition haben, dann kann man tatsächlich auch hingehen und für JavaScript-Dateien in separaten Dateien Type-Definitionen machen. Also da hast du dann eine Button.jsx-React-Komponente und dann machst du eine Button.d.ts-Datei daneben und schreibst da rein, wie denn die andere Datei aussieht und TypeScript kann dann automatisch erkennen,

ah, guck mal, hier gibt es eine Typ-Definition für diese andere Datei, die selber keine Typ-Definition mitbringt und dann hat es genau dasselbe Feature-Set, wenn ich diese Komponente verwende, wie wenn es direkt eine native TypeScript-Datei wäre. Und so kann man relativ easy hingehen und bei einer bestehenden Codebase für die Bausteine, die am häufigsten verwendet werden, so Type-Definition nachziehen, auch ohne die Original-Datei auch nur anzufassen. Gibt es da noch andere Herausforderungen beim Umzug von JavaScript auf TypeScript oder ist es so einfach in Anführungsstrichen, wie du es jetzt dargestellt hast?

Also es kommt schon noch dieser zusätzliche Compile-Step dazu, das darf man nicht außer Acht lassen und insbesondere, wenn man noch andere Compile-Steps hat, wie zum Beispiel so ein React Webpack-Bundler oder sonst irgendwas, dann kann es schon einigermaßen schwierig sein, die zu verheiraten, weil man dann so ein bisschen auf die Reihenfolge achten muss, was passiert in welchem Schritt, das ist ja dann so eine Build-Pipeline vom Source-Code bis hin zu dem tatsächlichen JavaScript-Wandel, das rausfällt. Das kann tatsächlich schwierig sein. Ansonsten, was die eigentliche Codebase angeht, dadurch,

dass das 100% kompatibel ist und Fehler möglicherweise dann zusätzlich auffallen, die vorher nicht klar waren, ist das, wie man mal so sagt, relativ einfach. die Probleme kriegt man dann im Alltag. Ich habe noch eine Frage, weil du eben von diesen Type-Dateien gesprochen hast. Wir machen das nicht mehr, dass wir separate Type-Dateien machen, sondern schreiben die Typen dann direkt in die Dateien, also in die Hauptdateien von den Objekten und so damit rein, oder? Ja, genau, also es ist ja ein bisschen, kommt ein bisschen auf den Use-Case an, wenn wir jetzt wirklich über die globalen Entities sprechen,

die in der ganzen Anwendung relevant sind, dann haben wir schon irgendwo globale Dateien, wo wir die lagern, weil sie eben jetzt nicht zu einzelnen React-Komponenten gehören oder zu einzelnen Funktionen oder so, sondern so übergreifend sind, aber für so eine klassische React-Komponente haben wir alles, was die braucht, in der Datei selber drin. Was ich wesentlich praktischer finde, weil früher ist man ständig in diesen Type-Dateien gelandet, mit denen man oft nicht so viel anfangen kann oder die dann so ein bisschen zusammenhangslos sind, während man, wenn man die Definition dann direkt neben dem,

ich sag mal, neben der React-Klasse hat, wo das verwendet wird oder Funktion, dann ist das meistens eher praktischer, denke ich. Und früher haben wir die, die Interfaces ja zum Beispiel auch mit dem i dann benannt, also zum Beispiel iUser, das war dann das Interface dafür, Das machen wir auch nicht mehr. Ich weiß nicht, ob das jetzt zu tief einsteigt, aber letztlich Thema TypeScript ist es ja irgendwie, vielleicht sagst du da auch gerade noch einen Satz zu. Ja, sehr gerne. Also es ist tatsächlich gar nicht so einfach zu sagen, weil da jeder so eine andere Meinung hat, wie denn eigentlich das Interface

zu benennen ist. Also User-Interface kann man da machen oder iUser sind so klassische Sachen. Was wir aber gesagt haben, ist auch wieder angelehnt an dieses Entity-Konzept, das kommt immer wieder, wirklich spannend, dass diese Entity außerhalb des Codes eigentlich das stärkste Abstraktionsmodell, was wir haben. Also wenn wir jetzt über wieder, weiß ich nicht, so eine Social-Media-Seite reden, dann ist so ein User-Entity eines der stärksten Konzepte, das wir haben, wo ganz viel drum herum gebaut ist. Und wenn wir das versuchen, in den Code zu übertragen, dann ist das, was wir im Code haben, was am nächsten

zu dieser globalen, allumfassenden Entity ist, ist eben dieses Interface. Und deswegen muss das denselben Namen haben, also dann auch einfach User. Und alles andere wird so drum herum gebaut. Und wir haben es dann so gemacht, dass wenn zum Beispiel wir eine React-Komponente haben, die einen einzelnen User anzeigt, also im MVC-Modell so eine klassische View für eine einzelne User-Entity, dann nennen wir die React-Komponente User-View. Ein bisschen sperrig mit dieser Endung noch hinten dran, aber eben, um da keine Namenskollision mit diesem Interface zu haben. Das Interface ist das Maß aller Dinge

und da wird alles drum herum benannt. Kay, sollen wir zu den Nachteilen kommen, die es eventuell gar nicht gibt? Haben wir es ja schon angesprochen, aber wenn du da noch Punkte hast, dann gerne raus damit. Ich habe alle Nachteile, die ich mir aufgeschrieben habe, habe ich ja selbst schon so ein bisschen entschärft. Was ist das Beste? Das eine ist natürlich, dass es kompiliert wird. Das kennen wir aber von früher eben vom JavaScript auch schon, dass wir in neueren ES6-Versionen geschrieben haben und dann in ältere kompilieren mussten. Das wäre heute nicht mehr der Fall, aber deswegen war das für uns

jetzt gar kein so ein Bruch. Aber letztendlich ist es natürlich so. Dann haben wir aber diese Minify-Funktionen und so, die wir sowieso machen. Von daher, denke ich, braucht man den Zwischenschritt immer. Muss ich deswegen so ein bisschen abschwächen, diesen Nachteil. Dann haben wir den Code, der an sich vielleicht komplizierter zu verstehen ist, weil die Leute entweder JavaScript schon kennen oder zumindest mit mehr Code konfrontiert sind und sich natürlich auch damit beschäftigen müssen, was für Types es überhaupt gibt, während man in JavaScript vielleicht auch mal durchkommt, wenn man nicht ganz genau versteht,

was der eine oder andere Type so macht. Gerade mit diesen ganzen Anti-Fein-Sachen und so oder Null-Sachen, da wird es ja manchmal dann ein bisschen komplizierter und da muss man sich in TypeScript schon mit beschäftigen, während man in JavaScript da manchmal so durchrutscht und bestenfalls keinen Fehler produziert. Ja, wir müssen mal einen Podcast über undefined in JavaScript machen. Sehr gerne. Und das ist für mich genauso ein Vor- wie ein Nachteil. Eigentlich für mich eher ein Vorteil und da schließt sich dieser mehr Code eben dran an, wo du ja auch schon gesagt hast, dass wir unter anderem Typechecks

weglassen können. Das heißt, da verlieren wir auf der anderen Seite auch wieder Code. Ja, und so bleiben für mich eigentlich fast nur Vorteile bei TypeScript über. Vielleicht ist noch ein bisschen ein Nachteil, dass TypeScript ja von Microsoft entwickelt wird, aber ich glaube, letztlich ist es dann auch Open Source und ich habe nicht das Gefühl, dass das jetzt von Microsoft irgendwie in eine bestimmte proprietäre Richtung oder so gedrückt wird. Also ich kann gar keine großen Nachteile finden und vielleicht leitet uns das auch dahin über, warum wir TypeScript verwenden, weil es eben nur Vorteile hat.

Das ist ja eigentlich der stärkste Indikator. Also bei jedem Frontend-Projekt, das wir anfangen, machen wir direkt, ohne zu fragen, am Anfang als erstes TypeScript drauf oder starten sogar mit so einem TypeScript-Basis-Package für React-Anwendungen oder sowas. Und das ist überhaupt gar keine Frage und Diskussion bei uns, ob wir TypeScript verwenden. Ich glaube, die Vorteile haben wir jetzt heute ausführlichst zusammengefasst. Wunderbar. Dann gibt es für mich fast auch nichts mehr hinzuzufügen. Wunderbar. Für mich auch nicht, Felix. Vielen Dank. Das war sehr freulich. Und wie war das Stehen? Ja, das war sehr dynamisch.

Ähnlich wie TypeScript. Nee, wie JavaScript. Ja, wunderbar. Kay, wir hören uns in der nächsten Woche. Dann bis zum nächsten Mal. Ciao, ciao. Tschüss.