1
00:00:00,160 --> 00:00:02,920
Type Script wird zehnmal 
schneller, zumindest der 

2
00:00:02,920 --> 00:00:07,760
Compiler, weil er gerade in 
diesem Moment von Type Script in

3
00:00:07,760 --> 00:00:10,960
Go portiert wird. 
Anders Heilsberg der Papa von 

4
00:00:10,960 --> 00:00:14,640
Type Script hat das letzte Woche
in einem Blogspot angekündigt 

5
00:00:14,640 --> 00:00:18,600
und beeindruckende Performance 
Gewinne gezeigt, was das für uns

6
00:00:18,600 --> 00:00:21,280
als Developer bedeutet, 
besprechen wir in dieser Folge. 

7
00:00:27,120 --> 00:00:31,880
Und damit herzlich Willkommen zu
Folge 111 des To do die Spell of

8
00:00:31,880 --> 00:00:37,400
Podcasts Yeah mit Robin Manuel 
Thiel und mir malte Lantin Robin

9
00:00:37,400 --> 00:00:41,280
Manuel, wie geht's dir heute? 
Ja Hi malte, mir geht's gut. 

10
00:00:41,280 --> 00:00:45,680
Ich hab die letzten Tage wieder 
ein altes Hobby, was ich nie 

11
00:00:45,680 --> 00:00:50,280
irgendwie richtig zu Ende 
gebracht habe aufgemacht und wir

12
00:00:50,280 --> 00:00:52,560
reden ja heute über type Script,
über type Script denke ich auch 

13
00:00:52,560 --> 00:00:55,840
immer ein bisschen an Typing, 
also tippen auf der Tastatur und

14
00:00:55,840 --> 00:00:57,000
wir hatten das letzte Mal schon 
gesagt. 

15
00:00:57,080 --> 00:00:59,680
Ich hab dir schon mal davon 
erzählt, dass wir mal ne Folge 

16
00:00:59,680 --> 00:01:02,440
dazu machen. 
Hör mal, hör mal hin ist. 

17
00:01:02,440 --> 00:01:04,720
Das ein neues Keyboard oder übst
du wieder? 

18
00:01:04,800 --> 00:01:07,280
Das ist ein altes Keyboard mit 
neuen Switches. 

19
00:01:08,160 --> 00:01:11,360
Und hör mal diesen. 
Diesen Thorx hat man, wenn sich 

20
00:01:11,360 --> 00:01:14,000
das schön weich anfühlt wie auf 
Moos. 

21
00:01:14,880 --> 00:01:17,560
Ich bin wieder im Keyboard Game,
ich bin ich hab immer noch das 

22
00:01:17,560 --> 00:01:19,040
Gefühl ich brauch ein geileres 
Keyboard, immer wenn ich 

23
00:01:19,040 --> 00:01:20,720
irgendwie so youtube Videos 
sehe, die Leute haben so geile 

24
00:01:20,720 --> 00:01:23,040
Keyboards, klingen so geil für 
mich ist eher der Klang und ich 

25
00:01:23,040 --> 00:01:26,680
komm ja von so nem. 
Von so einem Keyboard, das finde

26
00:01:26,680 --> 00:01:29,000
ich auch irgendwie gut. 
Also so ein flaches Keyboard und

27
00:01:29,000 --> 00:01:32,280
diese richtig großen mit diesen 
dicken Tasten, die haben mir 

28
00:01:32,280 --> 00:01:34,160
irgendwie nicht getaugt, habe 
ich auch 1 hier, aber da machen 

29
00:01:34,160 --> 00:01:36,400
wir mal eine eigene Folge zu, 
aber jetzt bin ich wieder im Low

30
00:01:36,400 --> 00:01:38,880
Profile Clicky Keyboard Game, 
aber halt nicht mit diesen 

31
00:01:39,760 --> 00:01:43,720
Klickigen Switches, sondern mit 
linearen Switches und irgendwie 

32
00:01:43,720 --> 00:01:45,600
ist das so ein bisschen so ein 
Nerd Ding, dann kannst du die 

33
00:01:45,600 --> 00:01:48,720
Tasten da so rausziehen und dann
kannst du da die die Switches 

34
00:01:48,720 --> 00:01:51,720
rein reinpacken und dann klingt 
das schön und dann kannst du die

35
00:01:51,720 --> 00:01:55,200
da selber belegen und. 
Ist ja auch beruhigend, ne, aber

36
00:01:55,200 --> 00:01:57,840
vielleicht können wir ja mal so 
eine ASMR folge machen, wo du 

37
00:01:57,840 --> 00:02:00,720
irgendwie mitfährst Tipps und 
wir dürfen alle zuhören. 

38
00:02:00,880 --> 00:02:03,120
Und dann flüstern wir die ganze 
Folge lang nur. 

39
00:02:03,600 --> 00:02:06,640
Der war Geflosternd und getestet
wird anstrengend okay. 

40
00:02:08,560 --> 00:02:13,360
Komm mal so, sorry, kurz bin ich
durchgegangen. 

41
00:02:13,840 --> 00:02:16,760
Ja, kein Problem. 
Wir freuen uns ja, wenn wir an 

42
00:02:16,760 --> 00:02:19,360
deinen kleinen Alltagsfreuden 
teilhaben können. 

43
00:02:19,680 --> 00:02:22,640
Und ja, von daher können wir uns
schon mal auf die Folge 

44
00:02:22,640 --> 00:02:27,120
vorbereiten, wo du uns dann die 
Instant Out deines Keyboard 

45
00:02:27,120 --> 00:02:32,280
Games mit uns teilst. 
So, aber jetzt wollen wir wieder

46
00:02:32,280 --> 00:02:34,640
zu den zu den Themen hier. 
Wir wollen über Type Script und 

47
00:02:34,640 --> 00:02:37,160
Go sprechen und bevor wir 
einsteigen wie immer natürlich n

48
00:02:37,160 --> 00:02:40,560
ganz herzliches Dankeschön an 
alle, die uns seit der letzten 

49
00:02:40,560 --> 00:02:44,080
Folge Kaffee spendiert haben, 
natürlich fleißig genutzt haben 

50
00:02:44,080 --> 00:02:47,040
um den in Code und Podcast 
folgen umzuwandeln. 

51
00:02:47,400 --> 00:02:51,280
Und da müssen wir einmal Death 
Boys danken für 5 Kaffee und 

52
00:02:51,360 --> 00:02:55,360
Thomas danken für 3 Kaffee ganz,
ganz ganz ganz lieben Dank an 

53
00:02:55,400 --> 00:02:57,280
euch beide. 
Herzlichen Dank. 

54
00:02:57,440 --> 00:03:00,920
Wenn auch ihr, sagt Ey, das ist 
ein cooler Podcast, würden den 

55
00:03:00,920 --> 00:03:03,520
Jungs auch gerne einen Kaffee 
ausgeben, dann freuen wir uns da

56
00:03:03,520 --> 00:03:04,640
immer sehr, sehr, sehr, sehr 
drüber. 

57
00:03:04,640 --> 00:03:07,040
Ganz ganz ehrlich auch überall 
die Jahre, immer immer wie ein 

58
00:03:07,040 --> 00:03:09,520
kleines Kind, wenn jemand wenn 
wir diese E Mail bekommen und 

59
00:03:09,520 --> 00:03:12,400
sagen, Hey jemand hat den hat 
uns einen Kaffee spendiert, dann

60
00:03:12,400 --> 00:03:16,080
findet ihr einen Link unten zu 
bei mir Coffee in den Shownotes.

61
00:03:16,720 --> 00:03:20,040
Und damit lass uns in die Folge 
der Woche einschränken. 

62
00:03:20,040 --> 00:03:22,560
Das ist ein ganz neues 
Announcement, ich glaube, der 

63
00:03:22,560 --> 00:03:26,480
blogspot kam vor ein paar Tagen 
erst, als anders Halsberg 

64
00:03:26,480 --> 00:03:30,720
angekündigt hat, dass eine große
Überarbeitung von Type Script 

65
00:03:30,720 --> 00:03:33,760
stattfindet und es wird nicht 
die Sprache an sich 

66
00:03:33,760 --> 00:03:38,000
überarbeitet, sondern es wird 
die ja die quasi darunter 

67
00:03:38,000 --> 00:03:41,040
liegende Infrastruktur 
überarbeitet, nämlich der Type 

68
00:03:41,040 --> 00:03:45,920
Script Compiler und der in der 
Idee laufende Language Service. 

69
00:03:46,400 --> 00:03:50,800
Und mit diesen neuen 
Implementierungen wird das ganze

70
00:03:50,960 --> 00:03:56,400
massiv schneller und da wollen 
wir mal heute ein bisschen drauf

71
00:03:56,400 --> 00:04:01,280
eingehen, was eigentlich da die 
Hintergründe sind und warum auch

72
00:04:01,600 --> 00:04:04,400
anders Halsberg, der auch lange 
an C. 

73
00:04:04,400 --> 00:04:07,520
Sharp mitgearbeitet hat, sich 
dafür entschieden hat, mit 

74
00:04:07,520 --> 00:04:12,240
seinem Team jetzt das Ganze neu 
zu implementieren, und zwar 

75
00:04:12,240 --> 00:04:15,680
nicht in in Anführungsstrichen 
der Microsoft Sprache. 

76
00:04:16,720 --> 00:04:19,720
C. 
Sharp, sondern Ingo für 

77
00:04:19,720 --> 00:04:23,040
diejenigen, die es nicht wissen 
anders Halsberg arbeitet bei 

78
00:04:23,040 --> 00:04:28,160
Microsoft seit vielen Jahren und
hat damit hat in dem in der 

79
00:04:28,160 --> 00:04:32,960
Funktion Type Script quasi 
erfunden. 

80
00:04:33,120 --> 00:04:36,160
Er hat mit seinem Team die 
Sprache entwickelt, die Idee 

81
00:04:36,480 --> 00:04:41,600
dieser Sprache die Typsicher zu 
entwickeln, ist aber letzten 

82
00:04:41,600 --> 00:04:47,120
Endes in Standard Java Script. 
Transpediert wird und damit in 

83
00:04:47,120 --> 00:04:51,680
jeder herkömmlichen Java Script 
Runtime, sprich im Browser oder 

84
00:04:52,000 --> 00:04:56,240
auch auf dem Server genutzt 
werden kann und dementsprechend 

85
00:04:56,240 --> 00:05:00,240
ist natürlich anders halsberg 
auch eine Koryphäe, so in dieser

86
00:05:00,240 --> 00:05:02,720
ganzen Welt der 
Entwicklungssprachen. 

87
00:05:03,200 --> 00:05:05,240
Ja, absolut. 
Also wenn das einer ankündigt, 

88
00:05:05,240 --> 00:05:07,560
dann schon dann schon eher als 
ich habe es ja immer im Intro 

89
00:05:07,560 --> 00:05:09,960
schon gesagt, der Papa von Type 
Script, der hat es so ein 

90
00:05:09,960 --> 00:05:12,400
bisschen erfunden. 
Weil ich ganz kurz gar nichts 

91
00:05:12,400 --> 00:05:15,520
mit typescript anfangen kann. 
Also es ist, ich glaub Java 

92
00:05:15,520 --> 00:05:17,920
Script ja den meisten die davon 
was sagen, das ist eigentlich 

93
00:05:17,920 --> 00:05:21,520
die Standardsprache um Logik vor
allem in Webanwendungen und im 

94
00:05:21,520 --> 00:05:24,960
Browser zu beschreiben und 
auszuführen ist eine 

95
00:05:24,960 --> 00:05:28,320
Skriptsprache, deswegen heißt es
auch Java Script, wird also auch

96
00:05:28,320 --> 00:05:30,880
ganz klassisch gar nicht 
kompiliert, irgendwie auf Byte 

97
00:05:30,880 --> 00:05:34,360
Code runter, sondern immer vom 
Browser oder von einer anderen 

98
00:05:34,360 --> 00:05:37,680
Runtime wie zum Beispiel no js 
interpretiert und dann 

99
00:05:37,680 --> 00:05:42,240
ausgeführt und. 
Java Script ist sehr, sehr 

100
00:05:42,240 --> 00:05:47,560
einsteigerfreundlich, hat aber 
dann, also das kommt aber zu 

101
00:05:47,560 --> 00:05:50,160
einem Preis, das ist vor allem 
der einem vor allem dann auf die

102
00:05:50,160 --> 00:05:53,120
Füße fällt, wenn man in großen 
Projekten und Teams arbeitet. 

103
00:05:53,680 --> 00:05:56,800
Java Strip hat nämlich keine 
Typsicherheit, das heißt, eine 

104
00:05:56,800 --> 00:06:00,640
Variable kann alles sein und 
kann auch den Typen während der 

105
00:06:00,640 --> 00:06:03,520
Laufzeit ändern, das heißt, ich 
kann irgendwie sagen, war Name 

106
00:06:03,680 --> 00:06:07,680
ist gleich und dann halt 
irgendein String malte. 

107
00:06:08,320 --> 00:06:10,720
Und ich kann, kann, aber kann 
aber sein, dass irgendeine 

108
00:06:10,720 --> 00:06:12,920
Funktion und ich habe dann auf 
einmal da ne Zahl draus macht 

109
00:06:12,920 --> 00:06:15,280
und wenn ich dann da an diese 
Zahlen n String dranhängen will,

110
00:06:15,680 --> 00:06:17,360
kann das funktionieren. 
Kann auch manchmal sein, dass es

111
00:06:17,360 --> 00:06:19,080
dann irgendwie n Fehler gibt, 
weil ich dann 2 Strings nicht 

112
00:06:19,080 --> 00:06:21,080
addieren kann und das ist ne hat
manchmal einfach so n paar 

113
00:06:21,080 --> 00:06:23,720
Nebeneffekte und gerade in 
großen Projekten fällt einem das

114
00:06:23,720 --> 00:06:27,200
auf die Füße und deswegen hat 
vor einigen Jahren jetzt schon 

115
00:06:27,200 --> 00:06:31,480
eben besagte anders heizberg 
Type Script erfunden, das ist im

116
00:06:31,480 --> 00:06:34,800
Prinzip sieht das sehr sehr 
ähnlich aus zu Java Script Code,

117
00:06:34,960 --> 00:06:37,200
hat aber halt die Endung Punkt 
TS in den Dateien und nicht 

118
00:06:37,200 --> 00:06:39,880
Punkt JS. 
Und nimmt eigentlich javascript 

119
00:06:39,880 --> 00:06:43,200
und fügt Javascript diesen Typ 
Support hinzu, den man eben auch

120
00:06:43,200 --> 00:06:46,480
von typisierten Sprachen wie 
Java selber zum Beispiel kennt. 

121
00:06:46,960 --> 00:06:50,400
Und da die Browser aber 
zumindest damals noch alle 

122
00:06:50,400 --> 00:06:52,920
nichts mit Type Script anfangen 
konnten, hat sich an das 

123
00:06:52,920 --> 00:06:54,640
Heizbecken n Trick überlegen 
gesagt. 

124
00:06:54,640 --> 00:06:57,560
Man kann zwar in type Script 
programmieren, Type Script 

125
00:06:57,560 --> 00:07:00,320
selber wird aber niemals 
ausgeführt, sondern wird immer 

126
00:07:00,320 --> 00:07:02,840
in javascript umgewandelt, weil 
das konnten ja schon alle ne, da

127
00:07:02,840 --> 00:07:05,040
gab es sowohl no JS wenn ich auf
dem Server oder auf meinem 

128
00:07:05,040 --> 00:07:06,880
Computer hier irgendwie diesen 
Code ausführen möchte. 

129
00:07:07,440 --> 00:07:11,120
Oder halt der Browser selber als
Runtime für Java Script. 

130
00:07:11,120 --> 00:07:13,680
Das heißt immer ein 
Zwischenschritt in der Type 

131
00:07:13,680 --> 00:07:18,360
Script Programmierung ist in die
Kommandozeile TSC einzugeben, 

132
00:07:18,360 --> 00:07:21,440
das steht für Type Script 
Compiler und der geht eben hin, 

133
00:07:21,520 --> 00:07:24,320
nimmt meinen ganzen Type Script 
Code, umwandelt in den Java 

134
00:07:24,320 --> 00:07:27,280
Script um, sodass ich am Ende 
Java Script als Produkt 

135
00:07:27,360 --> 00:07:30,840
ausliefern kann und auch gar 
nicht ist auch gar nicht mehr 

136
00:07:30,840 --> 00:07:32,520
vorher relevant, ob ich es 
vielleicht mit type Script 

137
00:07:32,520 --> 00:07:34,640
beschrieben habe. 
Das heißt, Typesript selber 

138
00:07:34,640 --> 00:07:36,760
findet eigentlich nur während 
der Entwicklung wegen der 

139
00:07:36,760 --> 00:07:40,160
während der Programmierung statt
ausgeführt wird typesript aber 

140
00:07:40,880 --> 00:07:42,920
eigentlich nie. 
Es gibt jetzt noch 23 Ausnahmen,

141
00:07:42,920 --> 00:07:44,440
weil es auch schon jetzt ein 
paar Jährchen alt ist. 

142
00:07:44,440 --> 00:07:47,680
Typesript aber eigentlich nie 
und dieser Compiler, also dieser

143
00:07:47,680 --> 00:07:51,280
Schritt von Type Script auf Java
Script kommen, der nennt sich 

144
00:07:51,360 --> 00:07:54,240
Transpilieren, weil nicht 
wirklich kompiliert wird, der 

145
00:07:54,240 --> 00:07:57,840
eigentlich eher übersetzt, und 
der ist jetzt, na jetzt noch 

146
00:07:57,840 --> 00:08:00,640
nicht, aber der wird jetzt 
gerade, es gibt erste Demos, 10 

147
00:08:00,640 --> 00:08:03,520
mal schneller. 
Weil anders Halsberg eben mit 

148
00:08:03,520 --> 00:08:06,880
seinem Team hingegangen ist und 
hat wir portieren diesen 

149
00:08:06,880 --> 00:08:08,760
Compiler in Go und das ist ganz 
spannend. 

150
00:08:08,760 --> 00:08:11,880
Der Compiler selber, der ist 
auch schon in Type Script 

151
00:08:11,880 --> 00:08:16,160
geschrieben und das fällt einem 
manchmal bei sehr großen 

152
00:08:16,160 --> 00:08:19,360
Projekten auch auf die Füße, 
weil der nicht wahnsinnig 

153
00:08:19,360 --> 00:08:22,400
performant ist. 
Dieser Umwandlungsprozess, und 

154
00:08:22,400 --> 00:08:24,080
der wird jetzt schneller. 
Ja, und das ist genau das 

155
00:08:24,080 --> 00:08:27,440
Stichwort. 
Sehr große Projekte, es werden 

156
00:08:27,440 --> 00:08:31,200
ja immer größere Projekte auch 
in Type Script. 

157
00:08:31,520 --> 00:08:34,080
Und damit in Webtechnologien 
entwickelt. 

158
00:08:34,080 --> 00:08:37,679
Und auch die populärste 
Entwicklungsumgebung, die wir 

159
00:08:37,679 --> 00:08:40,480
heutzutage haben, für 
Webprojekte, aber auch 

160
00:08:40,480 --> 00:08:44,240
zahlreiche andere Projekte, 
nämlich Visual Studio Code, ist 

161
00:08:44,240 --> 00:08:48,160
in Type Script entwickelt, ist 
eigentlich eine Webapplikation. 

162
00:08:48,720 --> 00:08:50,080
Die in Touchscreen entwickelt 
ist. 

163
00:08:50,080 --> 00:08:52,480
Und da hab ich irgendwie 
anderthalb Millionen Lines of 

164
00:08:52,480 --> 00:08:56,080
Code, das ist ne richtig große 
Anwendung und bei diesen großen 

165
00:08:56,080 --> 00:08:59,400
Anwendungen, da ist es natürlich
wichtig, dass wenn ich an so 

166
00:08:59,400 --> 00:09:02,600
einer großen Anwendung arbeite, 
dass dann natürlich gerade so 

167
00:09:02,600 --> 00:09:05,600
eine Übersetzung auch schnell 
und performant ist. 

168
00:09:06,480 --> 00:09:09,480
Aber auch wenn ich an kleineren 
Applikationen arbeite, habe ich 

169
00:09:09,480 --> 00:09:13,440
ja in in der Regel diesen Tab 
Script Compiler im Hintergrund 

170
00:09:13,440 --> 00:09:15,760
laufen, damit ich meine 
Anwendung irgendwie auch auf dem

171
00:09:15,760 --> 00:09:18,000
zweiten Fenster eine 
Webanwendung vielleicht mir 

172
00:09:18,000 --> 00:09:21,160
anschauen kann, während ich da 
dran entwickel oder auch im 

173
00:09:21,160 --> 00:09:23,760
Debugging. 
Und da ist natürlich Performance

174
00:09:23,760 --> 00:09:25,080
entscheidend. 
Ich möchte halt nicht immer 

175
00:09:25,080 --> 00:09:29,200
irgendwie so einen Bildvorgang 
laufen lassen bei meiner 

176
00:09:29,600 --> 00:09:32,360
üblichen kleinen Webapplikation,
die ich vielleicht als 

177
00:09:32,360 --> 00:09:34,960
Hobbyprojekt mache, kommt das 
vielleicht nicht ganz so zu 

178
00:09:34,960 --> 00:09:38,080
tragen, also. 
Aber wenn ich jetzt große 

179
00:09:38,080 --> 00:09:42,720
Applikationen habe, dann ist das
natürlich n signifikanter 

180
00:09:42,720 --> 00:09:46,800
Unterschied, ob ich jetzt am 
Beispiel von VS Code irgendwie 

181
00:09:47,120 --> 00:09:51,760
anderthalb Minuten warte, bis 
das Ganze kompiliert ist oder 

182
00:09:52,400 --> 00:09:57,200
mit dieser neuen Implementierung
des Compilers nur knapp unter 10

183
00:09:57,200 --> 00:09:59,280
Sekunden und damit wirklich 
diese. 

184
00:10:00,320 --> 00:10:03,960
Beschleunigung um den Faktor 10 
sehe und das macht dann 

185
00:10:03,960 --> 00:10:06,360
natürlich auch schon in der 
Entwicklungszeit einen 

186
00:10:06,360 --> 00:10:07,520
Unterschied. 
Genau. 

187
00:10:07,520 --> 00:10:09,440
Und das ist nicht nur Visual 
Studio Code, ne, das natürlich 

188
00:10:09,440 --> 00:10:11,840
ist so ein bisschen das 
Beispiel, weil es einfach so die

189
00:10:11,840 --> 00:10:15,840
Haus und Hof IDE oder der Editor
von Microsoft eben ist, aber man

190
00:10:15,840 --> 00:10:18,520
konnte das eben auch mit anderen
Projekten schon nachweisen, 

191
00:10:18,520 --> 00:10:20,400
diesen Performancegewinn, der 
ist immer so im Durchschnitt, 

192
00:10:20,400 --> 00:10:24,880
also dass dieser neue Type 
Script go Compiler um den Faktor

193
00:10:24,880 --> 00:10:27,680
10 schneller ist. 
Und ne wie malte gerade schon 

194
00:10:27,680 --> 00:10:29,320
gesagt hat, ne mit Visual Studio
Code. 

195
00:10:29,320 --> 00:10:31,520
Das ist ja eigentlich ne Desktop
Anwendung, das heißt die basiert

196
00:10:31,520 --> 00:10:33,600
auf Electron, das ist n 
Framework wo ich mit 

197
00:10:33,600 --> 00:10:38,320
webtechnologien Apps für den den
Computer oder das Smartphone 

198
00:10:38,320 --> 00:10:41,440
schreiben kann und das zeigt 
auch eigentlich wie wie weit 

199
00:10:41,440 --> 00:10:44,320
verbreitet diese Technologien 
sind und wie groß dieser Impact 

200
00:10:44,320 --> 00:10:47,600
ist und entsprechend viel 
Resonanz gab es dann eben auch 

201
00:10:47,600 --> 00:10:51,160
in der Community dazu, dass als 
jetzt angekündigt wurde, dass 

202
00:10:51,160 --> 00:10:54,000
dieser Type Script Compirer eben
in Go portiert wird. 

203
00:10:54,480 --> 00:10:56,640
Das Beispiel ist aus meiner 
Sicht auch so interessant, weil 

204
00:10:56,640 --> 00:10:59,520
es so n bisschen diesen in 
Inception loop hat. 

205
00:10:59,520 --> 00:11:03,320
Ne, dass ich halt irgendwie mit 
VS Code, welches in Type Script 

206
00:11:03,320 --> 00:11:07,960
geschrieben ist, an type Script 
arbeite und einen type script 

207
00:11:07,960 --> 00:11:11,600
compiler heute. 
Nutzer der in Type Script 

208
00:11:11,600 --> 00:11:14,640
entwickelt wurde. 
Und da kommt jetzt diese 

209
00:11:14,640 --> 00:11:18,400
Änderung ins Spiel und zwar wird
nämlich genau dieser Compiler 

210
00:11:18,720 --> 00:11:22,800
jetzt aktuell übersetzt von 
einer Implementierung in Type 

211
00:11:22,800 --> 00:11:28,560
Script in eine Implementierung 
in Go, welche ich dann nativ für

212
00:11:28,560 --> 00:11:31,200
die entsprechenden Plattformen 
kompilieren kann. 

213
00:11:32,000 --> 00:11:35,000
Ganz wichtig diese Änderung, 
dass der Type Script Compiler 

214
00:11:35,000 --> 00:11:37,160
jetzt nicht mehr selber in type 
Script dann geschrieben wird, 

215
00:11:37,160 --> 00:11:42,160
sondern in go übersetzt hat. 
Keine Auswirkungen auf die App, 

216
00:11:42,160 --> 00:11:44,240
die ihr vielleicht in Type 
Script schreibt. 

217
00:11:44,240 --> 00:11:48,040
Das heißt nicht, dass jetzt euer
Code in Go statt in Java Script 

218
00:11:48,040 --> 00:11:51,320
Transpiliert wird, nur der 
Compiler und der Language Server

219
00:11:51,320 --> 00:11:54,320
kommen wir gleich noch mal zu, 
der wird in Go in Go neu 

220
00:11:54,320 --> 00:11:57,240
geschrieben, das heißt, eure 
Anwendungen wird jetzt nicht 

221
00:11:57,240 --> 00:12:00,160
irgendwie morgen in Go 
transpiliert statt in Java 

222
00:12:00,160 --> 00:12:02,720
Script. 
Am Ende wird dadurch nicht nur 

223
00:12:02,720 --> 00:12:06,720
schneller, sondern das Team hat 
auch gesehen, dass sie. 

224
00:12:07,440 --> 00:12:09,920
Auch ne bessere 
Speichereffizienz hinbekommen 

225
00:12:10,080 --> 00:12:15,200
und damit auch allgemein die 
sonstigen Performance Kriterien 

226
00:12:15,520 --> 00:12:17,960
verbessern können. 
Und wir können ja gleich noch 

227
00:12:17,960 --> 00:12:20,640
mal n bisschen. 
Auf die anderen Technologien 

228
00:12:20,640 --> 00:12:24,480
eingehen, die sich das Team als 
Alternative angeschaut hat, weil

229
00:12:24,720 --> 00:12:27,880
gerade von einem Team bei 
Microsoft hätte man ja 

230
00:12:27,880 --> 00:12:31,080
vielleicht erwartet, dass sie 
nicht als Erstes die Haus und 

231
00:12:31,080 --> 00:12:34,800
Hofsprache von Google nehmen, 
sondern tatsächlich irgendwas, 

232
00:12:34,960 --> 00:12:37,680
was auch in House bei Microsoft 
entwickelt wird. 

233
00:12:38,360 --> 00:12:39,920
Es ist ganz spannend. 
Also das waren auch so die 

234
00:12:39,920 --> 00:12:42,400
ersten Reaktionen aus der 
Community, warum denn go und 

235
00:12:42,400 --> 00:12:45,920
nicht wie C plus plus, was ja 
eigentlich. 

236
00:12:46,720 --> 00:12:50,160
Von der Performance immer noch 
ungeschlagen ist oder oder Rust,

237
00:12:50,160 --> 00:12:52,320
was vielleicht sogar noch 
performanter wäre. 

238
00:12:52,320 --> 00:12:56,920
Ne ich mein weil theoretisch, 
wenn man sich jetzt irgendwie 

239
00:12:56,920 --> 00:13:00,720
sagt, OK wir, wir schreiben 
jetzt diesen Compiler neu, dann 

240
00:13:00,720 --> 00:13:03,440
kann man ja und und der vor 
allem auf auf Performance jetzt 

241
00:13:03,440 --> 00:13:05,840
ausgelegt sein soll, warum dann 
kann man sich auch anschauen, 

242
00:13:05,840 --> 00:13:08,480
warum schreibt man den jetzt 
nicht direkt in Rust, was ja 

243
00:13:08,480 --> 00:13:12,240
noch schneller als go ist oder 
in C plus plus was auch Cross 

244
00:13:12,240 --> 00:13:14,480
Plattform ist und noch schneller
als alle zusammen sind. 

245
00:13:15,680 --> 00:13:17,320
Ich find es dann immer 
interessant, wie dann in Social 

246
00:13:17,320 --> 00:13:19,480
Media die Leute halt immer 
irgendwie sofort irgendwelche 

247
00:13:19,480 --> 00:13:23,120
Spekulationen anstoßen und 
sagen, Hey, Sie verwenden jetzt 

248
00:13:23,120 --> 00:13:25,640
nicht c. 
Sharp bedeutet das was für diese

249
00:13:25,640 --> 00:13:27,560
Sprache? 
Heißt das, dass Microsoft nicht 

250
00:13:27,560 --> 00:13:30,400
mehr an C. 
Sharp glaubt und ich glaub da 

251
00:13:30,400 --> 00:13:34,320
interpretieren manchmal die ein 
oder anderen da zu viel rein, 

252
00:13:34,560 --> 00:13:38,680
weil am Ende ist es nämlich so, 
dass das Team sich mehrere 

253
00:13:38,680 --> 00:13:41,960
Technologien angeschaut hat und 
dann am Ende, und das ist glaub 

254
00:13:41,960 --> 00:13:45,040
ich aus unserer Sicht als Nutzer
dieser Technologien. 

255
00:13:45,200 --> 00:13:48,800
Genau die richtige Entscheidung,
die Sprache oder die Technologie

256
00:13:48,800 --> 00:13:53,120
genommen hat, die für den Job am
besten geeignet ist. 

257
00:13:53,120 --> 00:13:58,160
Und da kommen vielleicht auch 
nicht nur die Dinge zum Tragen, 

258
00:13:58,160 --> 00:14:01,200
die man vielleicht 
offensichtlich beurteilen würde.

259
00:14:01,200 --> 00:14:05,360
OK, was ist die Performance, was
sind die Performance Kriterien 

260
00:14:05,360 --> 00:14:08,240
wie Speicher, Geschwindigkeit et
cetera, sondern es kommen 

261
00:14:08,240 --> 00:14:09,840
natürlich auch andere Kriterien,
die. 

262
00:14:10,240 --> 00:14:13,680
Zum Tragen, wie zum Beispiel, 
welche Struktur hat die 

263
00:14:13,680 --> 00:14:17,520
Programmiersprache, welche 
Sprachkonstrukte gibt es, weil 

264
00:14:17,520 --> 00:14:21,280
auch ein Ziel bei dieser 
Übersetzung von Type Script 

265
00:14:21,280 --> 00:14:25,280
jetzt in Go war, dass die 
Semantik gleich bleibt, dass man

266
00:14:25,280 --> 00:14:28,560
tatsächlich auch ein Äquivalent 
hat, wenn man dann die beiden 

267
00:14:28,560 --> 00:14:31,400
Implementierungen nebeneinander 
liegt, dass man sagt, OK, das 

268
00:14:31,400 --> 00:14:34,680
ist genau eine. 
Übersetzung der aktuellen Type 

269
00:14:34,680 --> 00:14:39,200
Script Implementierung in Go und
Dementsprechend ändert sich 

270
00:14:39,200 --> 00:14:42,960
nichts an der Art und Weise, wie
dieser Transpiler oder Compiler 

271
00:14:42,960 --> 00:14:46,440
funktioniert, sondern es ist 
letzten Endes einfach nur eine 

272
00:14:46,440 --> 00:14:48,960
andere Technologie, in der das 
umgesetzt wurde. 

273
00:14:49,280 --> 00:14:51,440
Das ist ganz wichtig, ne. 
Wir sind ja eben nicht auf der 

274
00:14:51,440 --> 00:14:53,680
grünen Wiese, wir haben ja das 
Team hat ja nicht gesagt, wir 

275
00:14:53,680 --> 00:14:57,080
schreiben den Type Script 
Compiler neu, sondern das heißt 

276
00:14:57,080 --> 00:15:00,000
sich hier ohne Import, das heißt
das Ding wird portiert. 

277
00:15:00,400 --> 00:15:03,600
Und da ist, wie malte gerade 
schon gesagt hat, einfach grob 

278
00:15:03,600 --> 00:15:06,480
von der Struktur am ähnlichsten 
oder am geeignetsten für diesen 

279
00:15:06,480 --> 00:15:10,000
Port gewesen. 
Und abgesehen davon halte ich 

280
00:15:10,000 --> 00:15:11,720
diese ganze Diskussion auch 
irgendwie für so n bisschen 

281
00:15:11,720 --> 00:15:13,120
übertrieben. 
Also ich verstehe nicht, warum 

282
00:15:13,120 --> 00:15:16,080
die Leute jetzt irgendwie hier 
sagen, ja, Technologie X ist 

283
00:15:16,080 --> 00:15:19,040
besser oder Technologie y ist 
besser, wenn wir gerade um ne 

284
00:15:19,040 --> 00:15:22,320
wir wir reden gerade davon, dass
das Ding 10 mal schneller wird 

285
00:15:22,440 --> 00:15:25,800
als vorher, also ob ich da jetzt
ob ich das jetzt 10 oder 10 halb

286
00:15:25,800 --> 00:15:28,080
mal schneller mache, indem ich 
noch mal ne andere Technologie 

287
00:15:28,080 --> 00:15:29,800
nehme. 
Ich weiß nicht, ob das die 

288
00:15:29,800 --> 00:15:32,240
Diskussion überhaupt wert ist 
und warum mir nicht C Sharp 

289
00:15:32,240 --> 00:15:34,000
gewählt wurde, ist glaube ich 
relativ offensichtlich. 

290
00:15:34,880 --> 00:15:36,720
Microsoft ist immer noch absolut
committed zu C. 

291
00:15:36,720 --> 00:15:38,840
Sharp als Programmiersprache, 
aber für C. 

292
00:15:38,840 --> 00:15:41,200
Sharp brauche ich eben die 
Dotnet Runtime um den 

293
00:15:41,200 --> 00:15:44,480
installiert zu haben, wohingegen
Go und auch Ruston C plus plus 

294
00:15:44,880 --> 00:15:48,280
eben in absolut alternativen 
Code runterkompiliert werden 

295
00:15:48,280 --> 00:15:51,080
können, wo ich keine eigene 
Runtime verbrauche und gerade 

296
00:15:51,080 --> 00:15:53,320
wenn es hier um ne um ne 
Verschlankung auch von dieser 

297
00:15:53,320 --> 00:15:56,040
ganzen Sache geht, dann finde 
ich absolut die richtige 

298
00:15:56,040 --> 00:15:57,200
Entscheidung, die Sie hier 
getroffen haben. 

299
00:15:57,680 --> 00:16:00,560
Und finde ich auch noch mal ein 
Commitment zu einer Open Source 

300
00:16:00,560 --> 00:16:03,240
Community, zu einer 
Technologieoffenheit, die auch 

301
00:16:03,240 --> 00:16:06,280
in denen, die natürlich super 
wichtig ist, gerade diesen 

302
00:16:06,280 --> 00:16:08,640
Kontext. 
Das heißt, das Team nutzt jetzt 

303
00:16:08,640 --> 00:16:12,880
go als Low Level Sprache, die 
Multithreading beherrscht und 

304
00:16:12,880 --> 00:16:16,080
nativ auf verschiedene 
Plattformen portiert werden kann

305
00:16:16,080 --> 00:16:20,880
und sieht da signifikante 
Performance gewinne wann? 

306
00:16:21,240 --> 00:16:24,240
Können wir davon profitieren? 
Das ist ja heute noch nicht 

307
00:16:24,240 --> 00:16:27,160
live, ich glaube, es gibt halt 
eine Preview, wo ich mir das 

308
00:16:27,160 --> 00:16:30,640
ganze auch schon im 
entsprechenden Gitter brepo 

309
00:16:30,640 --> 00:16:34,640
anschauen kann, aber live wird 
das ja erst in einigen Monaten 

310
00:16:34,640 --> 00:16:36,440
werden. 
Ja oder vielleicht sogar Jahren?

311
00:16:36,440 --> 00:16:38,600
Ne, also im Moment, also die 
haben ja gesagt mit type Script 

312
00:16:38,600 --> 00:16:42,320
7 wird das live gehen, also ne 
das ist eine Entscheidung, die 

313
00:16:42,320 --> 00:16:44,880
ist getroffen das das ist der 
neue Weg für type Script. 

314
00:16:46,240 --> 00:16:48,120
Und das wird ab type Script 7 
kommen. 

315
00:16:48,120 --> 00:16:51,520
Aktuell ist glaub ich die 
Diversion 5.8 bei type Script, 

316
00:16:51,920 --> 00:16:55,200
das heißt in den nächsten 
Versionen sehen wir da erstmal 

317
00:16:55,200 --> 00:16:57,920
noch nichts von in der nächsten 
Major Version in type Script 6 

318
00:16:57,920 --> 00:17:00,560
sehen wir dann vielleicht schon 
die ersten kleineren Schritte, 

319
00:17:00,560 --> 00:17:02,560
die vielleicht in Go sind, 
vielleicht gibt es irgendwelche 

320
00:17:02,560 --> 00:17:05,359
Änderungen, irgendwelche APIS 
werden deprecated, das wird dann

321
00:17:05,359 --> 00:17:07,280
da irgendwie kommen und erst in 
type Script 7. 

322
00:17:07,640 --> 00:17:10,800
Also wahrscheinlich dieses Jahr 
nicht mehr und wahrscheinlich 

323
00:17:11,040 --> 00:17:13,079
vielleicht auch schon nächstes 
Jahr nicht mehr, wenn man sich 

324
00:17:13,079 --> 00:17:15,440
so ein bisschen den vergangenen 
Release Cycle von Timescree 

325
00:17:15,440 --> 00:17:17,599
anschaut, ist es soweit also 
noch. 

326
00:17:18,359 --> 00:17:20,560
Wie gesagt sehen wir da gar 
nichts von und wie gesagt, auch 

327
00:17:20,560 --> 00:17:23,599
noch mal wichtig bestehende Type
Script Projekte benötigen 

328
00:17:23,599 --> 00:17:26,040
ohnehin wahrscheinlich keine 
Anpassungen am Code, vielleicht 

329
00:17:26,040 --> 00:17:29,040
gibt es ganz ganz irgendwie 
edgecase AP is die dann in der 

330
00:17:29,040 --> 00:17:31,800
nächsten Version depricated 
werden und so was, aber die Idee

331
00:17:31,800 --> 00:17:34,000
ist natürlich, dass bestehende 
Type Script Projekte einfach so 

332
00:17:34,000 --> 00:17:37,480
weiter gepflegt werden können, 
jetzt nur deutlich performanter 

333
00:17:37,480 --> 00:17:39,760
sind, weil dieser neue Compiler,
der beeinflusst eben 

334
00:17:39,760 --> 00:17:42,240
hauptsächlich die 
Geschwindigkeit dieses Type 

335
00:17:42,240 --> 00:17:46,800
Script Kompilierungs oder 
Transpilierungsprozesses da. 

336
00:17:47,680 --> 00:17:50,240
Time Script zu Java Script 
transportiert wird, bleibt die 

337
00:17:50,240 --> 00:17:52,400
Funktionalität des generierten 
Codes. 

338
00:17:52,560 --> 00:17:55,200
Die bleibt ja komplett 
unverändert, also nur diese 

339
00:17:55,360 --> 00:17:58,400
diese Performance im Bild, die 
wird deutlich schneller. 

340
00:17:59,040 --> 00:18:02,400
Und einen weiteren Vorteil, den 
wir als Developer sehen werden, 

341
00:18:02,400 --> 00:18:06,120
ist, dass einfach auch die 
Sprachunterstützung in unserer 

342
00:18:06,120 --> 00:18:08,960
Entwicklungsumgebung die meisten
werden wir als Code verwenden, 

343
00:18:09,200 --> 00:18:12,080
schneller geladen wird. 
Da muss ja der entsprechende 

344
00:18:12,080 --> 00:18:14,960
Language Service, wenn ich mein 
Projekt öffne, durch alle meine 

345
00:18:14,960 --> 00:18:17,600
Dateien durchgehen, das ganze 
analysieren, damit ich dort die 

346
00:18:17,600 --> 00:18:21,200
Editor Unterstützung habe, dass 
ich dort mit den entsprechenden 

347
00:18:21,200 --> 00:18:24,320
Shortcuts und Kontextmenüs durch
mein Projekt durchspringen kann,

348
00:18:24,320 --> 00:18:27,600
dass die Referenzen stimmen, 
dass ich genau auch von dieser 

349
00:18:27,600 --> 00:18:28,920
Typsicherheit und den 
Referenzen. 

350
00:18:29,000 --> 00:18:32,880
Grenzen profitieren kann und 
natürlich auch solche 

351
00:18:32,880 --> 00:18:35,880
Sprachunterstützung, wie wenn 
ich irgendwelche Fehler mache, 

352
00:18:35,880 --> 00:18:38,560
dass das dann entsprechend 
unterstrichen wird, also alle 

353
00:18:38,560 --> 00:18:43,360
diese nativen Editor 
Unterstützung, die wenn ich die 

354
00:18:43,600 --> 00:18:47,520
Touchscreen Unterstützung in WS 
Code installiert habe nutzen 

355
00:18:47,520 --> 00:18:50,680
kann, wird jetzt auch schneller,
das heißt wenn ich ein Projekt 

356
00:18:50,680 --> 00:18:54,160
lade wird hier auch noch mal die
Performance verbessert bis dann 

357
00:18:54,160 --> 00:18:56,560
die entsprechende 
Sprachunterstützung für mich zur

358
00:18:56,560 --> 00:18:58,640
Verfügung steht. 
Genau, schneller und auch 

359
00:18:58,640 --> 00:19:02,000
weniger Ressourcenhungrig. 
Guter developer Freund von mir, 

360
00:19:02,000 --> 00:19:05,600
Sebastian, Wenn du zuhörst Liebe
Grüße hat n sehr sehr 

361
00:19:05,600 --> 00:19:08,520
beeindruckendes aber auch 
riesengroßes Type Script Projekt

362
00:19:08,520 --> 00:19:11,920
an dem er arbeitet und verliert 
da regelmäßig die Unterstützung 

363
00:19:11,920 --> 00:19:15,840
von der IDE WEIL der Language 
Server einfach aufgibt. 

364
00:19:16,120 --> 00:19:18,560
Also der Language Server, das 
ist ein kleiner Server, der 

365
00:19:18,560 --> 00:19:21,680
läuft lokal im Hintergrund, der 
übersetzt eben für die IDI, die 

366
00:19:21,680 --> 00:19:24,160
Programmiersprache und was man 
da gerade irgendwie sieht in 

367
00:19:24,160 --> 00:19:27,320
eine API und in Befehle, das 
ist, dass die ID quasi abfragen 

368
00:19:27,320 --> 00:19:29,600
kann. 
Hey was ist der Code korrekt, 

369
00:19:29,600 --> 00:19:32,160
was sehe ich denn hier, wo ist 
denn die Referenz zu diesem 

370
00:19:32,400 --> 00:19:35,200
Objekt und so weiter und der 
gibt teilweise auf oder 

371
00:19:35,200 --> 00:19:37,920
verbraucht so viel Speicher bei 
diesen riesengroßen Projekten, 

372
00:19:38,240 --> 00:19:40,640
dass der Compiler und der 
Language Server einfach gar 

373
00:19:40,640 --> 00:19:43,200
nicht mehr nachgekommen sind. 
Und der hat dann irgendwie so n 

374
00:19:43,200 --> 00:19:44,560
bisschen im Dunkeln 
programmiert. 

375
00:19:44,560 --> 00:19:47,280
Also der hat teilweise ne Datei 
aufgemacht und keine 

376
00:19:47,280 --> 00:19:49,680
Unterstützung mehr von der I 
dafür bekommen oder eben sehr 

377
00:19:49,680 --> 00:19:53,040
sehr spät, weil ein riesiges 
Projekt kompiliert oder 

378
00:19:53,720 --> 00:19:56,320
transpiliert müsst. 
Ihr müsst ihr entschuldigen, 

379
00:19:56,320 --> 00:19:58,360
wenn wir manchmal kompiliert und
manchmal transpiliert sagen, es 

380
00:19:58,360 --> 00:20:01,760
ist n Compiler ganz ganz 
offiziell kompilierter, aber 

381
00:20:01,760 --> 00:20:04,320
nicht in von type Clear of 
Javacle, sondern man das 

382
00:20:04,320 --> 00:20:07,280
Transpilieren ihr wisst aber was
wir meinen. 

383
00:20:07,600 --> 00:20:10,360
Genau und ne für dafür. 
Für diese bessere ähnliche 

384
00:20:10,360 --> 00:20:12,400
Performance ist wirklich ein 
realer Case, gerade in diesen 

385
00:20:12,400 --> 00:20:14,840
großen Projekten. 
Und das coole für uns ist, dass 

386
00:20:14,840 --> 00:20:18,160
wir von diesen zahlreichen 
Benefits profitieren können, 

387
00:20:18,160 --> 00:20:20,520
ohne dass wir irgendwas an 
unseren Anwendungen ändern 

388
00:20:20,520 --> 00:20:22,960
müssen. 
Und wir hatten es ja gerade 

389
00:20:22,960 --> 00:20:26,880
erwähnt, dass diese 
Implementierung in Go semantisch

390
00:20:26,880 --> 00:20:29,920
identisch ist zu der Type Script
Implementierung, das heißt an 

391
00:20:29,920 --> 00:20:33,200
der Art und Weise, wie unser 
Code dann von Type Script in 

392
00:20:33,200 --> 00:20:36,040
Java Script übersetzt wird, 
ändert sich nichts, das heißt, 

393
00:20:36,040 --> 00:20:39,120
am Ende sollte dort. 
Der gleiche Java Script Code 

394
00:20:39,120 --> 00:20:43,520
rauskommen wie vorher, aber mit 
besserer Performance, höherer 

395
00:20:43,520 --> 00:20:46,720
Geschwindigkeit und damit 
natürlich auch einen niedrigeren

396
00:20:46,720 --> 00:20:48,800
Ressourcenverbrauch. 
Das heißt, immer wenn ich so 

397
00:20:48,800 --> 00:20:51,520
einen Kompilierungsvorgang 
durchführe, entweder auf meiner 

398
00:20:51,520 --> 00:20:54,880
lokalen Maschine, während ich 
entwickel, oder natürlich 

399
00:20:54,880 --> 00:20:59,320
irgendwie in meiner ci, dann 
kann ich dort entsprechend Zeit 

400
00:20:59,320 --> 00:21:00,800
und Ressourcen sparen. 
Genau. 

401
00:21:00,800 --> 00:21:02,600
Gerade wenn ich jetzt irgendwie 
keine Ahnung meine. 

402
00:21:02,600 --> 00:21:05,000
Git of actions pipeline da 
irgendwie habe, dann spare ich 

403
00:21:05,000 --> 00:21:06,960
ja wirklich bares Geld dadurch, 
dass das schneller geht. 

404
00:21:07,400 --> 00:21:08,600
Vor allem, dass es parallel 
funktioniert. 

405
00:21:08,600 --> 00:21:10,320
Das ist ja einer der großen 
Benefits und diesem neuen 

406
00:21:10,320 --> 00:21:13,360
Compiler, dass eben Dateien, die
keine Abhängigkeit aufeinander 

407
00:21:13,360 --> 00:21:16,320
haben, auch parallel zueinander 
transferiert werden können, und 

408
00:21:16,640 --> 00:21:18,240
da spart man am Ende ja bares 
Geld. 

409
00:21:20,160 --> 00:21:23,520
Eine Frage, die noch so ein 
bisschen offen ist, aber und wo 

410
00:21:23,520 --> 00:21:27,400
es auch noch keine so richtige 
Antwort zu gibt, ist, wie sieht 

411
00:21:27,400 --> 00:21:31,280
es denn jetzt aus mit der Welt, 
die schon angefangen hat, Hype 

412
00:21:31,280 --> 00:21:33,960
Script nativ zu unterstützen? 
Ich hätte ja mal gesagt, ich 

413
00:21:33,960 --> 00:21:37,480
hatte ja Angangs gesagt. 
Eigentlich wird Type Script 

414
00:21:37,480 --> 00:21:39,880
nirgendwo so richtig nativ 
ausgeführt, sondern immer vorher

415
00:21:39,880 --> 00:21:42,320
in Java Script kompiliert. 
Für diese ganze Welt ändert sich

416
00:21:42,320 --> 00:21:45,920
gar nichts, aber es gibt A für 
den bestehenden Type Script 

417
00:21:45,920 --> 00:21:48,800
Compiler schon Erweiterungen, 
die natürlich auch in Type 

418
00:21:48,800 --> 00:21:51,440
Script geschrieben sind und b 
viel viel spannender. 

419
00:21:52,680 --> 00:21:55,680
Es gibt die ersten Projekte und 
die ersten Browser die 

420
00:21:55,680 --> 00:21:58,480
angefangen haben, Type Script 
Code einfach zu akzeptieren, 

421
00:21:58,480 --> 00:22:01,000
weil sie ihn ja entweder. 
Theoretisch gar auch anfangen 

422
00:22:01,000 --> 00:22:05,440
können, direkt zu direkt zu 
interpretieren oder im Zweifel 

423
00:22:05,680 --> 00:22:09,280
ja selber einfach kurz diesen 
compile Prozess machen können, 

424
00:22:09,440 --> 00:22:12,480
weil der Type scrip Compiler 
eben auch in type Script, also 

425
00:22:12,480 --> 00:22:16,000
in Java Script vorliegt und ich 
dadurch quasi in wenn ich eh 

426
00:22:16,000 --> 00:22:19,040
schon in einer Webumgebung bin 
oder in Note JS zum Beispiel 

427
00:22:19,040 --> 00:22:21,200
bin, dass ich dass mein Note JS 
Server einfach sagt, ich 

428
00:22:21,200 --> 00:22:24,640
akzeptiere type Script Code, 
weil entweder ich kann den 

429
00:22:24,640 --> 00:22:26,640
vielleicht sogar sogar selber 
lesen oder ich. 

430
00:22:27,160 --> 00:22:30,200
Kompilier den einmal beim beim 
beim Starten, weil ich kann ja 

431
00:22:30,200 --> 00:22:32,640
javascript Anwendungen ausführen
und der der Touchscriptpiler ist

432
00:22:32,640 --> 00:22:35,920
eine javascript Anwendung. 
Also diese Welt ist natürlich 

433
00:22:35,920 --> 00:22:39,840
ein bisschen nischig, aber die 
ist natürlich schon betroffen 

434
00:22:39,840 --> 00:22:42,720
von dieser Änderung, das wird 
wahrscheinlich die 99% der 

435
00:22:42,720 --> 00:22:46,800
Developer die Hierzuhören nicht 
betreffen, aber theoretisch muss

436
00:22:46,800 --> 00:22:49,360
man sich dafür natürlich 
irgendwie auch ne ne Lösung 

437
00:22:49,360 --> 00:22:54,960
überlegen und jetzt ist es ja 
natürlich so, dass Go sehr 

438
00:22:55,200 --> 00:22:58,960
kompatibel zu Web Assembly ist 
und Web Assembly auch im Browser

439
00:22:58,960 --> 00:23:00,840
laufen kann. 
Das heißt theoretisch wenn ich 

440
00:23:00,840 --> 00:23:03,680
sage, ich möchte diesen 
Transplillierungskompilierungsprozess

441
00:23:03,680 --> 00:23:06,000
auch im Browser machen, könnte 
ich das auch, danach müsste das 

442
00:23:06,000 --> 00:23:08,640
aber mit einer anderen 
Technologie machen, also da gibt

443
00:23:08,640 --> 00:23:10,800
es halt einfach so ein bisschen 
Reibung oder halt bei den 

444
00:23:10,800 --> 00:23:14,640
Erweiterungen für den für den 
Type Skip Compiler, den alten. 

445
00:23:14,720 --> 00:23:16,960
Wie lange wird der überhaupt 
noch irgendwie verfügbar sein, 

446
00:23:16,960 --> 00:23:18,680
werden die eine Zeit lang 
parallel arbeiten und ich kann 

447
00:23:18,680 --> 00:23:20,720
mir einen aussuchen, das ist 
aber so ein bisschen so ein 

448
00:23:21,040 --> 00:23:22,720
bisschen Reibung die das 
erzeugt. 

449
00:23:23,160 --> 00:23:28,400
Aber wie gesagt, das sind ganz 
spezielle Use Cases und dadurch,

450
00:23:28,800 --> 00:23:31,520
dass ja theoretisch der alte 
Compiler weiter funktionieren 

451
00:23:31,520 --> 00:23:34,560
sollte, weil ich meinen Code ja 
nicht anpassen muss, sehe ich da

452
00:23:34,560 --> 00:23:38,440
auch keine riesengroßen 
Implikationen von kann ja sagen,

453
00:23:38,440 --> 00:23:40,280
wenn ich typescript ausliefere, 
dann nehme ich halt den alten 

454
00:23:40,280 --> 00:23:43,120
Compiler, wenn ich selber dass 
das type Script in meinem Server

455
00:23:43,120 --> 00:23:46,400
irgendwie kompilieren möchte, 
das sollte ja weiterhin möglich 

456
00:23:46,400 --> 00:23:49,120
sein und sonst? 
Es wird ja seit Jahren 

457
00:23:49,120 --> 00:23:51,360
versprochen, dass Web Assembly 
das nächste große Ding ist. 

458
00:23:52,080 --> 00:23:55,520
Vielleicht trifft das dann ja 
bis, bis der finale Timeship Go 

459
00:23:55,520 --> 00:23:59,080
Compiler da ist auch irgendwann 
mal ein und dann vielleicht löst

460
00:23:59,080 --> 00:24:00,600
sich das Problem ja von ganz 
alleine auf. 

461
00:24:00,960 --> 00:24:03,920
Ja, ich glaub zusammenfassend 
lässt sich sagen, dass die 

462
00:24:03,920 --> 00:24:08,240
Änderungen, die da in der mache 
sind für diejenigen, die mit 

463
00:24:08,240 --> 00:24:10,400
Touchscreed arbeiten, dann in 
Zukunft. 

464
00:24:10,800 --> 00:24:12,800
Viele Vorteile mit sich bringen 
werden. 

465
00:24:12,800 --> 00:24:15,480
Das Ganze wird schneller, 
weniger ressourcenhungrig, man 

466
00:24:15,480 --> 00:24:19,200
kann auf größeren Projekten 
performanter arbeiten, ohne dass

467
00:24:19,200 --> 00:24:22,600
wir irgendwie signifikante 
Nachteile in Kauf nehmen müssen.

468
00:24:22,600 --> 00:24:25,840
Das Ganze läuft unter der Haube,
ich kann einfach meinen 

469
00:24:25,840 --> 00:24:30,960
aktuellen Code weiterentwickeln 
und kann dann von diesen neuen 

470
00:24:31,760 --> 00:24:35,520
Performance Verbesserungen 
entsprechend profitieren. 

471
00:24:36,480 --> 00:24:39,440
Mich würde interessieren, wie 
viele von euch, die ihr 

472
00:24:39,440 --> 00:24:44,000
irgendwie mit Web und Java 
Script Entwicklung zu tun haben,

473
00:24:44,640 --> 00:24:48,960
mit Type Script arbeiten und wie
viele von euch mit Java Script 

474
00:24:48,960 --> 00:24:51,520
direkt, also gar nicht typisiert
arbeiten. 

475
00:24:51,520 --> 00:24:55,600
Wir werden eine kleine Umfrage 
auch unter die Folge bei Spotify

476
00:24:55,920 --> 00:24:59,000
packen, mich würde das 
interessieren, wie verbreitet 

477
00:24:59,000 --> 00:25:03,040
letzten Endes Type Script bei 
Denjenigenjenigen ist, die uns 

478
00:25:03,120 --> 00:25:06,360
zuhören in meinem Umfeld, egal 
mit wem ich. 

479
00:25:06,440 --> 00:25:11,280
Spreche alle, die irgendwie Web 
machen, sind eigentlich alle auf

480
00:25:11,280 --> 00:25:15,440
Type Script mittlerweile und 
sind einfach damit sehr 

481
00:25:15,440 --> 00:25:18,840
zufrieden, weil sie damit halt 
größere, komplexere Projekte 

482
00:25:18,840 --> 00:25:20,120
besser managen. 
Schon so ein. 

483
00:25:20,120 --> 00:25:22,960
Paar? 
Vielleicht ja, aber. 

484
00:25:22,960 --> 00:25:25,120
Vielleicht ist es wirklich nur 
so ein bisschen meine meine 

485
00:25:25,120 --> 00:25:28,240
Bubble, die natürlich auch sehr 
stark aus der dieser 

486
00:25:28,240 --> 00:25:32,280
objektorientierten, häufig C. 
Sharp orientierten Welt kommen 

487
00:25:32,280 --> 00:25:34,160
und die sich dementsprechend 
natürlich mit einer. 

488
00:25:35,360 --> 00:25:38,320
Typisierten Sprache wie Type 
Script Wohler fühlen gerade bei 

489
00:25:38,320 --> 00:25:41,400
diesen größeren Projekten und 
von daher würde mich sehr 

490
00:25:41,400 --> 00:25:44,000
interessieren, wie das hier bei 
unseren Hörerinnen und Hörern 

491
00:25:44,000 --> 00:25:45,680
aussieht. 
Ja, voll, weil wir kommen ja 

492
00:25:45,680 --> 00:25:47,120
auch beide. 
Wir sind auch beide beruflich 

493
00:25:47,120 --> 00:25:49,840
auch eher bei großen Projekten, 
großen Firmen unterwegs und 

494
00:25:49,840 --> 00:25:51,920
gerade da ist dann natürlich die
Benefit Sun Type Script 

495
00:25:51,920 --> 00:25:53,840
irgendwie höher, als wenn ich in
so einem Hobbyprojekt da 

496
00:25:53,840 --> 00:25:55,120
irgendwie selber was 
zusammenbastel. 

497
00:25:55,120 --> 00:25:57,520
Aber selbst in meiner Browser 
Extension, der wirklich einfach 

498
00:25:57,680 --> 00:26:00,400
wahrscheinlich keine 300 Zeilen 
Java Script Code ist. 

499
00:26:01,080 --> 00:26:02,880
Da habe ich ja auch irgendwie 
angefangen, das mit Java Script 

500
00:26:02,880 --> 00:26:05,080
zu bauen und dann mich trotzdem 
noch mal am Ende für für Time 

501
00:26:05,080 --> 00:26:08,360
Script entschieden. 
Also ich finde das bin überall 

502
00:26:08,400 --> 00:26:10,760
benefits, ich bin aber auch ein 
Kind von objektorientierter 

503
00:26:10,760 --> 00:26:13,360
Programmierung vielleicht wenn 
ich mich davon los sagen könnte,

504
00:26:13,360 --> 00:26:16,360
würde mir das auch erliegen, 
deswegen auch ich bin sehr sehr 

505
00:26:16,360 --> 00:26:19,200
gespannt was ihr sagt wenn das 
irgendwie nicht in die Umfrage 

506
00:26:19,200 --> 00:26:20,240
passt. 
Hinterlasst auch sehr gerne 

507
00:26:20,240 --> 00:26:24,320
einen Kommentar auf youtube auf 
Spotify wo auch immer ihr uns 

508
00:26:24,320 --> 00:26:26,200
hört wenn man da Kommentare 
hinterlassen kann, wir lesen 

509
00:26:26,200 --> 00:26:29,200
immer alles fleißig und 
versuchen auch zu kommentieren. 

510
00:26:29,960 --> 00:26:33,160
Ansonsten wie immer, wenn euch 
die Folge gefallen hat, wenn ihr

511
00:26:33,160 --> 00:26:35,360
das spannend fandet, lasst uns 
gerne gute Bewertungen da. 

512
00:26:35,680 --> 00:26:37,080
Wir freuen uns auch immer sehr, 
wenn ihr uns einen Kaffee 

513
00:26:37,120 --> 00:26:39,560
ausgibt oder wenn ihr zu eurem 
eigenen Kaffee die passende Nerd

514
00:26:39,560 --> 00:26:42,600
Tasse in unserem Shop findet. 
Links zu beiden findet ihr in 

515
00:26:42,600 --> 00:26:44,080
der Beschreibung von der Podcast
Folge. 

516
00:26:44,080 --> 00:26:47,440
Und wir packen vielleicht noch 
das ein oder andere Video in die

517
00:26:47,440 --> 00:26:51,520
Show Notes, wenn ihr noch tiefer
in das Thema einsteigen möchtet,

518
00:26:51,520 --> 00:26:55,200
inklusive dem offiziellen Video 
von anders halsberg, wo er das 

519
00:26:55,200 --> 00:26:58,720
ganze noch mal aus seiner 
Perspektive erläutert. 

520
00:26:59,080 --> 00:27:01,560
Bis dahin alles Gute schreibt, 
viel Code schreibt vor allem 

521
00:27:01,560 --> 00:27:04,200
viel Time Script Code, weil der 
wird ja bald in einer rasenden 

522
00:27:04,200 --> 00:27:05,920
Geschwindigkeit in Java Script 
umgewandelt. 

523
00:27:06,640 --> 00:27:09,200
Ansonsten hören wir uns in 2 
Wochen wieder der To do 

524
00:27:09,440 --> 00:27:12,320
Developer Podcast erscheint 
nämlich alle 2 Wochen jeden 

525
00:27:12,320 --> 00:27:16,640
zweiten Montag, bis dahin habt 
ne gute Zeit bis dann tschau.