Revision 581: TypeScript 5.2

Transcript

[0:00] JavaScript beziehungsweise TypeScript führen das Using-Schlüssel dort ein.

Revision 581: TypeScript 5.2

https://workingdraft.de/581/

[0:06] Und mit Using kann man Bindings, also Variablen, deklarieren, die über ein explizites Ressourcenmanagement verfügen.
Ich hatte ja vor ein paar Wochen, war ich ja ganz übel krank und lag wirklich fiebrig da nieder und mein bescheuertes Gehirn dachte sich, das ist die ideale Gelegenheit, eine JavaScript-Library zu schreiben.
Hat's dann auch gemacht. Und leider ist das Ding auch relativ nützlich, sodass ich's benutzen muss.
Wenn gleich die Code-Qualität ungefähr dem entspricht, was du da so unter dem Fieberwahn ausmalen kannst.

[0:34] Music.

[0:59] Working Draft Revision 581, Diese Revision von Working Draft wird euch präsentiert von Hörerinnen und Hörern wie euch.
Auf patreon.com slash workingdraft könnt ihr uns ein paar Euro in den Hut werfen.
Aus euren Beiträgen und unseren gelegentlichen Werbeeinnahmen bezahlen wir allerleite eure Software-Abos und das Honorar unserer Audio-Producerin.
Wenn ihr euch auch beteiligen wollt, könnt ihr das unter patreon.com slash workingdraft sehr gerne machen.
Wir danken euch tausendfach für die Unterstützung und fürs weitere Zuhören.
Hallo und herzlich willkommen zu Working Draft Revision 581. Heute ist an Bord der Stefan.
Hallo.
Meine Wenigkeit, der Peter. Und das kann nur eins heißen, Nämlich bei Mike und schaff das mal wieder, was passiert.

[1:45] Ich seh schon wieder, was passiert. Na ja, einmal im Quartal, ne?
Ja, Timescope hat sich mal wieder ein Update geleistet.
Und wir wollen unter anderem, wie immer, über die drei, vier, eins interessanten Features reden, die es da so drin gibt.
Und, ähm, Stefan, du wolltest mit einem anfangen.
Ja, genau, also, äh, gleich ganz oben. Wir haben jetzt sehr viel über Sinn und Unsinn von Features gesprochen.
Und jetzt ist ein Feature rausgekommen, es gibt ein Ectoscript-Proposal dazu, von dem ich, also das ich gerne ein bisschen spitzfindiger diskutieren möchte.
Das glaube ich sofort. Ich hatte mir gedacht, dass du dich darauf stürzen würdest.
Ja, ja, also das ist gleich das Erste. Also man muss ja ganz ehrlich sagen, es ist wahrscheinlich auch das weitreichendste Feature, was in diesem Release drin ist. Zumindest schätze ich das einmal, weil ich habe mir den Rest nicht ganz im Detail angeschaut.
Aber es geht um die Using Declarations, das explizite Ressourcenmanagement.

[2:38] Tatsächlich führt JavaScript und somit auch Typescript, das ist immer diese Dualität, Typescript ist die erste Referenzimplementierung von Features, die in JavaScript noch auch erscheinen, JavaScript bzw. Typescript führen das Using-Schlüssel dort ein und mit Using kann man Bindings, also Variablen, deklarieren, die über ein explizites Ressourcenmanagement verfügen.
Explizites Ressourcenmanagement bedeutet, dass du nicht nur ein Objekt oder eine Instanz oder was auch immer für eine Struktur erstellen kannst, sondern auch beim Aufräumen du sicherstellen kannst, dass du diverse Aufräumarbeiten erledigst.
Das Beispiel, das Sie dort geschrieben haben, ist, dass du zum Beispiel sagst, du öffnest eine Datei im Node.js-Filesystem und sowie dieser File-Handle verschwindet, wird auch die Datei geschlossen beziehungsweise wird die Datei gelöscht, wenn das jetzt deine Idee ist.
Genau mit Anlink werden die Suchen gelöscht.
Und das Problem ist jetzt das, wenn du jetzt davon ausgehst, dass diese Dateien auch immer gelöscht werden, hast du das Problem, was ist, wenn du einen Early Exit hast oder irgendwo ein Fehler geworfen wird und so weiter.
Du hast in JavaScript nicht die Möglichkeit, dass du sagst, hey, egal was passiert, bitte schmeiß alle Sachen am Ende weg oder bitte führ diese Destructor-Tätigkeiten aus, zu dem Zeitpunkt, wo dieses Objekt weggeschmissen wird.

[4:01] Ja, du kannst ja schon ganz viele Try-Catches aneinander verschachteln, wenn du möchtest.
Genau, und Binary-Blöcke und solche Sachen, die werden immer ausgeführt am Ende.
Das kannst du schon machen, nur ist es halt wie immer nur so gut, wie du halt als Entwicklerin oder Entwickler auch bist. Das ist ein bisschen eine AP-Frage, wenn jetzt zum Beispiel so ein Objekt zur Verfügung steht für so einen temporären Fall und ich mache da ein Klasse-Grundherum. Gehe, ich von meinen Nutzerinnen und Nutzern aus, dass die nachher wissen, wie sie aufräumen oder mache ich das? Und wenn ich das mache, zu welchem Punkt mache ich das? JavaScript löst das so und das finde ich eigentlich eine sehr elegante Lösung. JavaScript führt das Dispose-Symbol ein. Also Symbols sind ja Möglichkeiten, dass du bei Klassen und Objekten diverse Accessoires hast, die zum Beispiel mit dem JavaScript direkt verbunden sind. Zum Beispiel ist es das Iterator-Symbol, wo du eine Generator-Funktion dahinter hast, mit der du neue Items rausjagen kannst und damit ist dann deine Klasse mit jeder For-Loop kompatibel.
Das sind quasi Magic Keys für Sprachprotokolle, damit man sich andocken kann an Konstruktionen wie InstanceOfKeyword, ForOfLoop und so weiter.
Genau, und ToStringTag, also was du in der Object-Object rausschmeißen willst, sondern Object dein Name, dann kannst du den ToStringTag verwenden. Also du hast da so kleine Hooks, mit denen du deine Klassen und Objekte eben kombinierst mit dem, was schon vorhanden ist.

[5:27] Und sie haben das Dispose-Symbol eingeführt, wo du sagst, in der Aufräumaktion führ bitte diese Schritte aus.
Das heißt, da kannst du nachher so Dinge machen wie Datei schließen, Datei löschen, wenn das jetzt deine Idee ist.
Das finde ich super, das finde ich cool.
Also ich verstehe, dass man sowas braucht und wenn man da wirklich eine elegante API machen möchte, dann kann man das gerne mit dem Dispose-Symbol machen, finde ich spitze.

[5:51] Das Spannende ist aber jetzt das, und das habe ich jetzt nicht ganz verstanden, warum man das braucht, dass es für Dinge, die das Post-Symbol ausführen möchten beim Aufräumvorgang, gibt es jetzt dieses das Using Keyword. Und das Using Keyword sagt, hey, das Post wird am Scope-Ende nachher aufgerufen.

[6:12] Also man führt neben Kunst wahr und lädt ein weiteres Deklarationssymbol ein oder Deklarationsschlüsselwort ein und sagt, passt, Scope Ende, sprich geschlungene Klammer zu, jetzt räumt zusammen und schließt das Ganze. So weit, so gut. Warum brauche ich das? Warum macht das nicht der Garbage Collector für mich? Der Garbage Collector müsste am Ende von dieser geschlungene Klammer sowieso drauf kommen, dass dort keine weiteren Zugriffe mehr auf das Spanning gibt und die Aufnahmearbeit durchführen. Also simpel ja, aber warum brauche ich eigene Schlüsselwerte?
Was sage ich der VM dadurch, was sage ich den Compiler dadurch? Das kapiere ich.
Das kann ich dir sagen. Der Garbage Collector garantiert dir nicht, dass ab Scope-Ende sofort das Objekt verschwindet, sondern nur, dass ab Scope-Ende niemand darauf zugreifen kann und dass es dann irgendwann verschwindet. Weil es gibt ja zum Beispiel auch die Finalization Registry, Ich weiß nicht, ob du mit der mal zu tun hattest.
Nö, glaub ich nicht. Das dachte ich auch, ich hab nämlich zuletzt erst, wie zum allerersten Mal, ernsthaft für eine Demo verwendet.
Finalization Registry ist im Prinzip ein Mechanismus, um auf ein Objekt einen Callback draufzusetzen on garbage collected.

[7:24] Und der wird dann halt eben ausgeführt, wenn das Objekt dann eingesammelt wird.
Die Finalization Registry hält nur eine schwache Referenz auf das betroffene Objekt natürlich.
Und dann kriegst du das eben. Und daran kannst du sehr gut nachvollziehen, der Garbage-Collector bei Objekten in JavaScript teilweise erst relativ spät greift.
Der wird während erwartet wieder mal einen Garbage-Collection-Zyklus machen und fertig, ne?
Genau, genau. Also, ne, das ist halt das eine. Das andere ist halt eben auch, dass so Sachen wie Garbage-Collection ist ja gar nicht Gegenstand der ECMAScript-Spezifikation.
Da wird ja nicht festgelegt, wie einer zu funktionieren hat, sondern nur, dass es einen zu geben hat und wie die dann das organisieren.
Da gibt's ja verschiedenste Möglichkeiten, das zu machen. Und man kann ja irgendwie so, wie nennt man das dann, so, dass man die Objekte in Generationen einteilt, irgendwie die kurzlebigen und die langlebigen, die checkt man halt seltener.
Das ist alles in der Implementierung freigestellt, sodass du tatsächlich, wenn du wirklich die Garantie geben willst, in der Sprache, dass, wenn Scope ende, dann werden diese Funktionen ausgeführt, die das Disposen machen.
Dann brauchst du dafür ein neues Sprachkonstrukt, weil die Garbage Collection macht das nicht.
Wenn man bessere Garbage-Kollektoren braucht.

[8:37] Nee, du bräuchtest keine besseren, du bräuchtest einen einheitlichen.
Ja, vielleicht das. Okay.
Und das kannst du natürlich machen, aber dann musst du den Leuten wieder vorschreiben, wie ihre ECMA-Skript-Implementierung aussieht und das tust du halt normalerweise nicht.
Ja, aber das ging doch da mit dem Using-Keyword wie Garbage-Collector-Vorschreibung mit extra Schritten.
Im Grunde sagt man ja damit, hey, okay, das Copy ist am Ende, schmeiß' weg.
Und das könnte ja ein super Default sein, eigentlich.

[9:04] Ja, ähm, glaube ich nicht, es, ähm... Also ich weiß, wie du auf die Idee kommst, dass es gefälligst einfach automatisch zu funktionieren hat.
Da gibt es ja noch so eine andere Programmiersprache, mit der du dich jetzt wieder mal befasst.
Ja, da ist eigentlich das Gang und Geben. Also da ist ja, gesprungene Gammel bedeutet, Ressourcen werden frei.
Genau. Das funktioniert eigentlich relativ gut.
Aber ich kenne mich jetzt ja in Rust, das ist die Programmiersprache, von der wir reden, die ja tatsächlich genauso funktioniert wie der Stefan, das jetzt gerade sozusagen sich für JavaScript erträumt hat.
Da muss man nicht beischreiben, wann was eingesammelt werden soll.
Da hat man keinen Garbage-Collector, sondern einfach der Compiler findet automatisch raus durch Betrachten des Codes und der Typen, wie langlebig ein Objekt ist.
Dann kann er dir garantieren, dass du keine Memory-Leaks hast.
Aber was er dir auch garantiert, ist, dass das Debuggen teilweise ein bisschen mühsamer wird.
Weil man muss eben da sehr komplizierte Typen alle so organisieren und so zusammenstecken, dass es auch funktioniert und für die Maschine verständlich ist.

[10:01] Aber Rust funktioniert doch, stand jetzt, wenn ich mich nicht täusche, quasi wie ein Produkt.
As in, das gibt es einmal.
Es gibt eine Rust-Implementierung und es gibt nicht irgendwie eine Spezifikation dafür, ist das so?
Es gibt mittlerweile eine Spezifikation und es gibt schon zwei Implementierungen.
Es gibt eine, die auf den GCC hinzielt und eine, die auf die LLVM hinzielt.
Okay. Das gibt es mittlerweile schon und es wird gerade eine Spezifikation für den Automotive-Sektor erarbeitet, Also für Rast in kritischen Umgebungen, das ist das Ferro-Scene, wo auch festgelegt wird, wie sich der Compiler zu verhalten hat in dieser Situation.
Damit ganz klar wird, das ist das Ergebnis, das wir erwarten.
Okay. Ist das so ... Ich muss ganz ehrlich sein. Okay.
Aber dann würde ich ja trotzdem annehmen, dass wegen der ganzen Garantien, die das beinhaltet, eben sehr genau beschrieben ist, wie sich tatsächlich am Ende auf der Ebene der Nullen und Einsen die ganze Mechanik verhält.
Wann da was Garbage Collected wird oder freigegeben wird oder verwendbar ist oder nicht, ne?
Und das ist halt eben bei den ECMAScript-Spezifikationen so komplett anders.
Ich hab aus Gründen der Vorbereitung für einen heißen Herbst voller Advanced-JavaScript-Workshops mich da so reingefressen in so diverse, wirklich mal ECMAScript-Spezifikationen lesen und Zeug.

[11:29] Und da steht wirklich nicht drin, wie irgendwas zu funktionieren hat. Null.
Da wird immer nur beschrieben, wir haben hier irgendwelche abstrakten Operationen deklariert und die am Ende beschreiben ein beobachtbares Verhalten, aber es ist an keiner Stelle irgendein Wort darüber verloren, wie etwas am Ende implementiert zu sein hat. Null.
Und das ist halt der ganze Geist, der da drinnen atmet. Und insofern ist halt eben diese Explicit Resource Management mit dem Using-Keyword tatsächlich eine Ausnahme, wo man halt eben wirklich generell sagt, dieser Effekt muss passieren, wenn diese Syntax so und so evaluiert ist.
Aber das ist eben nicht auf die gesamte Sprachmechanik Collection ausgedehnt.
Und deswegen würde das, also man müsste im Prinzip die Spezifikationen neu schreiben und einfach einen komplett anderen Ansatz wählen, nämlich den, wo wirklich, wie bei irgendwie C oder was ähnlichem, wirklich vordefiniert wird, wie am Ende sich das im Null und Einsen ausprägt.
Und das sehe ich halt nicht kommen. Das war ja, glaube ich, auch das Problem, was wir gehabt haben mit der Modulsyntax, dass die einmal komplett umsetzungsfrei entschieden worden ist, weil man sonst nicht weitergekommen wäre.

[12:36] Ja, gut, da ist das noch eine etwas gröbere Granularität, wegen der Browser-Node.js-Dualität, die man ja de facto hat.
Weil du kannst ja nicht sagen, wie ein Modul geladen wird, weil du ja nicht mal weißt, ob du als JavaScript-Engine in einem Browser, auf einem Server oder weiß Gott wo existierst.
Also, du kannst nicht irgendwie sagen, lade eine Datei, weil Datei gibt's ja gegebenenfalls konzeptionell nicht mal.
Dann bin ich aber gespannt zum Beispiel, ob das Using-Keyword jetzt...
Also was das für einen Einfluss hat auf die Objekte, die erzeugt werden.
Ob die vielleicht sogar am Stack erzeugt werden und nachher weggeschmissen werden.
Und ob ich das auch für Dinge verwenden kann, die kein Dispose-Symbol verwenden.
Also wirklich als Alternative zu LED-Kunst-Waren.

[13:22] Also, du... Okay. Das habe ich jetzt natürlich nicht nachgelesen, was passiert, wenn du irgendwie so using 42 machst.
Das habe ich jetzt natürlich auch nicht auf dem Zettel. Aber die Frage ist, warum würdest du?
Also damit ich gleich Dinge wegschmeißen kann, wo ich mir denke, okay, das ist viel zu groß.
Ah, da musst du, glaube ich, dein Rust-Gehirn da fahren lassen und wieder sagen, der Garbage Collector, der macht das schon.
Ja, aber das würde ich generell gerne sagen, der Garbage Collector macht das schon. Warum brauche dann unbedingt dieses Usen-Keyword.
Ist mir ja gut, ob das jetzt später aufgeschlüsselt wird oder nicht.
Weil das halt eben nicht Garbage Collection ist. Du willst halt von Usen eine Garantie haben, dass wenn Scope Ende Sachen passieren.
Und beim Garbage Collector hast du die Garantie, die Finalization Registry, du kannst das ja damit umsetzen, wenn du willst. Aber das würde halt eben bedeuten, dass die Datei halt irgendwann geclosed wird. Und dieses irgendwann könnte halt eben auch bedeuten, Nutzer macht beim Browser oben das X.
Und das sind alles so Sachen, die willst du nicht haben.
Du kannst es halt eben schon dem Garbage-Collector überlassen, weil der halt eben andere Dinge für dich managt, weil wenn wir jetzt mal die Existenz eines Garbage-Collectors voraussetzen, dann weißt du halt eben nicht, wann der läuft und du musst halt eben deinem System ein Stück weit vertrauen, dass er das halt zu irgendwelchen möglichst optimalen Zeitpunkten in guter Portionierung macht.
Und für sowas wie ein User Interface, wo ich am Ende einfach nur ein paar Buttons anklicke, ist das ja okay.
Das ist halt eben nicht eine Automotive-Rust-Echtzeitanwendung.

[14:45] Nee, ich versteh. Ich fühl sie trotzdem nicht richtig. Nee.
Und ich meine, es passt halt auch so ein bisschen zu dem, was du so ganz zu Beginn sagtest in unserer sogenannten Vorbesprechung, weiß Gott, wo die hingeschnitten wird.
Als du so gesagt hast, TypeScript wird das neue C++ durch diese vielen, vielen Sachen, die da so drin sind.
Weil genau daran hab ich halt eben auch gedacht.
Ich meine, in der Ankündigung da bei TypeScript, da machen sie ja im Prinzip das Szenario auf mit ihrer temporären Datei, die du am Ende nicht hinkriegst zu schließen oder exceptions, oder vergessen, oder was nicht allem. Und das ist ja noch die klassische Kritik an C++, dass man halt eben eine sehr große Kanone auf seinen Fuß richtet und dann ist vorbei. Und, als Gegenargument kommt dann von den C++-Freunden immer, ja, haha, aber hier im allerneuesten Standard gibt es dieses spezielle Sprachmittel und wenn du das verwendest, dann ist diese Fußkanone entschärft. Aber sie existiert immer noch, das ist das Problem. Die Fußkanone ist halt eben noch Und du kannst halt eben, wenn du, wenn du vorsichtig bist und umsichtig bist, dann verwendest du halt das neue Sprachmittel, womit das halt eben nicht mehr passiert.
Allein, das ist ja irgendwie nicht der Punkt. Der Punkt ist ja, dass man vielleicht die Existenz einer Fußkanone per se ausschließen möchte, was ja der Rust-Ansatz ist.
Und das ist wirklich mehr so der C++-Ansatz. Wenn du alles richtig machst, geht's nicht schief, aber wenn du es falsch machst, dann geht es halt richtig schief.

[16:07] Nein, es stimmt schon. Es stimmt schon. Ich meine, das ist vielleicht auch ein bisschen, dem geschuldet, dass die Programmiersprache jetzt auch schon sehr alt ist und weiter wächst.
Ich glaube, wir haben eh wieder genau das auch in der Vorbesprechung gehabt.
Da gibt es jetzt Leute, deren Beruf ist es, JavaScript-Proposals zu schreiben.
Die werden nicht einmal zu ihrem Chef sagen und sagen, hey, ich bin fertig, wir machen bei der Sprache nichts mehr, jetzt ist es vorbei, ich gebe mir eine andere Arbeit.
Sondern die werden halt weiter Proposals machen, die werden sich weiter Features ausdenken.
Und wir sind halt dort mittlerweile in einem Punkt, wo ich mir denke, die Features, die wir jetzt haben, die sind vielleicht für gewisse Cases jetzt gut, aber sie haben jetzt nicht mehr diese Tragweite, wie wir halt damals zum Beispiel in Echmascript 6 oder so, das Spread-Syntax bekommen haben, oder das Structuring. Ich glaube, das hat viel mehr verändert, als wie jetzt dieses Simple Dispose, wo du dich halt da wirklich fragen musst, okay, wie viele Leute werden das jetzt tatsächlich einsetzen, vor allem wenn eh wirklich jeder mit einem Framework arbeitet. Vielleicht wird das Framework das verwenden.
Und soweit, während die Features immer nuancierter, das kapiere, muss man sich aber auch fragen, ob man das Feature wirklich noch irgendwie in sein Verständnis von der Programmiersprache reinziehen will.
Oder ob man jetzt sagt, im Vergleich zu C++, wir als Team entscheiden uns jetzt, dass wir dieses Subset der Sprache verwenden und mit diesem Subset der Sprache kommen wir jetzt klar.

[17:27] Ja, ob man damit klarkommt, wird sich dann eben an den Dependencies bemessen, die man sich dann reinzieht.
Also wir sind hier jetzt so der funktionale Shop und wir wollen jetzt hier definitiv hier so Klassen irgendwie voll nicht verwenden. Allein dann kommen die Web Components um die Ecke. Und ich habe ja dann schon den Fall gedacht, dass die im Laufe der Zeit so ein bisschen das Front entfressen werden und das zumindest in irgendeiner Form sicherlich mitbestimmen werden. Es wäre mal Zeit, weil sonst wäre es einfach der traurigste Webstandard, den wir je gehabt haben. Weil existieren dann ja schon seit ewig. Sie haben keine Ahnung, wie viele Iterationen schon hinter sich, aber ich seh diese Adaption davon eigentlich noch nicht. Aber vielleicht bin ich da mittlerweile verblendet.
Ach du, das hatte ich tatsächlich letztens erst, weil neben Advanced JavaScript habe ich im Herbst ganz ganz viele Next Level Web Components mit TypeScript für Workshop und da muss ich natürlich auch am Anfang erstmal den Case machen, warum würde man sich damit befassen. Jetzt suche ich in meinen Notizen natürlich, wo das ist. Aber irgendein Link, den ich da ausgegraben hatte, meinte halt irgendwie so, ja, auf 20 Prozent der Webseiten finden sich halt irgendwelche Tags, die Custom Elements sind. Also irgendwas, das ist irgendwas anderes. So, klingt mir jetzt auch noch viel. Sehe ich jetzt nicht so richtig. Viele in meinem Universum verwenden immer noch auch alle React und Angular, also div, div, div, div, div, div.

[18:47] Ne? Aber, ähm, ja. Wahrscheinlich hat's irgendwo App minus Boot.
Und das ist ein Angular-Web-Komponente, wobei 20 Prozent ist schon viel.
Ja, das glaub ich nicht. Aber ich hab den Link zu dem Zeitpunkt noch nicht genau angesehen.
Der kommt noch auf meinen großen Haufen von.

[19:06] Vielleicht der Google-Tech-Manager. Ist der ein Web-Component? Vielleicht jetzt.
So kann man's auch machen.
Wenn man die Zahl hochpushen will, wenn das ist, wonach sich deine Beförderung bemisst, Das können wir mal machen.
Nee, also, ich glaub, das Problem ist halt einfach ultra, ultra haarig, an dem sie da arbeiten.
Und ich bin ja durchaus der Meinung, dass das was wird. Es ist halt nur wirklich eine sehr undankbare Aufgabe, die ganze Legacy, die in den ganzen DOM-APIs und HTML und so drinsteckt, irgendwie nachträglich durch eine High-Level-API erklärbar zu machen.
Ja.
Also, so machst du ja nicht deinen API-Design. Du machst ja erst mal so, so soll's am Ende aussehen.
Ich bau mir irgendwie so einen Dummy und dann bau ich das Framework darunter.
Und man macht ja nicht erst irgendwelchen Low-Level-Kram, dann 20 Jahre Legacy on top und baut dann eine High-Level-API drauf, die ein konsistentes Weltbild erschaffen soll.
Das ist halt einfach die undankbarste aller Aufgaben. Klappt halt schon ganz gut, aber ...
Es wird halt irgendwann zum Problem werden für diejenigen, die sagen, ich werde niemals eine Klasse nur mit der Kneifzange anfassen.
Manche Probleme, würde ich behaupten, sind für Klassen ganz gut zu lösen.
Irgendwelche ORMs oder so gedöhnt, wenn man das verwenden möchte.

[20:19] Es ist schwierig, da irgendwie wirklich zu sagen, wir sind jetzt hier der Shop, der sich auf dieses Subset einigt.
Weil das hast du halt nicht komplett unter Kontrolle.
Du sitzt dann irgendwie auf dein Framework und plötzlich sagt dein Framework in der Version 2.0, hier ist jetzt alles anders. Und dann? Ja, ja. Das sind die harten Probleme in der Softwareentwicklung. Ja.
Ja, ich würde tatsächlich auch sagen, also was du da so beschrieben hast, von wegen so dem relativen Impact von der Spread-Syntax bis hin zu jetzt diesem Using-Symbol, da würde ich halt einfach so sagen, das ist glaube ich nicht jetzt irgendwie ein programmiersprachenspezifisches Problem, sondern einfach so der Fortschritt der Technik allgemein. Da findest du, das muss da glaube ich auch wieder. Also wenn ich jetzt mal ganz plakativ werden möchte, so die Erfindung des Rades hat sicherlich insgesamt mehr Impact gehabt, als jetzt so die Erfindung vom E-Bike, was jetzt relativ jung ist, heißt aber jetzt ja nicht, dass irgendwie ein E-Bike in den so Form der menschlichen Fortbewegungsmittel einzufügende schlechte Idee ist oder dass man irgendwie jetzt davon nicht beeindruckt sein soll oder Zeug, sondern ist halt eben einfach so eine inkrementelle Verbesserung. Daran ist jetzt ja erst mal nichts verkehrt. Ja, das ist sehr schön gesagt.

[21:29] Okay. Wollen wir zum nächsten kommen? Stichwort Klassen. Ja, bitte, das darfst du beschreiben, weil ich glaub, ich hab mir das gar nicht durchgelesen, aber es klingt ja jetzt nicht so aufregend.
Es klingt nicht aufregend, das ist, glaub ich, auch nicht so aufregend, aber es ist dringendst nötig.
Nämlich Decorator-Metadata. Worum geht's?

[21:49] Es gibt ja schon seit ewig und drei Tagen die Arbeit an Decorators.
Das heißt so mit etsyntax versehene Annotationen.
Da haben wir uns schon ewig ausgesprochen über das Thema. Genau.
Das holt uns mit jeder Typescript-Folge wieder ein.
Das ist richtig. Aber pass auf, jetzt wird's lustig.
Weil Typescript hat ja so Legacy-Decorators und unterstützt ja auch die neuen Decorators, die jetzt der aktuelle ECMA-Script-Standard sind.
Wo ich übrigens tatsächlich jetzt einen Beitrag zur Spezifikation geleistet habe.
Wo? Ja, aha.

[22:20] Ich hab mich auf Social Media aufgeregt, über was, was nicht funktionierte.
Das war echt schräg und dann habe ich das tatsächlich mal da zum Spezifikationsschreiber nach GitHub getragen und der hat dann gesagt du hast das falsch gemacht und das falsch gemacht dein Babel Plugin macht das falsch aber wenn man alles richtig macht zeigt sich dieser Fehler in den Spezifikationen den muss ich ernsthaft reparieren. Also meine Inkompetenz gepaart mit Bugs in Babel führt zu einer Verbesserung der zukünftigen Decorators Spezifikation.
Ich leiste meinen Beitrag. Evaluationsreinfolge.
Also das ist tatsächlich dafür, dass das Stage 3 ist, ist das teilweise noch ausgesprochen doll im Flux, habe ich so den Eindruck. Aber egal. Also TypeScript hat so olle Decorators. Es gibt jetzt die tollen neuen Decorators.
Die ollen Decorators hatten einen TypeScript Flag, einen Compiler Flag namens Emit Decorator Metadata.
Da haben sie dann Runtime-Typ-Informationen noch mit ausgegeben, wenn sie das Zeug evaluiert haben.
Für den Angular-Compiler, der hat das dann aufgenommen und hat so gewusst, welche Komponenten er irgendwie...
Wo er die Templates kompiliert, kompilieren sie für welche Komponenten.

[23:27] Genau, so Zeug ist das jetzt. Und jetzt gibt es für die neuen Decorators ein Feature namens Metadata.
Stefan, du darfst einmal raten, mit welcher Funktionalität dieses neue Feature nichts zu tun hat.
Mit den Metadatas vom TypeScript-Compiler. Natürlich hat das damit nichts zu tun, deswegen heißt es ja genauso.
Mhm, mhm, mhm, mhm. Also ...
Ah, wunderschön. Ach.
Oh. Und man darf halt nicht den Legacy-Kram verwenden, man muss den coolen neuen Kram verwenden, auch wenn der extrem instabil ist und selbst Honks wie ich da noch Fehler drin finden.
Der Punkt mit der neuen Metadata ist der folgende.
Du hast ja bei Decorators in den ganzen Beispielen, in Hello World und so weiter, immer relativ isolierte Use Cases.
Mach irgendwie ein Logger an das dran, die Nebenwirkung bei dem Ding, das sind alles isolierte Sachen.
Du hast selten Dinge, die zusammenarbeiten sollen. Obwohl das natürlich in der Realität wahrscheinlich so sein wird.
Also, machen wir mal die Idee von der Web-Component. Du willst einen Decorator haben, der sagt, das ist eine Klasse, die ist dekoriert mit irgendwas, das sagt, du bist unter dem HTML-Tag jetzt zu finden.
Und du hast hier einen Accessor, der ist ein Attribut, bla, bla, bla. So Zeug.
Und die müssen ja möglicherweise irgendwie miteinander arbeiten können.
Die müssen irgendwie wissen, dass sie alle auf der gleichen Klasse rumhacken, um irgendwie durch Komposition tatsächlich eine gemeinsame Wirkung zu erzielen.
Die müssen irgendwie Daten teilen. Und das geht im Moment nicht.

[24:50] Also jeder Decorator sieht nur sein eigenes isoliertes Objekt, das er dekoriert.
Klassendecorator sieht nur die Klasse und Methodendecorator sieht nur die Methode.

[25:00] Und die haben kaum eine Möglichkeit, miteinander zu reden.

[25:04] Und jetzt hast du ein Metadata-Objekt, wo du einfach Zeug reinschmeißen kannst, das du über alle Dekorator-Aufrufe trägst, oder? So sieht's aus. Okay.

[25:13] Und das ist total sinnvoll, weil du halt irgendwie so Sachen hast, also...
Ich hatte ja vor ein paar Wochen, war ich ja ganz übel krank und lag wirklich fiebrig da nieder und mein bescheuertes Gehirn dachte sich, das ist die ideale Gelegenheit, eine JavaScript-Library zu schreiben.
Hat's dann auch gemacht.
Und leider ist das Ding auch relativ nützlich, sodass ich's benutzen muss.
Wenn gleich die Codequalität ungefähr dem entspricht, was du da so dir unterm Fieberwahn ausmalen kannst.
Und es geht tatsächlich um Web Components, wo ich halt so Sachen machen möchte, wie was ich grad beschrieben hab.
Ein Decorator für eine Klasse, du bist jetzt dieses HTML-Tag.
Ein Decorator für einen Accessor, du beschreibst jetzt einfach ein Attribut.
So was ähnliches gibt's auch bei, hier, Lit, dem Web Component Framework, aber bei mir halt eben mit viel, viel weniger und mit on top lustiger Fiebersyntax.
Der Punkt ist halt der, dass man da wirklich so Dinge machen muss wie, Naja, ein Attribut muss sich irgendwie initialisieren.
Wie initialisiert sich das? Na, wenn sich die Klasse konstruiert.
Wie bringe ich den entsprechenden Callback an? Naja, gar nicht, weil der Attribut-Decorator halt einfach überhaupt keinen Kontext hat, dass er zu einer Klasse oder Instanz gehört.
Und so, wie ich das im Moment halt manage, ist, ich hab halt eben ne ganze Haufen von Weakmaps, wo die Dinger sich halt eben, sobald sie sich initialisieren, es in Instanziieren, anmelden und sagen, jo, hier, ich bin die Callback-Sammlung von dieser und jenen Instanz, Und in dem Constructor über eine injectete Mixing-Klasse kann man dann BlaKicks. Das könnte einfach alles ein Rekord sein, den die Dinger miteinander teilen.
Und genau das ist die Decorators Metadata.
Und das ist voll nötig.

[26:40] Mhm, ich verstehe das, ja. Es klingt ja ziemlich einfach. Also, du hast einfach dieses Metadata-Objekt im Kontext und kannst dort ein Property setzen, wie du lustig bist.
So sieht's aus. Ja. Und dann kannst du es sogar über ein Symbol auf der Klasse, kriegen, oder auf der Instanz. Nein, auf der Klasse.

[26:58] Ähm, ja, weil du dekorierst ja die Klassendeklaration. Und damit hat die Instanz ja per se nichts zu tun.
Also klar, wenn du immer noch Daten mit der Instanz teilen willst, dann ist sicherlich eine Weakmap mit dem This als Key immer noch der richtige Weg.
Aber für so Sachen wie, ne, die Dinger, die halt im Prinzip jede Instanz betreffen.
Wo eben gesagt wird, das sind Initialisierungscallbacks, die müssen ausgeführt werden, wenn z.B. eine Webcomponent sich connectet.
Du musst dann ja irgendwie eine Möglichkeit haben, im Connected Callback auf Daten zuzugreifen, die befüllt werden von diesen ganzen Deklarationen.
Und wir reden da noch nicht über das Timing. In welcher Reihenfolge sich was initialisiert, das macht das alles noch viel komplizierter.
Und das geht damit halt eben einfach mal alles weg.

[27:40] Weil es halt eben so den Scope gibt, der sagt so, das ist die Klasse.
Und sobald sich halt eben was konstruiert, ist die Klasse komplett evaluiert.
Und dann finde ich da alles drin, was sich dort registriert hat und kann das halt eben alles bequem ausführen.
Ohne irgendwie Timing-Probleme und lauter Verrenkungen, die ich da machen musste.
Das wird voll gut. Ja, okay, das klingt wirklich sinnvoll und brauchbar. Nötig, würde ich sagen.
Weil das halt eben, wie gesagt, die Hallo-Welt-Beispiele, die funktionieren ohne. Sobald du was Ernsthaftes bauen willst, brauchst du Kontext. Und den gab es vorher nicht oder nur unter großen Mühen und damit geht das dann viel besser. Ich bin schon gespannt, wann dieses Feature rund um die Decorators wirklich in einer populären Bibliothek aufschlägt. Das werden wir lang darüber gesprochen, dass das ja wirklich, dass man mit mit Klassen und Deckgeräten, das kann man wirklich tolle Sachen designen. Also da kann man wirklich, glaube ich, schöne, schöne Frameworks, die minimalistisch sind, machen. Ich warte nur, dass das passiert. Ich glaube, ich glaube, Peter, das musst du machen. Ich glaube, du...
Nee, nee, nee. Du kannst, du kannst dir LIT nehmen. Also wirklich LIT.dev, das ist ja die Web Component Library da. Also es hat nicht auch irgendein Google-Produkt, das demnächst eingestampft wird. Ich habe keine Ahnung. Wenn du da mal auf die Seite gehst und dir da unten das Code-Sample anschaust, das verwendet die.
Da hast du so ein Decorator-Custom-Element mit einem Tag-Namen.
Das mit einem Decorator Property für eine IDL DOM Property.

[29:05] Und das ist halt schon ganz gut. Vor allen Dingen, wenn du halt mal vergleichst, wenn das jetzt ein Attribut wäre, das ist jetzt bei denen da alles ein bisschen anders, als es bei mir ist, also von der Syntax her, von der Oberfläche her sieht das, was ich da im Fieberwahn zusammengehauen habe, genauso aus wie das, aber funktioniert schon ein bisschen anders, weil ich halt wirklich so nach den Spezifikationen gegangen bin, und da ist es halt wirklich so, wenn du sowas hast wie ein Attribut auf einer Web-Component, das ist ja irre kompliziert.
Du musst ja irgendwie aus dem String des HTML irgendwie zum Beispiel eine Zahl rausparsen, die willst du gegebenenfalls irgendwie klempen, höchstens so groß, höchstens so klein.
Du musst irgendwie mit Unter Number umgehen, du musst das irgendwie in einen Getter und Setter verpacken, du willst es vielleicht Read-Only machen, Black-X. Das ist halt monströs komplex, aber im Prinzip ja für jedes Attribut gleich.
Sodass du wirklich das machen kannst, wie hier in dem Beispiel. Du sagst einfach, es gibt ein Ding, das heißt Name, und das verhält sich wie eine, IDL-JavaScript-Property auf einem HTML-Element. Und das ganze Handling von Attribute-Change-Callbacks und Initialisierung und aus einem String parsen und zunehmende Strings serialisieren, das kannst du alles vereinheitlichen damit und dann kannst du wirklich Web-Components bauen, wo du nicht mal sagen kannst, das Äquivalent von Hand geschrieben wäre so lang, weil du würdest das nicht so schreiben, weil du wahnsinnig werden würdest und sagen würdest, das mache ich so nicht, ich nehme halt hier irgendwelche Shortcuts. Und das kann halt eben echt schon sehr, sehr nice werden und ich glaube, dieses Lit ist halt im Moment unter den Dingern, die wirklich publik sind, das, was das beste Beispiel ist, wie das aussehen kann.

[30:31] Es ist halt natürlich in dem Ding, weil es ein Framework sein will, wieder viel zu viel Scheiß noch mit drin.
Mit HTML-Renderer und DOM-Diffing und CSS und JavaScript, bla bla bla.
Das ist alles Scheiß, den keine alte Sau braucht. Aber der Kern mit den Decorators, wie sie es hier verwenden, das ist, glaube ich, genau, wie es sein kann.
Wenn man auf den ganzen Rest verzichtet.
Ja, das stimmt schon. Wie populär es liegt, kann man das irgendwie beziffern?
Äh, nö, aber ich glaube, unsere Web Component Library ist sicherlich eins der populäreren.
Es ist ja so der Nachfolger von Polymer.
Das sind ja so die Dinger, die da so...
Ja, Vorpreschen. Es ist halt immer noch so, die Developer Experience von dem ganzen Kram ist halt immer noch zu schlecht.
Ja, das mit dem steht zum Fall selber leider, guckt das gar nicht.
Ja, also das war halt eben auch so meine Überlegung mit meinem Teil, mit meinen Decorators, dass ich halt so gesagt habe, okay, ich verfolge jetzt hier den Ansatz, das zum Beispiel wirklich so zu machen, dass es in TypeScript auch gut funktioniert.

[31:32] Und das ist schon dann echt schon ziemlich kompliziert, aber das muss man halt eben, glaube ich, machen, weil sonst, Du kannst halt, also das Beispiel, was wir hier halt eben auf der Lit-Webseite haben, das ist, würde ich sagen, schon konkurrenzfähig zu Angular oder React oder so.
Das kannst du irgendwie einem Entwickler oder einer Entwicklerin aus dem Angular- oder React-Feld zeigen und die würden sagen, das ist jetzt nicht so eine arg üble Zumutung, wenn du dir das Beispiel anschaust.
Aber trotzdem hast du halt dadurch, dass das halt eben wirkliche Web-Components, wirkliche HTML-Elemente sind, da ein Layer an Komplexität noch on top, den du in React nicht hast, weil React halt keine Attribute zum Beispiel hat.
Da musst du dir nicht überlegen, wie wird was zu einem String oder aus einem String rausgepasst.
Das Problem existiert da einfach nicht. Das ist aber notwendigerweise bei Web Components als essentielle Extrakomplexität on top.
Das heißt, du hast ohnehin verloren, wenn es jetzt darum geht, die Developer Experience so gut zu machen wie React.
Das kannst du aufgrund des anderen Scopes gar nicht schaffen.

[32:29] Aber du kannst halt andere Dinge rausholen, mit denen du die Web Components vielleicht verkaufen kannst.
Zum Beispiel, funktioniert überall.
Kannst du auch in dein Angular-Projekt reinwerfen, bist nicht auf React beschränkt.
Wird bis in alle Ewigkeit halten, weil's ein Browser-Standard ist.
Trifft vielleicht weniger zu, wenn du LIT hast mit irgendwie, da musst du aus NPM irgendwie 70 Sachen installieren, aber von der Theorie könnte es halt so sein.
Und es könnte halt mit klassischen DOM-Programmiertechniken, so jQuery-Style, kombiniert werden, mit so Sachen wie Event-Delegation, das könnte ja auch in solche Decorators reingegossen werden, dass du so ein Ding hast, addListen, das Ding lauscht auf seinem Shadow DOM, und wenn da ein Klick passiert auf einem Ding, auf das der Selector matcht, dann wird diese Methode ausgeführt und so weiter.

[33:08] Das könnte also alles sein, aber es sind halt unglaublich harte, dicke Bretter, die da gebohrt werden müssen.
Verglichen zu, ich bin React, ich vereinfache meinen Scope, für mich gibt es kein HTML, ich bin nur das DOM.
Das ist einfach ein inhärenter Vorteil, den die da haben. Das Gras ist ja auch nicht so grün, wie es gern publik gemacht wird.
Du hast mit React ja da ganz anderen Schwungen Probleme drinnen.
Wir haben damals auch entschieden, dass wir React verwenden.
Der Grundführerjekt war ganz ganz einfacher, macht jeder andere. Das heißt, wir haben dort viel weniger Probleme mit Onboarding.

[33:44] Es gibt genug Komponenten draußen, Bibliotheken draußen, wo sich wirklich eine Vielzahl an Entwicklerinnen und Entwicklern.

[33:49] Daran bedienen können und wir als, Applikations-Framework-Bereitsteller müssten uns nicht darum scheren. Erstens ein sehr gutes Argument, zweitens ein Argument.
Ja, genau. Das Problem dabei ist noch das, dass du trotzdem, auch wenn React wirklich nur minimalistisch im Framework approach ist, musst du dich mit den inneren Begebenheiten der Bibliothek auseinandersetzen über kurz oder lang. Diese Schuld kriegst du nicht weg. Es kommt irgendwo der Punkt, wo die Applikation langsam wird, weil du ständig Layout-Freshen machst oder wo du eine State-Management-Lösung auswählst, die nicht zu dem passt, wie die Applikation sein soll. Du musst dich über kurz oder lang wirklich mit dem Ding beschäftigen und damit machst du ein hornistenes Dauf.
Also da merkst du nachher, dass du vom Hundertsten ins Tausendste kommst und vielleicht auch die Bibliotheken, die du verwendest, die Komponenten, die du verwendest, nicht zusammenspielen mit dem, wie du deine Applikationen strukturiert hast, wird alles sehr schwierig, wird alles sehr, sehr schwierig. Diese Probleme hast du nach wie vor und da hilft dir auch React nicht, egal wie einfach das ist. Das ist richtig, aber pass auf, für den Marketing-Pitch sind das ja irgendwelche Externalitäten, die irgendwelche anderen ausbaden müssen. Ja, aber das sind die die Probleme, die du hast, wenn du wirklich damit arbeitest.

[35:15] Ja, das muss ja keiner mitkriegen. Ich bin mir nicht gegangen, das kriegen sie halt früher oder später mit.
Glücklich der, der nach einem Projekt nach drei Wochen gehen kann und das nächste macht und sich nicht mehr über die ganzen Sachen, die er verbrochen hat, kümmern muss.
Ich würde mal sagen, das hast du vielleicht bei Webstandards, die werden schon anders gestaltet.
Die werden so gestaltet, dass du halt in dem großen ganzen Web-Ökosystem auch gut damit umgehen kannst.
Kannst. Du musst halt auch ein paar Techniken lernen, ganz klar, aber das weißt du dann auch schon. Also die Sachen haben ja eine Langlebigkeit dahinter und die sind auch inspiriert von dem, was schon da war und solche Sachen. Von dem her denke ich mir, das ist vielleicht gar nicht so schlecht.
Es ist trotzdem der schwerste Weg, den man beschreiben kann.

[36:07] Meine Meinung zu React hat sich ja sehr stark konkretisiert, als ich letztens mal an einem JSF-Projekt ein bisschen Legacy-Beratung machen durfte.
Du armer Mensch, ja.
Na ja, ich meine, Codebase. Ich war dann derjenige, der nach so drei Wochen und so hier, damit könnt ihr die dringendsten Feuer austreten, sagen konnte, guten Tag, noch viel Spaß, ich mach jetzt was anderes.
Mir geht's gut. Ich hab nur das Zeug aufgemacht, hab so dieses XML-Zeug gesehen mit irgendwelchen Komponentennamen, die nix mit HTML zu tun haben, mit irgendwelchen On-Click-Geschichten.
Und dachte so, ach, das ist genau wie React, das kenn ich.
Und weißt du, was es ist? Es ist genau wie React, und das kenn ich. Ja, ja.
Ja, genau. Es ist die gleiche Idee. Du machst halt einfach ein, du machst Tabula rasa und sagst, ich mach jetzt hier einen neuen Überbau.
Der Überbau war halt eben da bei dem JSF-Java-XML-Gebimsel. Wir machen alles in XML, wir haben Komponenten, die sind da drin implementiert.
Wir haben auch so Sachen wie UI-Frameworks und so was. genau da ist es halt nur eine andere Darreichungsform, aber die gleiche Idee.
Und hinterher hast du genau die gleichen Probleme.
Nämlich, es ist viel zu viele Abstraktionsschichten. Wie kriege ich diese einfache Sache jetzt zum Funktionieren?
Und du kämpfst irgendwann einfach gegen das Framework an.

[37:18] Und auch das ist einfach wirklich so ein Pattern, das man dann einfach wiederkehrend sieht.
Also genau der Scheiß, auf den ich keinen Bock habe. Weswegen ich vielleicht sage, Web Component, okay, muss man vielleicht irgendwie mehr Energie reinstecken, aber vielleicht lohnt es sich irgendwie auf lange Sicht.
Unter der Voraussetzung, dass du für die lange Sicht daran interessiert bist.
Wenn deine Perspektive ist, ich bin da Startup, und wenn ich in zwei Jahren nicht die Kiste am Laufen habe, dann ist sowieso Feierabend Mai.
Dann nimmst du Next.js, Material.UI und dann nach mir die Sintflut.
Das ist dann der richtige Approach. Nur, das sind halt nicht alle.
Das sind halt nicht viele.
Ja, na, absolut. Also, bei mir ist halt auch der Anspruch jetzt der, möchte ich in einem halben Jahr wieder aufmachen können und weiter daran arbeiten.

[38:00] Also, das sind meine Hobbyprojekte zum Beispiel. Die haben halt, da arbeite ich mal in die Ferien ein, zwei Wochen dran, dann tut sich lange nichts und dann möchte ich wieder hingehen und das Problem ist meistens, dass ich dann nichts mehr kompilieren kann, weil sich das Ökosystem in irgendeiner Richtung bewegt hat und ich nicht nachher rennen kann.
Also, das sind auch Probleme.
Ja, muss man ja nicht haben. Man kann sich ja dazu entscheiden.
Man muss ja nicht komplett runter auf Stom gehen. Aber man kann ja vielleicht wirklich sagen, weniger Libraries, weniger Dependencies, weniger fanzige Framework.
Ich schreib mal ein paar Sachen mehr. Ich hab ja den Eindruck, manche da draußen haben ernsthaft eine Code-Allergie.
Die wollen so wenig tippen wie möglich, aber so viel npm install tippen wie möglich. Ja, ja, das stimmt.
Und vielleicht ist ja gar nicht so schlecht, wenn so Sachen, ich mein, das predige ich, glaube ich, jetzt hier auch nicht zum ersten Mal, aber so Sachen wie die Dinge, mit denen die Nutzer interagieren, so das User Interface, mit dem, was so die unmittelbare Erfahrung meines Produkts ist.
Wenn ich das nicht vielleicht zu 100% aus der Hand gebe.

[38:58] Ist das vielleicht eine Idee? Schaffe ich einen Wert in meiner Firma, der da drin bleibt, egal wie der Framework- und Design-Wind sich da grade dreht?
Ja, das sehe ich genauso. Ich möchte jetzt was fragen. Wollen wir noch ein paar Features durchgehen, die grad so in dieser TypeScript ...
Im TypeScript-Release drinnen sind? Oder sind die eh wohl eher so nett?
Ich find, zwei können wir erwähnen.
Ja. Die nächsten zwei?
Äh ... äh, warte mal, Reihenfolge. Genau, die nächsten zwei, ja, würde ich sagen, genau, die sind das.
Das erste ist relativ einfach erklärt.
Du hast die Möglichkeit gehabt, mit Tuple-Typen, sprich, Tuple kannst du dir vorstellen wie ein Array mit fixer Länge, wo jedes Element einen spezifischen Typ hat, wohingegen das Array eine Variable-Länge hat und alle Elemente haben den gleichen Typ.
Du hattest die Möglichkeit, dass du in Tuple-Typen mit Labels den einzelnen Stellen im Tuple einen Namen geben konntest.
Das ist rein auf der Typ-Ebene, das ist nur ein ganzer Anhängsel, damit du mehr Metainformationen bekommst, beziehungsweise nimm TypeScript auch diese Labels her, wenn du die Parameterliste einer Funktion extrahieren willst, dass die Namen der Parameter dort aufscheinen.

[40:20] Das ist quasi die Idee. Das funktioniert soweit ganz gut, Problem ist, wenn du irgendwelche Typen hast, die jetzt kein Label haben oder Tuple-Elemente, die kein Label haben, dann hast du die nicht mischen können. Also du hast nicht was mischen können zwischen hat ein Label und hat kein Label, das hat dann Fehler geworfen und diese Änderung macht es jetzt möglich, dass du die mischen kannst. Die Labels werden nachher weggeschmissen, aber zumindest gibt es keinen Fehler mehr, wenn du diese Tuple irgendwie miteinander kombinierst.
Ja. Nett.
Findest du? Ich hab folgendes Problem. Wenn mein Turpel so komplex ist, dass es Namen bräuchte, tragen die Namen zur Übersichtlichkeit nicht bei, sondern machen nur noch mehr Line Noise.
Das kann ich nicht ganz bestätigen. Ich finde diese Labels dann gut, wenn du zum Beispiel so was wie einen React-Hook schreibst. schreibst.

[41:12] Also React-Hooks verwenden hauptsächlich tuple, weil du die Rückgabe-Werte dann gut benamsen kannst.
Das heißt, wenn du setState schreibst, kannst du genau sagen, welchen Namen hat das jetzt, beziehungsweise welchen Namen hat die set-Funktion dazu.
Und damit klar ist, was an welcher Stelle kommt, ist es schon hilfreich, dass du dort im Typen auch die Annotation hast, hey, das ist jetzt der Wert und das andere ist der setter, zum Beispiel.
Da finde ich das gut. Beziehungsweise wenn du halt Funktionen, also Parameterlisten von Funktionen generierst, dann ist ja auch der Name dieses Parameters wichtig.
Der darf nicht nur Strings sein oder Numbers, sondern der hat halt auch einen Sinn.

[41:55] Username und Passwort sind beide Strings, aber sind sehr unterschiedliche Sachen in der Parameterliste.
Genau, und da finde ich das super.
Man kann darüber streiten, ob es jetzt wichtig ist, ob man dieses Mischen kann mit etwas, das keine Labels hat.
Es ist wahrscheinlich ein nerviger Fehler und dass der jetzt nicht mehr stattfindet, finde ich okay.
Ja, ich habe dir jetzt auch nichts dagegen, dass sie das eingeführt haben.
Ich denke halt nur so, ah, nett, ich werde das nicht benutzen.
Genau, nett. Ich verwende Labels bei Doppeltypen sehr oft.
Ich bin ja auch von React runtergekommen, von daher bin ich da vielleicht dann einfach weniger betroffen.
Das nächste Feature ist eigentlich, oh gut, dass das endlich funktioniert.
Endlich funktioniert. Das hat einen ziemlich spannenden Fehler gegeben, dass wenn du jetzt zum Beispiel einen Union-Typen von StringArray oder NumberArray, dann hast du dort nicht auf Array-Funktionen zugreifen können, weil es laut Typescript zwischen String und Number keinen Schnitttyp gegeben hat. Das heißt, du hast gesagt, Moment, wenn du dort jetzt auf ein Element zugreifst oder einen Filter machst und so weiter, was ist das für ein Typ, weil du hast zwei unterschiedliche Arrays, passt irgendwie nicht zusammen. Und dieses Beispiel wird jetzt transformiert, also vom String Array oder Number Array, wird in ein String oder Number Array transformiert.
Und damit hast du jetzt nicht eine Schnittmenge dazwischen, sondern eine Vereinigungsmenge fürs Element und kannst eben wieder solche Filteroperationen und so weiter anwenden.

[43:18] Ja, das ist voll okay. Also auch sowas, wo man denkt, ja gut, das hätte eigentlich schon existiert.
Genau, das wird den meisten halt nur auffallen, weil plötzlich Code, der vorher nicht funktioniert hätte, plötzlich funktioniert. Und zwar genauso, wie man es erwarten würde.
Und keiner wird das hier mitkriegen, dass diese Arbeit geleistet wurde.
Genau. Aber ich bin sehr froh, dass sie das gemacht haben.
Naja, das ist super. Und weitere kleine Editor-Verbesserungen und so weiter.
Ja, Performance hier, Refactoring da.
Es gibt jetzt einen ziemlich coolen Performance-Pool-Request von Prof. Blumberg.
Ich muss mir das mal im Detail anschauen.
Aber die gehen mit isolated declarations, machen so ein paar Abkürzungen, in dem welche Deklarationen nachher vom Typ-Check geermittet werden.
Und der soll ziemlich einen Performance-Gewinn vorsorgen, soweit ich das mitbekommen habe.
Das ist aber dann wahrscheinlich was für das nächste Release.
5.3, so ein kleiner Spoiler. Aha.

[44:18] Interessant. Also dann, wenn mich Kompilierzeit interessiert, verwende ich ja meistens nicht den TypeScript-Compiler. Ja. Das stimmt. Also bei mir ist auch so Typ-Checken im Hintergrund während dem Entwickeln und Compilen noch mit irgendwas, was schnell ist und Typen ignorieren.
Ja, nee, also halt so, ne, Dev-Mode heißt halt, das Babel-Plugin streicht einfach die Typen raus und ich hab halt einfach einen besseren Linter in meiner IDE. Exakt. Und wenn ich's dann baue, dann jag ich's durch CSC durch, um die DTS-Dateien zu kriegen.
Aber irgendwie scheint mir so, mein TypeScript kompiliert zu langsam, ist da doch ein Anforst-Error auf Benutzerseite, würde ich fast sagen.
Aber das weiß auch nicht jeder, ist auch geheimes Templar-Wissen.
Du würdest meinen, okay, ist ein Compiler, also verwende ich den.
Dass man den nicht verwenden sollte, weil's ewig lange dauert, ist ja nicht offensichtlich.

[45:03] Vielleicht sollten die einen No-Check-Flag in ihren Compiler einbauen, das würde helfen.
Ich meine das ernst. Ja, ich glaub, das gibt's sogar.
Ist wahrscheinlich auch langsam. Ja. Also, ich glaub, Peter, ich muss ein bisschen auf die Uhr schauen.
Leider kann ich das nicht.
Aber wir haben eine feste Sendung. Dann schauen wir einfach mal auf den Aufnahme-Anhalten-Button.
Liebe Hörerinnen und Hörer, wir danken fürs Zuhören.
Wir sehen euch in unserem Slack, im FairDiverse und hier auf ... unter welchem Namen jetzt auch immer.
Gerade da Ilons Trümmergruppe da jetzt gerade unterwegs ist.
Da sehen wir euch und auch in der nächsten Sendung, in der es gehen wird um dich, Stefan.
Das war spannend.
Wir danken fürs Zuhören. Bis zum nächsten Mal. Tschüssi. Tschüss.

[45:53] Music.

[46:15] Ich höre dich geklaut deutlich. Und jetzt, jetzt, jetzt kannst du auch endlich gehen.
Mit denen du vor tausenden und abertausenden Standing Ovations bekommst.
Standing Ovations, ich weiß nicht, ob ich Applaus bekomme. Das waren Standing Ovations.
Der Inhalt von meinem Vortrag war ja das, dass ich Dinge in Typescript herzeige, die nicht funktionieren, wo Typescript uns anlügt, wo das Typ-System etwas anderes vorgibt, als wie die Realität widerspiegelt.
Und gebe eben vier Probleme an, vier Lösungen und finde nachher wieder vier Probleme zu den Lösungen.
Und das bauscht sich halt so auf, bis du halt wirklich merkst, okay, also eigentlich alles, was wir irgendwie schreiben, ist total verloren und kaputt und am besten sollte man mit der Programmiererei aufhören und dann kommt eben dieser Kniff, wo ich sage, aber Moment, trotzdem ist Typescript meine zweite Lieblingsprogrammiersprache, weil Typescript macht mich produktiv und diese Schnitzer im Typsystem, diese Kompromisse, die Typescript macht, sind ja nicht von irgendwoher, sondern ganz bewusst gemacht und ich verweise eben auf diesen Eindruck, dass Typescript nicht vorhat, ein, korrektes Typsystem zu sein, sondern ein produktives Typsystem zu sein.
Und Philosophie ein bisschen, würde ich sagen, und das war einfach eine Entscheidung, die die Entwickler damals gemacht haben.

[47:44] Und genauso wie wir als Entwicklerinnen und Entwickler auch Entscheidungen treffen müssen. Also ich gehe ein wenig so auf den Kniff hin.
Unsere Aufgabe ist nicht, zu programmieren, das ist die Aufgabe zum Beispiel vom Co-Pilot oder von Stack Overflow. Unsere Aufgabe ist es, hinter jeder Zeile Code, die in unser Codebase kommt, auch, zu verstehen, was die tut und diese Entscheidung getroffen zu haben, dass die jetzt in unser Codebase, kommt. Das würde ich als unsere Aufgabe sehen, weil immerhin sind wir alle Entwickler. Und ich habe eben dann diese Slides gehabt, das war der Übergang, we are all developers, also we are developers, es war die we are developers Konferenz, und da habe ich da ein ziemlich blödes Gesicht gezogen und habe diese Wojack-Geist gehabt, die nachher hinzeigen, diesen tollen Witz. Und das hat die Leute komplett überrascht und die sind gestorben verlochen. Das hat einen wunderschönen langen Applaus vorsagt und ich habe mich gar nicht mehr eingekriegt, aber gesagt, okay echt jetzt, das kommt so gut an, spitze. Also ich bin ein Boomer-Mimer, ich habe absolut keine Ahnung, was dieses Meme überhaupt bedeutet, aber ich habe es lustig gefunden und es ist anscheinend auch gut dann auch mal ein komisches Video von mir.

[48:54] Ich finde vor allem auch der Kontrast zwischen der Größe der Bühne und so der ganzen Gravitas hinter der Veranstaltung und dann kommst du halt da mit den Paint-Kraklern vorbei. Finde ich sehr gut.
Das war's für heute. Ich hoffe, ich konnte euch helfen. Wenn ja, dann abonniert meinen Kanal.
Wenn euch das Video gefallen hat, dann lasst ein Abo da, dann das Video hier oben unten.
Und dann abonniert den Kanal. Und dann sehen wir uns beim nächsten Video.
Ja, ich glaube, dass das sehr zugänglich war, weil die anderen Leute, die auf der Hauptbühne waren, die haben ja diese großen Ideen und solche Sachen.
Ja, der Heini von Stackoverflow war, glaube ich, letztes Jahr da und hat da gesprochen und keine alte Sau war da. Das fand ich lustig.
Ja genau, also der Stack Overflow Typ ist immer dabei, der John Romero von der Doom Entwickler ist auch immer dabei, seine Frau ist immer dabei, und der Arne Typ von SAP, der der Chief Innovation Typ ist, der halt ganz große, wichtige Zukunftsthemen behandelt und dann kommt halt dazwischen der Pausenclown und macht halt die Strichmännchen auf einer weißen Folie, also spannend minimalistisches Design.
Es dürfte glaube ich zielpublikumgerecht gewesen sein und ich freue mich sehr darüber.
Ich bin sehr happy mit dem Ergebnis.
Sicher von meiner Sprecherkarriere, wenn ich tatsächlich eine haben sollte, war das einer von den schönsten Momenten. Irrsinnig nervös.
Aber ich habe auch das Gefühl gehabt, dass ich irrsinnig stabil war im Vortrag.
Das passiert mir auch nicht oft.

[50:17] Naja, komm, das ist halt, wenn du das Thema, glaube ich, ganz gut kennst und ich würde sagen, bei TypeScript gibt es jetzt nicht so viele, die dir was vormachen.
Ja, das kann ich nicht sagen.
Aber ist zumindest.

[50:34] Zumindest weiß ich, was ich da präsentiere, glaube ich. Also das ist das schon. Die Themen habe ich ja relativ oft durchgekaut.
Mein Englisch war sehr stabil. Das hat mich auch gefreut. Normalerweise harte ich da immer recht herum, aber ich habe so eine Entschlackungskur gemacht bei dem Vortrag und habe einfach viele Details weggegeben, dass ich mich nur auf die Geschichte fokussiere und dann war mein Englisch auch gut.
Man hat halt so seine Bewegchen oder Problemchen, wenn man präsentiert.
Präsentiert und das war dann Gott sei Dank eins mehr.

[51:04] Hervorragend. Persönlich war ich sehr, sehr zufrieden und vor allem der Ansturm nachher. Ich glaube, ich habe die drei Stunden danach mit 70 Leuten gesprochen. Ich bin nicht mehr aus den Räden gekommen. Es war beeindruckend.
Nicht schlecht. Auch der Menge geschuldet. Es sind ja glaube ich vor Ort, 12.000 Leute gewesen. Das ist halt eine Masse. Mit der musst du halt umgehen können.
Und ich glaube halt, das Thema ist halt auch wirklich so eins, Also, gerade so TypeScript, das ist halt so unhandlich im Sinne von, das hat halt so viele Ecken und Enden.
Da ist halt auch immer sehr viel Nachfragebedarf und ist das wirklich so, mache ich das richtig und so.
Weil ich hatte ja letztes Jahr TypeScript da als Thema.
Und wie gesagt, ich hatte halt eine Größenordnung weniger Läutchen da.
Aber trotzdem, wenn ich das jetzt mal so verrechne, dürfte da der Ansturm hinterher ungefähr gleich viel gewesen sein.
Mit halt so, mache ich das richtig, ist das wirklich so gedacht oder ...
Ja, es ist spannend, weil die Sprache wirft doch einiges an Nuancen auf, wo sich manche Entwicklerinnen und Entwickler nicht ganz sicher sind.
Ich habe schon mittlerweile das Gefühl, dass TypeScript so ähnliches Schicksal wie C++ erleben wird, wo sie Teams auf ein Subset einigen müssen, um sinnvoll produktiv gemeinsam zu sein.

[52:23] Weil die du ja ausdrucken kannst mit unterschiedlichste Techniken.
Nimmst du Function Overloads, nimmst du Conditional Types, nimmst du Klassen, nimmst du Interfaces, nimmst du Types, nimmst du die objektorientierten Features.
Also du hast einfach viele Ausdrucksmöglichkeiten. Ich könnte jetzt mittlerweile nicht einmal sagen, wie viel die richtige oder einzig wahre ist, weil vor diesen dogmatischen Tipps geht mir sowieso nichts halt.

[52:51] Aber zu wissen, dass man eine Auswahlmöglichkeit hat, und zu wissen, welche Implikationen jede Möglichkeit besitzt, das gehört, glaube ich, mittlerweile zur täglichen Arbeit einzelner Teams dazu.
Ja, und ich würde ja sagen, ist ja nicht mal TypeScript spezifisch, sondern ist ja mehr so JavaScript an sich.
Die großen Schismen, so OOP und Funktional und so, Die finden sich ja da auch drin.
Und dann packst du halt eben noch Klasseninterfaces und was nicht alles on top und dann wird es nicht einfacher.
Ich habe so ein spannendes Erlebnis gehabt vor kurzem.
Ich habe ein sehr, sehr altes Programm für mich, ein ganzes Note-Skript, das ich verwendet habe, um aus YAML-Files JSON-Files zu generieren, damit ich so eine Statistik machen kann.
Ich bin über sämtliche Meetups von unserer Meetup-Gruppe drüber gegangen, habe die Hosts rausgezogen und ich bin über eure Sprecherinnen und Sprecher drüber gegangen und habe die Sprecherinnen und Sprecher rausgezogen und habe dann so eine Statistikliste gemacht, die ich wieder in einem statischen Seitengenerator packen kann, der nachher so Highscores oder so ewige Bestenliste produziert hat. Und habe das mit einem 100 Zeiler gemacht, also wirklich nur.

[54:12] Daten.
Transformieren und starte mit dem Objekt oder mit der Liste an Files, mit den Objekten transformierst durch und bringst in ein Format, das ich noch irgendwo verarbeiten kann.
Rein ist JavaScript und vom Stil her mittlerweile, muss ich sagen, sehr fragwürdig, was ich da gemacht habe, weil ich wüsste nicht, wie ich das sinnvoll typen könnte.

[54:34] Weil ich nur Objekte als Maps verwende und dort in irgendwas reinschreibe und einfach nur hoffe, dass das nachher im JSON am Ende wieder richtig rauskommt.
Und alleine die Einschulung vom Typen, einfach nur, dass ich mir Gedanken machen muss, wie mein Modell ausschaut, hätte komplett verändert, wie das Programm geschrieben worden wäre.
Also komplett. Zum Besseren? Auf jeden Fall zum Besseren.
Nein, also ganz gerade zum Besseren, weil ich habe dann dort noch ein paar Techniken drin gehabt, wo ich halt einfach abgekürzt habe.
Ich habe auch nicht den Anspruch gehabt, dass das Ding stabil funktioniert, weil es war ein kleines Helfer-Skript für mich, damit ich die Liste nicht selbst manuell warten muss.
Aber jetzt gehe ich halt sechs Jahre später oder sieben Jahre später dran und denke mir, ich habe keine Ahnung, was das Ding tut. Ich könnte es dir nicht sagen auf der Basis von den Objekten, die ich dort lese. Und ich habe das wieder mühsam erarbeiten müssen.
Das gefällt mir so gut, weil mittlerweile ist das nämlich eines meiner Beispiele, um die Sinnhaftigkeit von TypeScript zu manifestieren, wenn ich Workshops mache.
Mache ich mit einer Gruppe gerne mein altes Programm durch und ich versuche, dass die Gruppe redet, was ich mit dem Programm gemeint habe.
Das ist die Idee geworden. Das stellt sich sehr spannend heraus.
Das mache ich immer ganz gerne, aber mit dem Code von dem Kunden.

[55:53] Ja, stimmt. Ihr wollt einen Typescript-Workshop haben, aber ihr habt schon Typescript. Wie wäre es, wenn ich nicht einfach meine Slides runterbete, weil ihr wisst eh die Hälfte davon.
Wie wäre es, wenn wir über das reden, was ihr nicht wisst? Gibt mal Code.
Ja, das ist natürlich die beste Art.
Ja, geht natürlich nicht, weil NDA und man kann dir doch nicht den Zugriff geben, bla Keks und dann muss man sich da älter machen. Ihr unterzeichnet ein Alman-NDA und uns geben halt dann ausgewählte Beispiele.
Ja, das hat schon hin. Manchmal gegen erbitterten Widerstand. Das kommt halt darauf an, wie groß der Laden ist und ob der vernünftig drauf ist oder ob das irgendwelcher tyrannischer Mittelstand ist.
Von wegen, oh, unsere Geschäftsgeheimnisse.
Also was immer gut funktioniert ist, Entwickler, die mich direkt anschreiben und sagen, hey, sie hätten ein Problem und ich sage, okay, dein Deal ist das.
Du kriegst von mir eine gratis Antwort, aber ich verwende dein Problem anonymisiert für einen Blogpost.
Das sowieso. funktioniert sehr gut, also da kommt echt viel raus dabei. Das ist der einzige Grund, wie meine Serie hier Fragen zu HTML5 beantwortet jemals Inhalt bekommen hat.
Ich finde, das ist ein guter Deal. Total, weil dann hat man es auch schon fertig formuliert und dann geht es ab in die Zweitverwertung. Es ist interessant, dass du diesen Weg gegangen bist, von früher mein unordentliches Programm hin zu einem ordentlichen mit TypeScript und so. Ich Ich habe mich letztens den umgekehrten Weg beschritten.

[57:14] Wieder weg mit den Typen. Weg mit allem. Weg mit dem ganzen smarten Zeug.
Also ich habe halt meinen Präsentationstool mal wieder neu geschrieben.
Das muss man ja alle paar Jahre mal machen. Bei welcher Nummer bist du jetzt?
Pick 10? Pick 11? Ich habe aufgehört zu zählen. Es heißt tatsächlich jetzt einfach nur N. Ja.

[57:36] Aber da bin ich halt tatsächlich hingegangen. Ich habe so gesagt, Ich versuche, das jetzt einfach mal so reudig wie möglich zu machen und mit so dem Ziel, maximale Stabilität herzustellen.
Und halt eben einfach so native DOM-Methoden, Blahkeks. Das Einzige, was daran bisschen fancy ist, dass ich halt für meine Web-Components Decorators verwende.
Und dafür halt eben auch Parcel, aber Parcel verwende ich sowieso zum Bundlen, dass ich halt irgendwie sagen kann, mach aus meiner Slidesammlung, also irgendwie, ich hab, das ist so Produktreihe irgendwie so, TypeScript-Workshop, diese Größe, jene Größe, solche Größe.
Und dann kann ich einfach ein CLI-Kommando schreiben kompiliert ihr mir das in eine HTML-Datei, je nachdem, was ich da gerade erzählt habe.
Und da ich sowieso den Bundler habe, kann ich halt eben auch da Decorators reinbauen, aber der Rest ist halt wirklich so, also ich hab hier so, wenn ich mal so zitieren darf, irgendwie so, eckige Klammern, .indexof, .call, document, query, selector, all.
So Zeug ist da halt eben drin, weil, es ist halt eine Zeile, und die Zeile wird bis in alle Ewigkeit funktionieren, und ich hab keine Bock, das Ding noch mal neu zu schreiben, jetzt gefälligst bis zur Rente zu halten.

[58:36] Und deswegen hab ich alles rausgeschmissen. Also kein RxJS mehr da drin, kein jQuery mehr da drin, was da alles in den vorherigen Dingern drin war.
Einfach nur Funktionen, paar globale Variablen, die Wahrheit lebt im DOM.
Also nicht irgendwie so aus dem State die Daten oder so was, sondern das sind einfach irgendwie so 100 Prozent OOP und ein bisschen Glue-Code on top.
Herrlich. Also ich hätte gern wieder so ein Projekt, wo man einfach mit Basismitteln komplett frameworkfrei, was Tolles schaffen kann.
Ich schreibe halt nur viel zu wenig JavaScript im Moment.

[59:08] Ja, ich weiß nicht, ob du das unbedingt haben willst. Schön ist es halt nicht.
Es muss nicht schön sein, es muss nicht zufriedenstellend sein.
Mein Anspruch ist sehr minimalistisch. Du wirst ja dann gern die neuen Werkzeuge und Tools von JavaScript verwenden.
Das hat natürlich auch einen Sinn.
Ich habe mich mit Klassen nun nie so auseinandergesetzt, dass ich sage, okay, ich setze jetzt mein eigenes Programm nur auf Komponenten- und Klassenbasis auf, ohne dass ich irgendein Framework verwende oder so. Das würde ich gerne mal machen.
Es ist schwierig, weil ich glaube, um, sagen wir mal so, ich habe das jetzt so formuliert, aus einer bestimmten Risikoüberlegung heraus. Nämlich die Risikoüberlegung ist irgendwie, die ganze Software geht über einen Dicer und ich kann irgendwann das tatsächlich nicht mehr weil irgendwie die Dependencies nicht da sind.
Ich hab auch kein Node-Modules außerhalb eben für das Build-System.

[1:00:03] Sondern alles ist da schön in Vendor drin.
Ganz klar. Aber das ist sozusagen das Szenario, wogegen ich mich verteidige.
Und das kann ich halt eben machen, weil das andere Risikogebiet, nämlich dass ich irgendwie das Scope-Creep habe, das kann ich halt ausschließen, weil ich ja weiß, was es werden soll und was es sein muss, und es wird niemals was anderes sein müssen, als das, von dem ich sehr genau weiß, was es ist, im Szenario Scope Creep, Erweiterung, Änderung. Und wenn das passieren kann, ist das glaube ich nicht schlecht, dass du sowas hast. Ja, das stimmt. Andererseits brauchst du dann wieder gute Architektur und die kennst du mittlerweile eher. Also du weißt ja mittlerweile, der SlideTool funktioniert.

[1:00:42] Ja, äh, pfff, ja. Wie das? Weiß ich nicht.

[1:00:48] Ich hab ja mal tatsächlich mir angeschaut, wie so andere funktionieren hier.
Wie heißt denn das? Ja, Reveal zum Beispiel.
Das hatte ich mir ja angeschaut, als ich da ein Plugin für geschrieben habe, für dieses Code-Animations-Ding.
Das ist definitiv sehr viel komplexer und sehr viel smarter.
Also meine main.js hat 218 Zeilen.
Wunderbar. Ja, aber bitte, das sind ja nicht die tollen Dinge.
Aber es sind dann noch so ein paar Klassen für die Web-Components und Zeug, aber trotzdem.
Na, herrlich. Ja. Einfacher Code, simpler Code, dependencyfrei.
Wunderschön. Nicht die unbedingt haben.
Ja, das ist nicht dependencyfrei. Die sind halt nur jetzt in einem Folder.
Okay, gut, fair enough. Ja, aber immerhin bin ich NPM-frei, was alles außer das Bildsystem angeht.
NPM ist ja Technical Dead mit der ersten Zeile. Das ist leider so.
Also, mir graust richtig davor, wenn ich ein Node-Modul sehe.
Aber ich bin ja auch in einem komischen Platz gerade im Moment.
Das Problem ist halt, dass npm immer nur Probleme löst, aber halt auch Probleme macht und das ist halt sehr schwierig.

[1:01:55] Ja, was glaube ich so wirklich fehlt, ist so irgendwie das Bewertungskriterium.
So recht. Also du findest ja manchmal, wenn du irgendwie verzweifelt nach einem npm-Modul findest, findest du ja diese ganzen Bewertungsseiten, die irgendwie da versuchen diese Packages zu scoren anhand von Aktivität und Zeug.

[1:02:15] Ich weiß ja nicht, was das richtige Kriterium ist, um zu entscheiden, ob jetzt irgendwas ein gutes Package ist oder nicht, aber was die machen, ist es definitiv nicht. Ja, es ist eine gute Frage. Ich, könnte es da nicht beantworten. Es hat über den Zeitraum, wo ich es brauche, am wenigsten Probleme gemacht. Das ist, glaube ich, das einzige Kriterium, das ich wirklich nennen kann. Aber da fällt mir auch nicht mehr recht viel ein, was ich da reingeben würde. Was heißt Problem? Also Problem ist jetzt ja auch sehr allgemein. Naja, das Ding ist, beschäftigst du länger mit der Wartung und der Instandhaltung vom Framework, also wie dass du das Framework tatsächlich nutzt, dann wird das schon ein Problem sein. Also wir haben teilweise das Problem gehabt, bei Leuten, die ich kenne, die haben halt Angular verwendet, als Beispiel jetzt nur Angular, ist beispielhaft coole anderen Sachen und haben halt das Problem, dass wirklich quartalsweise, wenn die nächste Version kommt, die gesamte Firma einmal einen Tag Pause hat, damit das Kern-UI-Team die, Möglichkeit hat, die Dependencies zu aktualisieren.
Und da würde ich schon sagen, wenn das...
Wenn das mein Anspruch ist, dass alle 100 UI-Entwicklerinnen und Entwickler einen Tag Pause machen, vier Tage im Jahr mindestens Pause haben, dass sie aktiv an Features arbeiten.

[1:03:37] Dann ist das nicht das richtige Framework, so stabil es auch sein kann.
Das andere, was ich habe, ist Next.js. Das hat gut angefangen.
Und das Problem, was du jetzt hast, ist, dass die so viele Versell-Plattform-Features reinbauen, dass das einfach nicht mehr wirklich nutzbar ist für andere Dinge.
Bzw. du dir versteckte technische Schuld einkaufst, die dir nicht einmal bewusst ist.
Ja, sie haben im Prinzip einen Garten gepflanzt und jetzt fangen sie langsam an, die Mauer hochzuziehen.
Ja, genau, genau, genau.
Also Park geschaffen, jeder darf rein, den Zahn runterholen und bitte ein Ticket kaufen. Ja.
Das ist so die Idee. Aber gut, das ist halt ja sozusagen, das hätte man vorhersehen können, glaube ich. Ja, sicher.
Also, da weiß ich jetzt nicht, ob das jetzt in die gleiche Kategorie wie so ein Angular rein muss.
Angular hat ja wenigstens den Anspruch, das nicht zu sein, und ist es dann vielleicht trotzdem.
Ja, also das Problem ist halt, man verbringt irrsinnig viel Zeit mit der Wartung, mit der Instandhaltung von dem Programm, wenn man das Framework hat, oder irgendwelche Bibliotheken.
Es gibt ja genauso gut Notbibliotheken, die ständig Pflege brauchen, und ich weiß nicht.
Also, ich habe generell das Problem, da werde ich jetzt aber schon sehr, sehr philosophisch, dass Dinge ja scheinen, wie wenn sie nie fertig werden würden und gerade mit Frameworks, die jetzt zum Beispiel unterstützt sind von Venture-Capitalists und von Startups.

[1:05:01] Die werden auch nie abgeschlossen. Das Thema ist, dass dieses Framework weiterlebt und dass dort Features reinkommen. Das ist die Arbeit und der Job dieser Leute, dass dort Dinge erschaffen werden.

[1:05:12] Und solange das deren Beruf ist, werden auch Dinge erschaffen, ob sie sinnvoll sind oder nicht.

[1:05:19] Die Frage stört mir nicht, sondern es muss halt ein Roadmap geben.
Es ist nie ausentwickelt, meinst du?
Genau, und auf der Roadmap steht nie, wir sind jetzt fertig.
Das Einzige, was wirklich einen finalen Stand feature-technisch bekommen hat, war die Query.

[1:05:33] Ich ... also, ich ... Ich glaub, es gibt noch Sicherheitsupdates.
Aber tatsächlich, ob da jetzt Features implementiert werden, glaub ich nicht. Ich glaub, das ist ...

[1:05:44] Was man ja problemlos rechtfertigen könnte. und neue Versionen rechtfertigen mit irgendwie, sagen wir mal, etwas gestreamlainteren APIs, die so gleichsam dein YAML-Beispiel von früher, ne?
Also, da sind halt so viele Patterns drin in jQuery, nach dem Motto, die Signatur dieser Methode ist halt, steck irgendwas rein, und unter der Haube machen wir ganz viel Ducktyping, um rauszufinden, was du gemeint hast.
Das ist ja heutzutage nicht mehr so en vogue, und man könnte problemlos rechtfertigen, ein Update zu machen, irgendwie Version 4.0 oder so, wo man das halt eben mal aufräumt.
Vom Feinschleifen und von nuancierten Verbesserungen, aber an dem Grobkonzept wird sich ja nix ändern.
Und ich glaube, diese Feinverbesserung will auch keiner haben von denen, die das noch nutzen.
Da liegt der Wert mehr so darin, dass man halt eben was hat, worauf man sich verlassen kann, was halt gleichsam Infrastruktur ist.
Absolut und das Schöne ist ja, ich habe vor kurzem so ein Twitter-Wall gebaut, ist schon länger her jetzt, als es noch Konferenzen gegeben hat, also vor Corona. Und da haben wir das Problem gehabt, dass wir die Sprecher und Sprecherinnen in so einem Karussell durchfahren, lassen wollten, automatisch. Das heißt, du hast Twitter-Wand auf der einen Seite gehabt und die Sprecher-Bild links oben und die Sponsoren-Bild links unten. Und Sponsoren und Sprecherinnen sind über unterschiedliche Timings durchgeschaltet worden.

[1:07:09] Unsere Digitalistik gemacht, Flexbox im CSS und eine Jiquiri Plugin draufgeschnalzt, die sich konfiguriert hat nach dem Timing. Fertig, erledigt, 30 Minuten, 30 Minuten Aufwand und ich habe die perfekte Twitter-Wall gehabt für unser Problem. Jetzt habe ich es nur erweitert und habe ein CMS dran gehängt und ein paar Konfigurationsmöglichkeiten und solche Sachen, Aber mir erschließt sich da der ganze Trend nach diesen Frameworks, die unbedingt konstant neue Features brauchen, nicht, wenn es mir nicht hilft, dass ich genau bei diesen rudimentären Tasks einfach schneller werde. Warum kann ich das nicht auch in Next.js einfach aktivieren? Warum ist das nicht einfach da, als irgendwelche Komponente, die funktioniert und nicht ewig und Stunden braucht, dass ich das habe, wo ich auch noch Entscheidungen treffen muss. Renne ich das jetzt am Server oder am Client oder was auch immer. Also ich finde, da ist das Framework ein bisschen, innoviert an der falschen Stelle. Mein Wunsch war eigentlich gewesen, dass ich, genauso wie es die Web-Components versprechen, dass ich in React einfach irgendwelche React-Komponenten kombinieren kann und das Ding flutscht und ich brauche nichts mehr machen. Aber ich sehe das nicht. Also ich sehe in React, Angular oder wie sie auch heißen mögen, sehe ich einfach nur mehr Entwicklungsaufwand.

[1:08:25] Ja, die betreiben das halt auf eine bestimmte Weise, wie du es halt beschrieben hast, also auch wenn sie selber nicht irgendwie Venture Capital Funded sind, operieren sie als wären sie es und das trifft halt eben auch viele zu, statt zu sagen, so ist fertig, naja und das ist natürlich auch so, ähm, das ist halt auch so ein bisschen ein Problem des Wachstums, also du hast irgendwie was geschrieben und das ist irgendwie halbwegs erfolgreich, dann nutzen immer mehr Leute das und deine neue Nutzerschaft rekrutiert sich ja notwendigerweise nach einem gewissen Punkt nicht mehr aus denen, die sofort sagen, das passt auf genau, was ich brauche, sondern das rekrutiert sich aus dem, das kann ich mit ein bisschen Gewalt dazu bringen, dass es auch für mich funktioniert, aber dann kommt direkt danach der Bug-Report, kannst du das nicht irgendwie rundermachen?
Und damit hast du ja so quasi automatischen Scope-Creep mit drin.
Und das braucht wahrscheinlich irgendwie ganz gewaltige ...
Ja. Disziplin hauptsächlich. Ja. Ich mein, es ist ja jetzt auch nicht falsch, irgendwie die Software zu verbessern oder so.
Deswegen keine Ahnung, was es da braucht. Bringt mich zu einer sehr guten Überleitung. Pass auf, Peter.
Dinge, von denen wir nicht wissen, ob wir sie unbedingt benötigen.
Es gibt jetzt ein neues JavaScript-Feature, das jetzt in TypeScript 5.2 auch zur Verfügung steht.
Soll ich irgendwie zwischendurch mal die Sendungsnummer ansagen?
Bitte sehr gern. Das ist wie immer so das Sahnehäubchen des Quartals, wenn man aus unserem hier irgendwie eine kohärente Sendung zusammenschnipseln muss.
Okay, ich tue einfach mal so, als hätte es das ganze Vorgespräch nicht gegeben.