Type Script wird zehnmal schneller, zumindest der
Compiler, weil er gerade in diesem Moment von Type Script in
Go portiert wird. Anders Heilsberg der Papa von
Type Script hat das letzte Woche in einem Blogspot angekündigt
und beeindruckende Performance Gewinne gezeigt, was das für uns
als Developer bedeutet, besprechen wir in dieser Folge.
Und damit herzlich Willkommen zu Folge 111 des To do die Spell of
Podcasts Yeah mit Robin Manuel Thiel und mir malte Lantin Robin
Manuel, wie geht's dir heute? Ja Hi malte, mir geht's gut.
Ich hab die letzten Tage wieder ein altes Hobby, was ich nie
irgendwie richtig zu Ende gebracht habe aufgemacht und wir
reden ja heute über type Script, über type Script denke ich auch
immer ein bisschen an Typing, also tippen auf der Tastatur und
wir hatten das letzte Mal schon gesagt.
Ich hab dir schon mal davon erzählt, dass wir mal ne Folge
dazu machen. Hör mal, hör mal hin ist.
Das ein neues Keyboard oder übst du wieder?
Das ist ein altes Keyboard mit neuen Switches.
Und hör mal diesen. Diesen Thorx hat man, wenn sich
das schön weich anfühlt wie auf Moos.
Ich bin wieder im Keyboard Game, ich bin ich hab immer noch das
Gefühl ich brauch ein geileres Keyboard, immer wenn ich
irgendwie so youtube Videos sehe, die Leute haben so geile
Keyboards, klingen so geil für mich ist eher der Klang und ich
komm ja von so nem. Von so einem Keyboard, das finde
ich auch irgendwie gut. Also so ein flaches Keyboard und
diese richtig großen mit diesen dicken Tasten, die haben mir
irgendwie nicht getaugt, habe ich auch 1 hier, aber da machen
wir mal eine eigene Folge zu, aber jetzt bin ich wieder im Low
Profile Clicky Keyboard Game, aber halt nicht mit diesen
Klickigen Switches, sondern mit linearen Switches und irgendwie
ist das so ein bisschen so ein Nerd Ding, dann kannst du die
Tasten da so rausziehen und dann kannst du da die die Switches
rein reinpacken und dann klingt das schön und dann kannst du die
da selber belegen und. Ist ja auch beruhigend, ne, aber
vielleicht können wir ja mal so eine ASMR folge machen, wo du
irgendwie mitfährst Tipps und wir dürfen alle zuhören.
Und dann flüstern wir die ganze Folge lang nur.
Der war Geflosternd und getestet wird anstrengend okay.
Komm mal so, sorry, kurz bin ich durchgegangen.
Ja, kein Problem. Wir freuen uns ja, wenn wir an
deinen kleinen Alltagsfreuden teilhaben können.
Und ja, von daher können wir uns schon mal auf die Folge
vorbereiten, wo du uns dann die Instant Out deines Keyboard
Games mit uns teilst. So, aber jetzt wollen wir wieder
zu den zu den Themen hier. Wir wollen über Type Script und
Go sprechen und bevor wir einsteigen wie immer natürlich n
ganz herzliches Dankeschön an alle, die uns seit der letzten
Folge Kaffee spendiert haben, natürlich fleißig genutzt haben
um den in Code und Podcast folgen umzuwandeln.
Und da müssen wir einmal Death Boys danken für 5 Kaffee und
Thomas danken für 3 Kaffee ganz, ganz ganz ganz lieben Dank an
euch beide. Herzlichen Dank.
Wenn auch ihr, sagt Ey, das ist ein cooler Podcast, würden den
Jungs auch gerne einen Kaffee ausgeben, dann freuen wir uns da
immer sehr, sehr, sehr, sehr drüber.
Ganz ganz ehrlich auch überall die Jahre, immer immer wie ein
kleines Kind, wenn jemand wenn wir diese E Mail bekommen und
sagen, Hey jemand hat den hat uns einen Kaffee spendiert, dann
findet ihr einen Link unten zu bei mir Coffee in den Shownotes.
Und damit lass uns in die Folge der Woche einschränken.
Das ist ein ganz neues Announcement, ich glaube, der
blogspot kam vor ein paar Tagen erst, als anders Halsberg
angekündigt hat, dass eine große Überarbeitung von Type Script
stattfindet und es wird nicht die Sprache an sich
überarbeitet, sondern es wird die ja die quasi darunter
liegende Infrastruktur überarbeitet, nämlich der Type
Script Compiler und der in der Idee laufende Language Service.
Und mit diesen neuen Implementierungen wird das ganze
massiv schneller und da wollen wir mal heute ein bisschen drauf
eingehen, was eigentlich da die Hintergründe sind und warum auch
anders Halsberg, der auch lange an C.
Sharp mitgearbeitet hat, sich dafür entschieden hat, mit
seinem Team jetzt das Ganze neu zu implementieren, und zwar
nicht in in Anführungsstrichen der Microsoft Sprache.
C. Sharp, sondern Ingo für
diejenigen, die es nicht wissen anders Halsberg arbeitet bei
Microsoft seit vielen Jahren und hat damit hat in dem in der
Funktion Type Script quasi erfunden.
Er hat mit seinem Team die Sprache entwickelt, die Idee
dieser Sprache die Typsicher zu entwickeln, ist aber letzten
Endes in Standard Java Script. Transpediert wird und damit in
jeder herkömmlichen Java Script Runtime, sprich im Browser oder
auch auf dem Server genutzt werden kann und dementsprechend
ist natürlich anders halsberg auch eine Koryphäe, so in dieser
ganzen Welt der Entwicklungssprachen.
Ja, absolut. Also wenn das einer ankündigt,
dann schon dann schon eher als ich habe es ja immer im Intro
schon gesagt, der Papa von Type Script, der hat es so ein
bisschen erfunden. Weil ich ganz kurz gar nichts
mit typescript anfangen kann. Also es ist, ich glaub Java
Script ja den meisten die davon was sagen, das ist eigentlich
die Standardsprache um Logik vor allem in Webanwendungen und im
Browser zu beschreiben und auszuführen ist eine
Skriptsprache, deswegen heißt es auch Java Script, wird also auch
ganz klassisch gar nicht kompiliert, irgendwie auf Byte
Code runter, sondern immer vom Browser oder von einer anderen
Runtime wie zum Beispiel no js interpretiert und dann
ausgeführt und. Java Script ist sehr, sehr
einsteigerfreundlich, hat aber dann, also das kommt aber zu
einem Preis, das ist vor allem der einem vor allem dann auf die
Füße fällt, wenn man in großen Projekten und Teams arbeitet.
Java Strip hat nämlich keine Typsicherheit, das heißt, eine
Variable kann alles sein und kann auch den Typen während der
Laufzeit ändern, das heißt, ich kann irgendwie sagen, war Name
ist gleich und dann halt irgendein String malte.
Und ich kann, kann, aber kann aber sein, dass irgendeine
Funktion und ich habe dann auf einmal da ne Zahl draus macht
und wenn ich dann da an diese Zahlen n String dranhängen will,
kann das funktionieren. Kann auch manchmal sein, dass es
dann irgendwie n Fehler gibt, weil ich dann 2 Strings nicht
addieren kann und das ist ne hat manchmal einfach so n paar
Nebeneffekte und gerade in großen Projekten fällt einem das
auf die Füße und deswegen hat vor einigen Jahren jetzt schon
eben besagte anders heizberg Type Script erfunden, das ist im
Prinzip sieht das sehr sehr ähnlich aus zu Java Script Code,
hat aber halt die Endung Punkt TS in den Dateien und nicht
Punkt JS. Und nimmt eigentlich javascript
und fügt Javascript diesen Typ Support hinzu, den man eben auch
von typisierten Sprachen wie Java selber zum Beispiel kennt.
Und da die Browser aber zumindest damals noch alle
nichts mit Type Script anfangen konnten, hat sich an das
Heizbecken n Trick überlegen gesagt.
Man kann zwar in type Script programmieren, Type Script
selber wird aber niemals ausgeführt, sondern wird immer
in javascript umgewandelt, weil das konnten ja schon alle ne, da
gab es sowohl no JS wenn ich auf dem Server oder auf meinem
Computer hier irgendwie diesen Code ausführen möchte.
Oder halt der Browser selber als Runtime für Java Script.
Das heißt immer ein Zwischenschritt in der Type
Script Programmierung ist in die Kommandozeile TSC einzugeben,
das steht für Type Script Compiler und der geht eben hin,
nimmt meinen ganzen Type Script Code, umwandelt in den Java
Script um, sodass ich am Ende Java Script als Produkt
ausliefern kann und auch gar nicht ist auch gar nicht mehr
vorher relevant, ob ich es vielleicht mit type Script
beschrieben habe. Das heißt, Typesript selber
findet eigentlich nur während der Entwicklung wegen der
während der Programmierung statt ausgeführt wird typesript aber
eigentlich nie. Es gibt jetzt noch 23 Ausnahmen,
weil es auch schon jetzt ein paar Jährchen alt ist.
Typesript aber eigentlich nie und dieser Compiler, also dieser
Schritt von Type Script auf Java Script kommen, der nennt sich
Transpilieren, weil nicht wirklich kompiliert wird, der
eigentlich eher übersetzt, und der ist jetzt, na jetzt noch
nicht, aber der wird jetzt gerade, es gibt erste Demos, 10
mal schneller. Weil anders Halsberg eben mit
seinem Team hingegangen ist und hat wir portieren diesen
Compiler in Go und das ist ganz spannend.
Der Compiler selber, der ist auch schon in Type Script
geschrieben und das fällt einem manchmal bei sehr großen
Projekten auch auf die Füße, weil der nicht wahnsinnig
performant ist. Dieser Umwandlungsprozess, und
der wird jetzt schneller. Ja, und das ist genau das
Stichwort. Sehr große Projekte, es werden
ja immer größere Projekte auch in Type Script.
Und damit in Webtechnologien entwickelt.
Und auch die populärste Entwicklungsumgebung, die wir
heutzutage haben, für Webprojekte, aber auch
zahlreiche andere Projekte, nämlich Visual Studio Code, ist
in Type Script entwickelt, ist eigentlich eine Webapplikation.
Die in Touchscreen entwickelt ist.
Und da hab ich irgendwie anderthalb Millionen Lines of
Code, das ist ne richtig große Anwendung und bei diesen großen
Anwendungen, da ist es natürlich wichtig, dass wenn ich an so
einer großen Anwendung arbeite, dass dann natürlich gerade so
eine Übersetzung auch schnell und performant ist.
Aber auch wenn ich an kleineren Applikationen arbeite, habe ich
ja in in der Regel diesen Tab Script Compiler im Hintergrund
laufen, damit ich meine Anwendung irgendwie auch auf dem
zweiten Fenster eine Webanwendung vielleicht mir
anschauen kann, während ich da dran entwickel oder auch im
Debugging. Und da ist natürlich Performance
entscheidend. Ich möchte halt nicht immer
irgendwie so einen Bildvorgang laufen lassen bei meiner
üblichen kleinen Webapplikation, die ich vielleicht als
Hobbyprojekt mache, kommt das vielleicht nicht ganz so zu
tragen, also. Aber wenn ich jetzt große
Applikationen habe, dann ist das natürlich n signifikanter
Unterschied, ob ich jetzt am Beispiel von VS Code irgendwie
anderthalb Minuten warte, bis das Ganze kompiliert ist oder
mit dieser neuen Implementierung des Compilers nur knapp unter 10
Sekunden und damit wirklich diese.
Beschleunigung um den Faktor 10 sehe und das macht dann
natürlich auch schon in der Entwicklungszeit einen
Unterschied. Genau.
Und das ist nicht nur Visual Studio Code, ne, das natürlich
ist so ein bisschen das Beispiel, weil es einfach so die
Haus und Hof IDE oder der Editor von Microsoft eben ist, aber man
konnte das eben auch mit anderen Projekten schon nachweisen,
diesen Performancegewinn, der ist immer so im Durchschnitt,
also dass dieser neue Type Script go Compiler um den Faktor
10 schneller ist. Und ne wie malte gerade schon
gesagt hat, ne mit Visual Studio Code.
Das ist ja eigentlich ne Desktop Anwendung, das heißt die basiert
auf Electron, das ist n Framework wo ich mit
webtechnologien Apps für den den Computer oder das Smartphone
schreiben kann und das zeigt auch eigentlich wie wie weit
verbreitet diese Technologien sind und wie groß dieser Impact
ist und entsprechend viel Resonanz gab es dann eben auch
in der Community dazu, dass als jetzt angekündigt wurde, dass
dieser Type Script Compirer eben in Go portiert wird.
Das Beispiel ist aus meiner Sicht auch so interessant, weil
es so n bisschen diesen in Inception loop hat.
Ne, dass ich halt irgendwie mit VS Code, welches in Type Script
geschrieben ist, an type Script arbeite und einen type script
compiler heute. Nutzer der in Type Script
entwickelt wurde. Und da kommt jetzt diese
Änderung ins Spiel und zwar wird nämlich genau dieser Compiler
jetzt aktuell übersetzt von einer Implementierung in Type
Script in eine Implementierung in Go, welche ich dann nativ für
die entsprechenden Plattformen kompilieren kann.
Ganz wichtig diese Änderung, dass der Type Script Compiler
jetzt nicht mehr selber in type Script dann geschrieben wird,
sondern in go übersetzt hat. Keine Auswirkungen auf die App,
die ihr vielleicht in Type Script schreibt.
Das heißt nicht, dass jetzt euer Code in Go statt in Java Script
Transpiliert wird, nur der Compiler und der Language Server
kommen wir gleich noch mal zu, der wird in Go in Go neu
geschrieben, das heißt, eure Anwendungen wird jetzt nicht
irgendwie morgen in Go transpiliert statt in Java
Script. Am Ende wird dadurch nicht nur
schneller, sondern das Team hat auch gesehen, dass sie.
Auch ne bessere Speichereffizienz hinbekommen
und damit auch allgemein die sonstigen Performance Kriterien
verbessern können. Und wir können ja gleich noch
mal n bisschen. Auf die anderen Technologien
eingehen, die sich das Team als Alternative angeschaut hat, weil
gerade von einem Team bei Microsoft hätte man ja
vielleicht erwartet, dass sie nicht als Erstes die Haus und
Hofsprache von Google nehmen, sondern tatsächlich irgendwas,
was auch in House bei Microsoft entwickelt wird.
Es ist ganz spannend. Also das waren auch so die
ersten Reaktionen aus der Community, warum denn go und
nicht wie C plus plus, was ja eigentlich.
Von der Performance immer noch ungeschlagen ist oder oder Rust,
was vielleicht sogar noch performanter wäre.
Ne ich mein weil theoretisch, wenn man sich jetzt irgendwie
sagt, OK wir, wir schreiben jetzt diesen Compiler neu, dann
kann man ja und und der vor allem auf auf Performance jetzt
ausgelegt sein soll, warum dann kann man sich auch anschauen,
warum schreibt man den jetzt nicht direkt in Rust, was ja
noch schneller als go ist oder in C plus plus was auch Cross
Plattform ist und noch schneller als alle zusammen sind.
Ich find es dann immer interessant, wie dann in Social
Media die Leute halt immer irgendwie sofort irgendwelche
Spekulationen anstoßen und sagen, Hey, Sie verwenden jetzt
nicht c. Sharp bedeutet das was für diese
Sprache? Heißt das, dass Microsoft nicht
mehr an C. Sharp glaubt und ich glaub da
interpretieren manchmal die ein oder anderen da zu viel rein,
weil am Ende ist es nämlich so, dass das Team sich mehrere
Technologien angeschaut hat und dann am Ende, und das ist glaub
ich aus unserer Sicht als Nutzer dieser Technologien.
Genau die richtige Entscheidung, die Sprache oder die Technologie
genommen hat, die für den Job am besten geeignet ist.
Und da kommen vielleicht auch nicht nur die Dinge zum Tragen,
die man vielleicht offensichtlich beurteilen würde.
OK, was ist die Performance, was sind die Performance Kriterien
wie Speicher, Geschwindigkeit et cetera, sondern es kommen
natürlich auch andere Kriterien, die.
Zum Tragen, wie zum Beispiel, welche Struktur hat die
Programmiersprache, welche Sprachkonstrukte gibt es, weil
auch ein Ziel bei dieser Übersetzung von Type Script
jetzt in Go war, dass die Semantik gleich bleibt, dass man
tatsächlich auch ein Äquivalent hat, wenn man dann die beiden
Implementierungen nebeneinander liegt, dass man sagt, OK, das
ist genau eine. Übersetzung der aktuellen Type
Script Implementierung in Go und Dementsprechend ändert sich
nichts an der Art und Weise, wie dieser Transpiler oder Compiler
funktioniert, sondern es ist letzten Endes einfach nur eine
andere Technologie, in der das umgesetzt wurde.
Das ist ganz wichtig, ne. Wir sind ja eben nicht auf der
grünen Wiese, wir haben ja das Team hat ja nicht gesagt, wir
schreiben den Type Script Compiler neu, sondern das heißt
sich hier ohne Import, das heißt das Ding wird portiert.
Und da ist, wie malte gerade schon gesagt hat, einfach grob
von der Struktur am ähnlichsten oder am geeignetsten für diesen
Port gewesen. Und abgesehen davon halte ich
diese ganze Diskussion auch irgendwie für so n bisschen
übertrieben. Also ich verstehe nicht, warum
die Leute jetzt irgendwie hier sagen, ja, Technologie X ist
besser oder Technologie y ist besser, wenn wir gerade um ne
wir wir reden gerade davon, dass das Ding 10 mal schneller wird
als vorher, also ob ich da jetzt ob ich das jetzt 10 oder 10 halb
mal schneller mache, indem ich noch mal ne andere Technologie
nehme. Ich weiß nicht, ob das die
Diskussion überhaupt wert ist und warum mir nicht C Sharp
gewählt wurde, ist glaube ich relativ offensichtlich.
Microsoft ist immer noch absolut committed zu C.
Sharp als Programmiersprache, aber für C.
Sharp brauche ich eben die Dotnet Runtime um den
installiert zu haben, wohingegen Go und auch Ruston C plus plus
eben in absolut alternativen Code runterkompiliert werden
können, wo ich keine eigene Runtime verbrauche und gerade
wenn es hier um ne um ne Verschlankung auch von dieser
ganzen Sache geht, dann finde ich absolut die richtige
Entscheidung, die Sie hier getroffen haben.
Und finde ich auch noch mal ein Commitment zu einer Open Source
Community, zu einer Technologieoffenheit, die auch
in denen, die natürlich super wichtig ist, gerade diesen
Kontext. Das heißt, das Team nutzt jetzt
go als Low Level Sprache, die Multithreading beherrscht und
nativ auf verschiedene Plattformen portiert werden kann
und sieht da signifikante Performance gewinne wann?
Können wir davon profitieren? Das ist ja heute noch nicht
live, ich glaube, es gibt halt eine Preview, wo ich mir das
ganze auch schon im entsprechenden Gitter brepo
anschauen kann, aber live wird das ja erst in einigen Monaten
werden. Ja oder vielleicht sogar Jahren?
Ne, also im Moment, also die haben ja gesagt mit type Script
7 wird das live gehen, also ne das ist eine Entscheidung, die
ist getroffen das das ist der neue Weg für type Script.
Und das wird ab type Script 7 kommen.
Aktuell ist glaub ich die Diversion 5.8 bei type Script,
das heißt in den nächsten Versionen sehen wir da erstmal
noch nichts von in der nächsten Major Version in type Script 6
sehen wir dann vielleicht schon die ersten kleineren Schritte,
die vielleicht in Go sind, vielleicht gibt es irgendwelche
Änderungen, irgendwelche APIS werden deprecated, das wird dann
da irgendwie kommen und erst in type Script 7.
Also wahrscheinlich dieses Jahr nicht mehr und wahrscheinlich
vielleicht auch schon nächstes Jahr nicht mehr, wenn man sich
so ein bisschen den vergangenen Release Cycle von Timescree
anschaut, ist es soweit also noch.
Wie gesagt sehen wir da gar nichts von und wie gesagt, auch
noch mal wichtig bestehende Type Script Projekte benötigen
ohnehin wahrscheinlich keine Anpassungen am Code, vielleicht
gibt es ganz ganz irgendwie edgecase AP is die dann in der
nächsten Version depricated werden und so was, aber die Idee
ist natürlich, dass bestehende Type Script Projekte einfach so
weiter gepflegt werden können, jetzt nur deutlich performanter
sind, weil dieser neue Compiler, der beeinflusst eben
hauptsächlich die Geschwindigkeit dieses Type
Script Kompilierungs oder Transpilierungsprozesses da.
Time Script zu Java Script transportiert wird, bleibt die
Funktionalität des generierten Codes.
Die bleibt ja komplett unverändert, also nur diese
diese Performance im Bild, die wird deutlich schneller.
Und einen weiteren Vorteil, den wir als Developer sehen werden,
ist, dass einfach auch die Sprachunterstützung in unserer
Entwicklungsumgebung die meisten werden wir als Code verwenden,
schneller geladen wird. Da muss ja der entsprechende
Language Service, wenn ich mein Projekt öffne, durch alle meine
Dateien durchgehen, das ganze analysieren, damit ich dort die
Editor Unterstützung habe, dass ich dort mit den entsprechenden
Shortcuts und Kontextmenüs durch mein Projekt durchspringen kann,
dass die Referenzen stimmen, dass ich genau auch von dieser
Typsicherheit und den Referenzen.
Grenzen profitieren kann und natürlich auch solche
Sprachunterstützung, wie wenn ich irgendwelche Fehler mache,
dass das dann entsprechend unterstrichen wird, also alle
diese nativen Editor Unterstützung, die wenn ich die
Touchscreen Unterstützung in WS Code installiert habe nutzen
kann, wird jetzt auch schneller, das heißt wenn ich ein Projekt
lade wird hier auch noch mal die Performance verbessert bis dann
die entsprechende Sprachunterstützung für mich zur
Verfügung steht. Genau, schneller und auch
weniger Ressourcenhungrig. Guter developer Freund von mir,
Sebastian, Wenn du zuhörst Liebe Grüße hat n sehr sehr
beeindruckendes aber auch riesengroßes Type Script Projekt
an dem er arbeitet und verliert da regelmäßig die Unterstützung
von der IDE WEIL der Language Server einfach aufgibt.
Also der Language Server, das ist ein kleiner Server, der
läuft lokal im Hintergrund, der übersetzt eben für die IDI, die
Programmiersprache und was man da gerade irgendwie sieht in
eine API und in Befehle, das ist, dass die ID quasi abfragen
kann. Hey was ist der Code korrekt,
was sehe ich denn hier, wo ist denn die Referenz zu diesem
Objekt und so weiter und der gibt teilweise auf oder
verbraucht so viel Speicher bei diesen riesengroßen Projekten,
dass der Compiler und der Language Server einfach gar
nicht mehr nachgekommen sind. Und der hat dann irgendwie so n
bisschen im Dunkeln programmiert.
Also der hat teilweise ne Datei aufgemacht und keine
Unterstützung mehr von der I dafür bekommen oder eben sehr
sehr spät, weil ein riesiges Projekt kompiliert oder
transpiliert müsst. Ihr müsst ihr entschuldigen,
wenn wir manchmal kompiliert und manchmal transpiliert sagen, es
ist n Compiler ganz ganz offiziell kompilierter, aber
nicht in von type Clear of Javacle, sondern man das
Transpilieren ihr wisst aber was wir meinen.
Genau und ne für dafür. Für diese bessere ähnliche
Performance ist wirklich ein realer Case, gerade in diesen
großen Projekten. Und das coole für uns ist, dass
wir von diesen zahlreichen Benefits profitieren können,
ohne dass wir irgendwas an unseren Anwendungen ändern
müssen. Und wir hatten es ja gerade
erwähnt, dass diese Implementierung in Go semantisch
identisch ist zu der Type Script Implementierung, das heißt an
der Art und Weise, wie unser Code dann von Type Script in
Java Script übersetzt wird, ändert sich nichts, das heißt,
am Ende sollte dort. Der gleiche Java Script Code
rauskommen wie vorher, aber mit besserer Performance, höherer
Geschwindigkeit und damit natürlich auch einen niedrigeren
Ressourcenverbrauch. Das heißt, immer wenn ich so
einen Kompilierungsvorgang durchführe, entweder auf meiner
lokalen Maschine, während ich entwickel, oder natürlich
irgendwie in meiner ci, dann kann ich dort entsprechend Zeit
und Ressourcen sparen. Genau.
Gerade wenn ich jetzt irgendwie keine Ahnung meine.
Git of actions pipeline da irgendwie habe, dann spare ich
ja wirklich bares Geld dadurch, dass das schneller geht.
Vor allem, dass es parallel funktioniert.
Das ist ja einer der großen Benefits und diesem neuen
Compiler, dass eben Dateien, die keine Abhängigkeit aufeinander
haben, auch parallel zueinander transferiert werden können, und
da spart man am Ende ja bares Geld.
Eine Frage, die noch so ein bisschen offen ist, aber und wo
es auch noch keine so richtige Antwort zu gibt, ist, wie sieht
es denn jetzt aus mit der Welt, die schon angefangen hat, Hype
Script nativ zu unterstützen? Ich hätte ja mal gesagt, ich
hatte ja Angangs gesagt. Eigentlich wird Type Script
nirgendwo so richtig nativ ausgeführt, sondern immer vorher
in Java Script kompiliert. Für diese ganze Welt ändert sich
gar nichts, aber es gibt A für den bestehenden Type Script
Compiler schon Erweiterungen, die natürlich auch in Type
Script geschrieben sind und b viel viel spannender.
Es gibt die ersten Projekte und die ersten Browser die
angefangen haben, Type Script Code einfach zu akzeptieren,
weil sie ihn ja entweder. Theoretisch gar auch anfangen
können, direkt zu direkt zu interpretieren oder im Zweifel
ja selber einfach kurz diesen compile Prozess machen können,
weil der Type scrip Compiler eben auch in type Script, also
in Java Script vorliegt und ich dadurch quasi in wenn ich eh
schon in einer Webumgebung bin oder in Note JS zum Beispiel
bin, dass ich dass mein Note JS Server einfach sagt, ich
akzeptiere type Script Code, weil entweder ich kann den
vielleicht sogar sogar selber lesen oder ich.
Kompilier den einmal beim beim beim Starten, weil ich kann ja
javascript Anwendungen ausführen und der der Touchscriptpiler ist
eine javascript Anwendung. Also diese Welt ist natürlich
ein bisschen nischig, aber die ist natürlich schon betroffen
von dieser Änderung, das wird wahrscheinlich die 99% der
Developer die Hierzuhören nicht betreffen, aber theoretisch muss
man sich dafür natürlich irgendwie auch ne ne Lösung
überlegen und jetzt ist es ja natürlich so, dass Go sehr
kompatibel zu Web Assembly ist und Web Assembly auch im Browser
laufen kann. Das heißt theoretisch wenn ich
sage, ich möchte diesen Transplillierungskompilierungsprozess
auch im Browser machen, könnte ich das auch, danach müsste das
aber mit einer anderen Technologie machen, also da gibt
es halt einfach so ein bisschen Reibung oder halt bei den
Erweiterungen für den für den Type Skip Compiler, den alten.
Wie lange wird der überhaupt noch irgendwie verfügbar sein,
werden die eine Zeit lang parallel arbeiten und ich kann
mir einen aussuchen, das ist aber so ein bisschen so ein
bisschen Reibung die das erzeugt.
Aber wie gesagt, das sind ganz spezielle Use Cases und dadurch,
dass ja theoretisch der alte Compiler weiter funktionieren
sollte, weil ich meinen Code ja nicht anpassen muss, sehe ich da
auch keine riesengroßen Implikationen von kann ja sagen,
wenn ich typescript ausliefere, dann nehme ich halt den alten
Compiler, wenn ich selber dass das type Script in meinem Server
irgendwie kompilieren möchte, das sollte ja weiterhin möglich
sein und sonst? Es wird ja seit Jahren
versprochen, dass Web Assembly das nächste große Ding ist.
Vielleicht trifft das dann ja bis, bis der finale Timeship Go
Compiler da ist auch irgendwann mal ein und dann vielleicht löst
sich das Problem ja von ganz alleine auf.
Ja, ich glaub zusammenfassend lässt sich sagen, dass die
Änderungen, die da in der mache sind für diejenigen, die mit
Touchscreed arbeiten, dann in Zukunft.
Viele Vorteile mit sich bringen werden.
Das Ganze wird schneller, weniger ressourcenhungrig, man
kann auf größeren Projekten performanter arbeiten, ohne dass
wir irgendwie signifikante Nachteile in Kauf nehmen müssen.
Das Ganze läuft unter der Haube, ich kann einfach meinen
aktuellen Code weiterentwickeln und kann dann von diesen neuen
Performance Verbesserungen entsprechend profitieren.
Mich würde interessieren, wie viele von euch, die ihr
irgendwie mit Web und Java Script Entwicklung zu tun haben,
mit Type Script arbeiten und wie viele von euch mit Java Script
direkt, also gar nicht typisiert arbeiten.
Wir werden eine kleine Umfrage auch unter die Folge bei Spotify
packen, mich würde das interessieren, wie verbreitet
letzten Endes Type Script bei Denjenigenjenigen ist, die uns
zuhören in meinem Umfeld, egal mit wem ich.
Spreche alle, die irgendwie Web machen, sind eigentlich alle auf
Type Script mittlerweile und sind einfach damit sehr
zufrieden, weil sie damit halt größere, komplexere Projekte
besser managen. Schon so ein.
Paar? Vielleicht ja, aber.
Vielleicht ist es wirklich nur so ein bisschen meine meine
Bubble, die natürlich auch sehr stark aus der dieser
objektorientierten, häufig C. Sharp orientierten Welt kommen
und die sich dementsprechend natürlich mit einer.
Typisierten Sprache wie Type Script Wohler fühlen gerade bei
diesen größeren Projekten und von daher würde mich sehr
interessieren, wie das hier bei unseren Hörerinnen und Hörern
aussieht. Ja, voll, weil wir kommen ja
auch beide. Wir sind auch beide beruflich
auch eher bei großen Projekten, großen Firmen unterwegs und
gerade da ist dann natürlich die Benefit Sun Type Script
irgendwie höher, als wenn ich in so einem Hobbyprojekt da
irgendwie selber was zusammenbastel.
Aber selbst in meiner Browser Extension, der wirklich einfach
wahrscheinlich keine 300 Zeilen Java Script Code ist.
Da habe ich ja auch irgendwie angefangen, das mit Java Script
zu bauen und dann mich trotzdem noch mal am Ende für für Time
Script entschieden. Also ich finde das bin überall
benefits, ich bin aber auch ein Kind von objektorientierter
Programmierung vielleicht wenn ich mich davon los sagen könnte,
würde mir das auch erliegen, deswegen auch ich bin sehr sehr
gespannt was ihr sagt wenn das irgendwie nicht in die Umfrage
passt. Hinterlasst auch sehr gerne
einen Kommentar auf youtube auf Spotify wo auch immer ihr uns
hört wenn man da Kommentare hinterlassen kann, wir lesen
immer alles fleißig und versuchen auch zu kommentieren.
Ansonsten wie immer, wenn euch die Folge gefallen hat, wenn ihr
das spannend fandet, lasst uns gerne gute Bewertungen da.
Wir freuen uns auch immer sehr, wenn ihr uns einen Kaffee
ausgibt oder wenn ihr zu eurem eigenen Kaffee die passende Nerd
Tasse in unserem Shop findet. Links zu beiden findet ihr in
der Beschreibung von der Podcast Folge.
Und wir packen vielleicht noch das ein oder andere Video in die
Show Notes, wenn ihr noch tiefer in das Thema einsteigen möchtet,
inklusive dem offiziellen Video von anders halsberg, wo er das
ganze noch mal aus seiner Perspektive erläutert.
Bis dahin alles Gute schreibt, viel Code schreibt vor allem
viel Time Script Code, weil der wird ja bald in einer rasenden
Geschwindigkeit in Java Script umgewandelt.
Ansonsten hören wir uns in 2 Wochen wieder der To do
Developer Podcast erscheint nämlich alle 2 Wochen jeden
zweiten Montag, bis dahin habt ne gute Zeit bis dann tschau.