Revision 560: Typescript 5.0

2023, Vanessa Otto, Peter Kröner, Hans Christian Reinl, Stefan Baumgartner Und Christian Schaefer
Working Draft
https://workingdraft.de/

Edit Transcript Remove Highlighting Add Audio File
Export... ?

Transcript


[0:00] Es ist eine Major Version, also TypeScript hat ja jetzt nicht diese, oh wow wir haben Breaking Changes mit einer Major Version Idee, sondern sie sagen TypeScripts Grundidee ist Breaking Changes zu verursachen, deswegen sagen sie einfach noch 4.9 ist 5.0 dran.
Also so ein Typparameter kann ja schon sehr wortreich sein und wenn ich jetzt hier so sehe, Konz T, Extents Read Only, irgendwas?
Ich bin da, wie sagt man das, Kampf geprüft. Ich schreibe Last.
Also was da im generischen Umfeld passiert, das ist wild.
Aber es ist so gut, du sagst so viel richtige Sachen. mach ich, ob ich das vermisse.

[0:36] Music.

[1:01] Hallo und herzlich willkommen zu Working Draft Revision 560.

Revision 560: Typescript 5.0

https://workingdraft.de/560/


[1:04] Heute am Start der Stefan. Hallo Servus. Und meine Wenigkeit der Peter.
Was mag wohl das Thema sein, wenn die zwei sich alleine im Working Draft Studio einfinden?
Jawoll, der Microsoft hat wieder gekreist und gebar uns eine neue TypeScript Version, speziell jetzt die Version 5.0.
Peter und wir zwei ehemaligen Langzeiturlauber dachten uns, lassen wir doch mal die Tradition wieder auferleben und sprechen darüber, was es da so alles Neues gibt und ob uns das interessiert und wie wir das finden und so weiter.
Genau. Es ist eine Major Version. Also TypeScript hat ja jetzt nicht diese Oh wow, wir haben Breaking Changes mit einer Major Version Idee, sondern sie sagen, TypeScripts Grundidee ist Breaking Changes zu verursachen. Deswegen sagen sie einfach noch 4.9 ist 5.0 dran. Es erlaubt ihnen aber, troch diverses Verhalten von grundlegenden Features neu zu überdenken. Und ich glaube, von dem sehen wir diesmal einige Sachen. Oder zumindest, Okay, was würdest du sagen, fällt da so in die Kategorie rein?
Decorators und Inams.
Aber meinst du nicht, dass das mit den Decorators eher was damit zu tun hat, dass jetzt der ECMAScript-Standard sich mal aufgerafft hat? Ich hätte gemeint, das trifft sich gut.

[2:18] Das wäre meine Idee gewesen. Also Decorators, also gut, von vorne.
Ich wollte gerade sagen, du als Klassenfeinschmecker solltest doch erstmal erklären, was Decorators sind.
Genau, Decorators. anfangen. Wer von euch schon Angular 2 Plus geschrieben hat, kann sich vielleicht daran erinnern, dass Angular diese Decorator Syntax sehr stark verwendet hat. Du hast dieses Add.

[2:43] Something über einer Klasse, über eine Methode und kannst damit deine Klasse mit neuen Features ausstatten. Oder im Falle von Angular wird heute der Compiler aktiv und sagt, oh wow, das ist etwas, das muss ich ein bisschen anders behandeln und da muss ich ein paar zusätzliche Compiler-Dinge starten. Und das ist ja ein Feature, das kennt man aus anderen Programmiersprachen genauso. Also vor allem in C-Sharp und in Java, Java heißt es glaube ich Annotation, sind diese Sachen vorhanden.
Du kannst einfach sagen, hey, dieses eine fällt, diese eine Methode, diese eine Klasse, ich behandle sie jetzt etwas anders, ich füge weitere Eigenschaften hinzu oder lese aus diesen Eigenschaften etwas Spezielles raus.
Basierend auf dem Decoretor Pattern, das ist ein Pattern aus der objektorientierten Programmierung halt in Syntax gegossen. Das ist glaube ich der spannende Unterschied zum eigentlichen Software Pattern. Und das Thema war das, dieser Decorator, der trägt ja eine Geschichte mit sich. Das ist ja fantastisch, weil ursprünglich hat es niemand auf dem Schirm gehabt, außer Google für Angular und Angular hat gesagt, hey, lass uns doch unsere eigene Programmiersprache machen, AddScript, Add wegen diesem Decorator Add Symbol, mit der wir eben Decorators schreiben können und die für unser Framework Angular besonders dienlich sind.
Und dann hat TypeScript, das TypeScript-Team, gesagt, hey, coole Idee, nur 90 Prozent eurer neuen Sprache sind TypeScript, es geht eigentlich wirklich nur um die Decorators.

[4:08] Lass uns doch zusammenarbeiten. Anders Heilsberg mit Kollegen ist runtergeflogen nach Mountain View, die haben sich mal zwei Wochen eingesperrt in einem Meetingraum und haben noch entschieden, passt, wir können Decorators experimentell unterstützen in TypeScript und es braucht keine neue Programmiersprache dafür.
Und so ist TypeScript überhaupt einmal in Angular reingemandert.
Und das Spannende war noch, was gesagt haben, hey, okay, Decorators sind das Tier, dass auch andere Framework-Hersteller, wie z.B.
Ember, gemeint haben. Also, coole Idee, wollen wir jetzt auch für unsere Dinge, ist eh in TypeScript, d.h. wir brauchen dort nicht irgendwie andere Programmiersprache entdecken, aber Yehuda Katz vom Ember-Team hat gesagt, das muss ein sauberer Standard werden.
War da ein Proposal gemacht und das Proposal liegt jetzt seit keine Ahnung, acht Jahren herum oder so. Es hat ewig gedauert.
Was spannend ist, weil es hat tatsächlich für dieses eine Proposal in ECMAScript ja sehr sehr viele Real-World Beispiele gegeben.

[5:00] Großes Problem war, es hat sich mit der Modul-Syntax geclasht.
Das heißt, die Modul-Syntax hat gesagt Export und dann etwas.
Und die experimentellen Decorator haben gesagt, der Decorator kann über dem Export Keyword sein.
Und die tatsächlichen ECMAScript Decorators haben gesagt, na ja, eher nach dem Export.
Das war, glaube ich, dieser große, große Unterschied mit Ausnahme von einigen Details in wie solche Decorators implementiert werden sollen. Aber das war der große, große Unterschied.
Naja, und das ist ja auch immer so Abwärtskompatibilitäts-Fragen mit zum Beispiel irgendwie so private Klassenfelder. Ja, genau.
Wie spielt das zusammen, wie kann man sowas dekorieren? Also, es ist halt in sich, weil halt so eine Klasse in ECMAScript schon eine hart komplizierte Angelegenheit ist, extra schwierig, so was da noch anzuflanschen.
Syntaktisch sicherlich, aber halt eben auch semantisch und das Ganze irgendwie zukunftssicher zu gestalten.
Ich hatte mich ja zwischenzeitlich sogar mal zu der Annahme versteift, das wird eh niemals was.
Ja.
Aber es hat halt noch nur irgendwie eine Dekade gedauert und dann ist es was geworden. Ja.
Das Spannende ist das, also ich weiß nicht, ich glaube, dass der Trend zu eher mehr Funktionen nutzen in JavaScript hat einfach das Proposal einschlafen lassen, da war einfach nicht mehr der Nutzen da.
Und tatsächlich ist es aber nicht so doofes Feature, also gerade wenn man Klassen schreibt, wenn man meint, Klassen schreiben zu müssen, dann kann man damit doch einiges Tolles anstellen.

[6:26] Und jetzt sind die Decorators hier. Also Decorators sind in ECMAScript jetzt schon länger in Stage 3, deswegen ist das, was ich gemeint habe, ich glaube, dass das Scythe Script schon auf die 5.0 gewartet hat, bis das die Implementierung endlich landet, weil ich glaube, es ist schon seit über einem Jahr das Proposal dort, wo es sein soll. Und es ändert sich in Wirklichkeit nicht großartig viel für euch zu entwickeln. Es ist jetzt dem Standard entsprechend, das heißt ihr braucht dieses Experimental Decorators Feature nicht mehr. In der Nutzung ändert sich fast nichts. Ich glaube, in der Implementierung gibt es andere Methoden oder Funktionsschnittstellen. Ich kann das aber nicht genau sagen, weil ich einfach selbst nie Decorators geschrieben habe, weil ich selten Klassen schreibe. Na ja, es ist halt insofern, was als ECMAScript schon sich Mühe macht mit den.

[7:11] ECMAScript-Features, vor allen Dingen halt eben privaten Feldern nach Art eben von ECMAScript, nicht so sehr nach denen von TypeScript, sich da irgendwie zusammen zu finden. Dazu gehört halt eben auch dieses neue Accessor Keyword für Jetta und Zeta, die halt dann auf ein privates Feld zugreifen, was halt in der Welt von TypeScript, wo Privatheit eben per Compile-Time-Feature implementiert wird, einfach keine Rolle spielt und insofern ist das da alles nicht drin.
Aber die generelle Idee, so aus Perspektive derjenigen, die das am Ende anwenden, ist es tatsächlich das Gleiche.
Ich habe irgendwie ein Klassenfeature, die ganze Klasse oder eine Methode oder ein Feld oder weiß Gott was und da klatsche ich dann halt eben Annotationen, add irgendwas davor und die helfen dann diesen jeweiligen Features gewisse Funktionen über.

[7:58] Als Alternative zum guten alten Class A Extents B. Was ja so ein bisschen Häkeln mit Ofenhandschuhen ist.
Also geht halt schon, macht halt keinen Spaß. Und da wird halt so das Versprechen von Wiederverwendbarkeit und Komposition besser eingelöst durch so einen Dekorator.
Der ist im Prinzip einfach nichts weiter als eine Higher Order Function, die halt auf den Klasselementen operiert.
Also bis da wieder eine Funktion schreibt, könnte ein Dekorator schreiben.
Solange TypeScript nicht mitspielt, weil das Typing von diesen Dingern ist dann schon ein bisschen advanced. Aber ja, das ist jetzt da und das kommt und das wird und ja.
Wenn man halt meint, Klassen schreiben zu müssen, sagst du, ne?
Ja, also ich bin ja mittlerweile auch nicht mehr so ein Hardliner wie ich es früher war, weil es mir eigentlich mittlerweile sehr wurscht ist, wie jemand entwickelt.
Es gibt ja Nutzen für Klassen. Wenn du komplexen State verwalten musst und es.

[8:54] Gut ist, diesen State über angehängte Methoden zu verwalten, bitte gar schon machen wir eine Klasse. Also absolut sinnvoll zum Beispiel Bilderobjekte oder Bilderklassen. Herrlich, wo du einfach nicht weißt, hey, gibt es irrsinnig viele Varianten, die noch zum finalen Objekt führen können. Mach ein Bilderpattern, wo du einfach mit jedem Methodencall etwas vom internen State änderst und dann hast du Bilder und du kriegst ein finales Objekt raus. Fantastisch, super, funktioniert sehr gut. Überleg halt, ob du diesen State brauchst. Also das ist etwas, was ich bei vielen meiner Kunden schrägstrich Kollegen, je nachdem wo ich gerade bin, mitbekommen ist, dass einfach die Klasse immer so das erste Mittel ist zu dem Skyfen. Einfach weil sie es so kennen. Und dann denkst du, hey cool, du laufst dort in State Maintenance Probleme rein, die du alle nicht brauchst, wenn du einfach schaust, hey du kriegst shit in, shit out. Also eine ganz Funktion. Du hast Inputparameter, du hast auch Inputparameter. Und man soll halt... also es gibt ja für jedes Werkzeug einen Verwendungs-Track und das ist nicht jeder Verwendungs-Track. Und genauso gibt es Funktionen, gibt es Dinge, die besser in Objekten, Dinge, die besser in Klassen, Dinge, die besser in Funktionen aufgehoben sind. Genau. Ja, also so als wichtigsten Anwendungsfall von Klassen würde ich einfach mal in den Raum werfen, irgendwelche anderen Tools, die mit Klassen arbeiten.

[10:17] Die Entscheidung ist ja nicht zu 100% dir überlassen, du musst ja mit irgendwas zusammenarbeiten.
Und wenn du zum Beispiel jetzt hingehst und sagst, ich mach jetzt eine React-Anwendung, Gott bewahre.
Dann würdest du wahrscheinlich einfach eine klassische Funktion schreiben, die halt irgendwelches JSX ausspuckt, weil das ist halt wie es da gemacht wird.
Sagst du hingegen, ich möchte jetzt lieber Web-Components bauen.
Dann wirst du um eine Klasse schlecht herumkommen. Also die Welt da draußen wirkt ja auf deinen Code sich auch aus, würde ich sagen.
Das sind auch diese Workarounds, die mit diesen Takt-Template-Literals-Orbeten in Webcomponents nicht ausgegoren.
Also da kommst du an der Klasse nicht vorbei. Das Spannende ist sogar, dass...
Nicht ausgegoren, aber was Special Interest triggert.
Das ist nur ein Edicated Guessing. Wir reden ja davon, dass ich mich sowieso nicht mehr auskenn und eigentlich nur versuche, klug zu scheißen. Aber das ist... Entschuldige.
Also ich meine halt nur, so Workarounds, für was?
Also, so die meisten Web Component Libraries, die ich so sehe, die versuchen halt Web Components zu verwenden anstelle von einem Single Page App Framework, a la Angular oder React.

[11:26] Und die bauen dann halt irgendwie so Tech Template Tutorials, da schreibt es halt eben HTML Fragment dran, dann fabriziert ihr das halt irgendwie, ne?
Genau. Deine Output oder so. Ja, genau.
Ist ja alles irgendwie ganz nett, aber das ist meines Erachtens einfach ein Kategoriefehler.
Weil solche Konstruktionen sind eine Abstraktion über HTML Elemente, quasi ein Templating Mechanismus und Web-Components sind ein Mechanismus, um HTML-Elemente in die Welt zu setzen.
Ja, ja.
Korrekt. Und das kommt, glaube ich, aus der Ecke von React, wo du wirklich einfach die Idee ist, dass du HTML bündelst, weil du ja diesen Framework-Charakter hast.
Und eigentlich sollte genau das, was du sagst, schon vorher erledigt werden.

[12:05] Bevor überhaupt die Web-Komponente greift. Ja, genau.
Also was halt dem Web sozusagen fehlt, wäre halt ein Art Templating-Mechanismus.
Also so Handlebars-mäßig. Das würde halt diese Aufgabe, die ja eine Relevante ist.
Ich will halt einfach nur irgendwie sagen, es gibt da jetzt irgendwie so ein Widget und dieses Widget besteht halt irgendwie aus einem Diff mit drei Buttons drin, render das mal da rein.
Dafür gibt es halt eben keine native Lösung und Web-Components kann man dazu verwenden, aber es ist halt einfach schon so ein bisschen wie, keine Ahnung, ich fahre jetzt mit meinem Ein kaufen je nach gegebenheit markt funktionieren aber so richtig optimal ist das nicht.

[12:44] Für. Ein mensch wie mich der schon lange weg ist vor dem thema da gab es doch mal ein proposal das genau das versucht hat umzusetzen, so handelbar style templates, Im handelbar style templates oder natürlich gibt es auch bemühungen die, jsx syntax einfach sozusagen zu domestizieren, ja Also einfach als alternative Funktur für Funktions.
Da gab es ja sogar mal eine Implementierung von Firefox, nicht dieses...
Ah, e-Eggmascript. Ja, e-Eggmascript, genau. Eggmascript vor XML oder so, genau.
Genau. Gab's im Sinne von, das hat mal halt irgendwer mal aufgeschrieben, aber das ist glaube ich so aus den 2000ern, aus dem... Na, aber da gab's sogar eine Implementierung.
Das ist nicht nur irgendwo eine Idee, sondern da gab's eine Implementierung. Ist wahrscheinlich schon längst wieder rausgefallen.

[13:36] Ja, ja, das ist auf jeden Fall nicht mehr aktuell. So, was haben wir denn hier noch?
Ich hab letztens irgendwas gesehen, wo irgendwer was gebaut hatte, das finde ich jetzt eh nicht wieder, im Prinzip ein Proposal gebaut hat, wie man das in ECMAscript halt einbauen könnte. Man müsste halt irgendwie, also die Details entgehen mir da, weil ich da nicht tief genug drin stecke, aber de facto ist ja das JSX, so wie es heute ist, irgendwie relativ spezifisch auf React ausgerichtet in seiner ganzen Art und Weise, wie es funktioniert und wenn man das in Vue oder so verwendet, dann bringen halt diese ganzen Frameworks eine ganze Menge von Workarounds, damit hat irgendwie funktioniert. Aber so eine Art Mechanismus wäre halt glaube ich etwas was man mal machen könnte und was halt sicherlich auch sinnvoll wäre aber Web Components sind das halt eben nicht und deswegen ist das was du da so... deswegen war ich gerade so etwas etwas angepiekst von... Ja das stimmt. Du hast richtig mit der Ansage diese Workarounds greifen nicht, aber das Problem ist nicht dass die nicht funktionieren sondern das Das Problem ist, dass man das versucht.
Die Ausgangssage ist falsch.

[14:37] Genau. Eine andere Sache, die ich spannend fand, Nobby, du hast dem gesagt, man macht den React halt einfach nur Funktionen DJ6 auspucken. Früher hat es auch noch Klassen gegeben, macht man mittlerweile nicht mehr.
Aber früher war genau das in einer Komponente, in einer Klassenkomponente, du hast die Klasse geschrieben und du hast InternState verwaltet.
Macht sich ja Sinn. Tatsächlich ist ja eigentlich dieser useState Hook, der jetzt existiert, der ja grausamst implementiert ist, wo du halt einfach nur Glück hast, dass du tatsächlich den State zurückkriegst oder intern halt wirklich sehr stark wuchführen musst, damit du wieder die Komponenteninstanz zum State rückführen kannst.
Ist ja eigentlich abscheulich im Vergleich zu ich habe eine Klasse und mach einfach das Punkt x ist irgendwas. Also genau für solche Dinge wäre ja eigentlich eine Klasse das perfekte Mittel. Ja ja halt eben nicht, weil du halt eben Funktionalität nicht so gut teilen kannst. Also useState ist ein einmal implementierter unendlich oft recycelbarer Mechanismus. Das kannst du halt mit normalen Klassen nicht machen, es sei denn natürlich, Ustate wäre ein Dekorator. Ha! Bingo! Ah, cool und wieder zurückgeführt.
Also, haha. Ich meine, ich meine, das ist ja genau das Ding. Die adressieren das gleiche Problem.
Die beiden Mechanismen. Da machst du einfach add tracked drauf oder sonst irgendwas, fertig.

[15:57] Ja, genau. Und dann weißt du halt eben, ah, okay, ich muss halt irgendwie da Mechanismen generieren, um halt irgendwie diese private Variable zu ändern. Wenn die sich ändert, mache ich halt irgendwie meinen wie auch immer in der Klassenmethode implementierten Vergleich. So, entweder mache ich irgendwie einen Deep Compare oder ich mache halt so einen Shallow Check, weil Immutability und Zeug und dann weiß ich halt eben, ob ich mich neu rendern muss oder nicht. Wunderschön. Könnte ich mir vorstellen, dass das funktioniert, weil also ich glaube nicht, dass ich jemals in ReactUseFact richtig verwenden würde, wenn ich nicht irgendwie eher es lint hätte, dass mich permanent anplärt.
Ja, ja, ja. Und wobei es dann die Brücke auch zwischen Framework Code und anderem Code einfach leichter, weil die Grenze zum Framework eindeutiger wird. Also dann brauchst du diese Use Effect Workarounds nicht, wie du gesagt hast, und dann kannst du auch imperativen Canvas Code zum Beispiel schreiben in einem deklarativen Universum.
Halleluja, das wäre ja mal was.
Ja, wow.
Dieses witzige Weis, ich habe immer so diesen Softspot für die Ember Menschen, das ist ja das, was Ember eigentlich machen wollte. Aber sie haben halt einfach nicht das richtige Markthilm gehabt dazu.
Nicht das richtige oder nicht genug? Das trau ich mir jetzt nicht sagen.
Was haben die denn so an Corporate Backer?
Also den von React kenn ich, der ist ziemlich groß und hat ziemlich tiefe Taschen.
Ja, und da ist einfach das Outlet vor Skylight am kleinen Ruby und Rails Monitoring Shop.

[17:22] Wobei ja dann einer der größeren Backer LinkedIn war. Vielen Dank für's Zuschauen!
Okay, groß. Und die aber jetzt auch mittlerweile Alternativen suchen, meine, meine noch. Ja, okay. War mir auch zum Beispiel gar nicht bekannt, was ja auch schon für sich spricht. Ja, das zeigt das Symptom wieder recht gut. Zu den Decorators hätte ich noch eine Anmerkung, wo ich glaube, dass das tatsächlich auch ganz eine ganz gute Rolle spielen könnte, weil jetzt unser hypothetisches State Management in React, das jetzt die Klassen wieder belebt, ich meine, das wäre ja eigentlich ganz gut, wäre ja relativ on-brand, was so JavaScript angeht.
Klassen sind das Mittel der Wahl. Nee, Klassen sind jetzt doof und riechen nach Luluh. Nee, jetzt haben wir wieder Klassen.
Man bittet ja, lass das Pendel schwingen. Wir brauchen das, ansonsten stirbt die Programmiersprache. Wenn es nicht ständig Meinungen gibt von Richtung 1 nach Richtung 2, dann schreibt keiner mehr JavaScript.
So sieht es nämlich aus. Naja, also da glaube ich jetzt nicht unbedingt dran, dass das passieren wird. Die sind mit ihrem Krams hier schon ganz gut bedient und Zeug.

[18:25] Das ist nicht passiert genug. Ne, aber tatsächlich glaube ich, das könnte ein nützliches Werkzeug sein, um tatsächlich Web Components Library gestützt zu bekommen. Weil Web Components sind ja notwendigerweise Klassen. Man muss ja immer von HTML Element extenden, damit man halt irgendwie bei den Build-Ins, also sowas wie HTML Element und HTML Diff Element und Zeug, Die sind ja nicht wirklich Klassen, das sind ja irgendwelche Build-ins, aber wenn ich von denen extende, triggern die irgendwelche Logik.
Und um mich halt irgendwie da ranzuklingen, muss ich halt eben das machen.
Und bei den Decorators ist es halt, glaube ich, so, dass so HTML-NAS-Verhalten tatsächlich in Form von einer Microlibrary bereitgestellt werden könnte, die einfach nur besteht aus einem Haufen von Decorators, womit ich dann zum Beispiel sagen kann, es gibt hier irgendwie Excessor, irgendwie auf meinem HTML Element, ist jetzt irgendwie so ein Feld Disabled und da kann ich dann halt wirklich so Dinge machen wie, dass die entsprechenden Getter und Setter fabriziert werden und das Attributänderungsmonitoring und das alles einigermaßen einheitlich wird, dass ich einfach deklarieren kann. Ich habe jetzt hier zum Beispiel ein Attribut, so was wie Disabled und das ist ja eigentlich ein Boolshes Attribut. Also das ist entweder da oder nicht da, aber was Das ist dann zum Beispiel, wenn ich sowas sage wie Disabled gleich False.

[19:45] Wie will ich das bewerten also wenn man jetzt ganz nach der reinen leere geht würde man wahrscheinlich sagen das meint dass das ist ablet attribute gesetzt ist auf true weil es ist ja auf was gesetzt also es ist da.
Möglicherweise will man das ja irgendwie komplizierter gestalten content edit ist ja auch so ein ding da drin oder.
Attribute die halt mehr so eine art in am state haben mit drei möglichen werten oder so das ist alles.
Irre kompliziert, auch irgendwie sowas, verarbeitet diese Zahl, dieses Attribut als Zahl.
Ich kann ja jedes HTML-Attribut alles reinschreiben, was ich lustig bin.
Käsekuchen, interpretiere das bitte schön als Zahl.
Wie soll das gehen? Soll da noch der Number rauskommen oder soll da, wenn da noch der Number rauskäme, irgendwie null rauskommen oder irgendwie so Krams, ne?
Wenn man das einmal schreibt, ist ja gut, aber wie recycle ich das in, wenn ich jetzt drei Komponenten habe und die haben alle drei Attribute?
Das ist halt im moment wirklich nur möglich indem ich das alles von hand aufschreibe und in den jeweiligen gettern zettern attribut händler diese.

[20:39] Ganzen inputs durch entsprechende parsing funktionen durchschicken und wenn das alles dekorators werden dann wäre das echt weniger schlimm als es jetzt aktuell ist oder das klingt ja klassisch schreibe ich einfach drüber ad web component und dann macht das ding automatisch ein so ein define mit der component registry aber nur wenn es ist schon gecheckt hat bin ich definiert oder nicht und so zeug das könnte alles das ist genau das was litt macht nicht dieses komponent web component framework die machen genau das du kannst et custom element schreiben mit dem tag name und, die klasse drunter wird als custom element registriert oder du hast am property decorator mit dem wird, das mapping zwischen html und deiner dem steht einer klasse gemacht also die richtung gibt schon aber jetzt gibt es das halt nach tiefen Schauskripten.
Erstens das und zweitens ist dieses Lit Zeug halt wieder ein komplett Buy-in, wo ich halt nicht nur ein paar Funktionen habe, sondern ich muss halt eben diese Klasse extenden von denen.
Dieser Custom Element Decorator.

[21:40] Denn würde ich mir zutrauen, ihn in der nächsten halben Stunde zu schreiben.
Und dann funktioniert er, dass du, wenn du da irgendein Element hast, das du ableitst, dass du das registrierst.
Ja, das ist tatsächlich ein Zehntseiler, den habe ich hier irgendwo rumliegen.
Cool, erster Framework Code ist da. Und dann hast du dann Bunch of Decorators und haust die rein und schreibst einfach schöner.

[21:59] Genau, und das ist halt eben kein Framework, sondern ist halt mehr so eine Art Lowdash.
Also, greif in diesen Werkzeugkasten rein und du willst irgendwie einen Attribut haben, dass irgendwie sowas wie Content Editable ist, nimmst du das, willst das Ding als Custom Element definieren, nimmst du das.
Aber es ist halt immer noch eine Web Component und du könntest jederzeit jede von diesen Funktionen ersetzen oder sein lassen, deine eigene daneben schreiben, das Ganze irgendwie rappen.
Es wäre halt tatsächlich modular. Es wäre halt, ne, nach der Idee von useState, wo halt eben es auch Libraries von Hooks gibt da draußen für React, könnte es halt eben Libraries von Attributimplementierungen geben.
Und das muss alles gar nicht groß zusammenspielen, weil es halt einfach nur, Dinge dekoriert, also Dinge, die ohnehin da sind, in das ohnehin vorhandene, in die ohnehin vorhandene Mechanik für Web Components einbindet. Und ich denke, das ist schon ziemlich was wert. Gekauft will ich haben.
Absolut. Okay, ich arbeite halbwegs ich dran. Ja, bitte. Das erste, was du brauchst, ist ein Name und das zweite, was du brauchst, ist ein Gizabrepo und dann weiß ich's. Dann kommen nicht die Contributor.
Ja, dann kommen die Contributors, dann haben die Bugs und dann muss ich das fixen.
Und dann hab ich auch da Issues, wo drin steht, ist das schon tot?
Und ich so, nee, ich hab halt nur auf was anderes zu tun.
Das sollten Leute mit stabileren Nerven machen, als ich das bin.
Aber, ja.
Und dieses Interludium wurde Ihnen präsentiert von Burnout-Gefährdeten in 30ern, Anfang 40ern. So ist es.

[23:25] Aber, nächste Punkt. Nächster Punkt. Hey, Stefan. Ja.
Wie viele Use Cases für das Keyword Konst gibt's in TypeScript? Go! Um...

[23:34] Gibt aber, ein spannendes Thema ist, also das const-Keyword existiert in JavaScript und in TypeScript.
In JavaScript definiert es ein konstantes Binding.
Das heißt, du hast jetzt nicht ein variables Binding, wo du den gleichen Namen neu zuweisen kannst, sondern du hast ein konstantes Binding. Das heißt, die Zuweisung ist erfolgt.
Das heißt, du kannst nichts mehr ändern. Wenn du jetzt einen primitiven Datentyp hast, wird er nicht geändert.
Wenn du einen komplexen Datentyp hast, wie ein Objekt oder Array, dann kannst du zu einem neuen Element ändern, aber nicht mehr vom Objekt auf etwas anderes.

[24:06] Das ist der JavaScript Teil und das gibt es auch in TypeScript als Typ Modifier und es gibt es als Typ Assertion.
Da fällt mir gerade der deutsche Name dazu nicht ein, wo du sagen kannst, hey, dieses eine Objekt, dieses eine JavaScript Objekt oder diesen einen JavaScript Wert nennen wir mal so, behandle ich im Typ System als Literal Wert.
Das heißt, TypeScript ist das so. du hast ein Typ und zu diesem Typ passt eine Menge an möglichen Werten und dieser Typ kann sehr breit sein, diese Menge kann sehr groß sein oder dieser Typ kann sehr schmal sein, also die Menge kann sehr klein sein und mit s-Konst fixierst du den Wert, den du gerade hast, als diesen einen Wertetyp.
Das heißt, der kann keine andere Form annehmen. Zu dieser Menge ist nur ein einziger Wert kompatibel und das ist der, den du gerade definiert hast. Und das ist toll, das ist großartig, falls du wirklich auf diese Werte typen zugreifen willst, wenn du die tatsächlichen Strings, die tatsächlichen Nummern brauchst und nicht einfach jeden String oder jede Nummer, du entsprechende Keys vielleicht brauchst von deinem Objekt, dann hilft es, dass du einfach sagen kannst, hey, mit s-Const hat dieser Wird die Bedeutung, dass er sich nicht ändert?

[25:28] Und ist dem Typ-System auch als Rotkrist zu behandeln. Genau.
Und dieses Konst-Schlüsselwort aus dem Typ-System findet jetzt Einzug in GenericType-Parameters.
Das sind Generics, wo du sagen kannst, hey, du hast hier dieses eine T, diesen generischen Typ.
Aber wenn dieser Typ kommt, dann behandle ihn als Konstant.
Das geht teilweise schon mit primitiven Werten sehr, sehr gut, wo du einfach sagst, du fügst jetzt tatsächlich den literal string Stefan zum Beispiel ein für dieses t, dann ist es auch dieser Wert und es kann nur mehr Stefan sein und es kann nicht string werden unter.

[26:06] Gewissen Voraussetzungen. Wenn du dort noch jetzt zum Beispiel ein String Array hast, du hast jetzt Stefan und Peter in einem Array, dann merkt TypeScript Theo es ist doch eher ein String Array, weil das ist wahrscheinlich das nächste was du machen möchtest. Und mit const t kannst du jetzt hey, nein, wenn ich dort das Array-Steffen und Peter reingebe, dann behandle ich das auch als das Array-Steffen und Peter. Das ist so die Idee. Und es gibt aber ganz coole Use Cases dafür.
Eine, die ich gesehen habe ist zum Beispiel, du hast einen React-Router, jetzt haben wir wieder in dieser Ecke gelandet, wo du halt deine ganzen Routes definierst in einer Funktion, defineRoutes, da hast du mit einem const t die ganzen Routen definiert und dann willst du eine Methode schreiben oder eine Funktion schreiben, wo du von einer auf die andere dich bewegen kannst, über JavaScript, dann kannst du halt dort ein Autocomplete kriegen für genau die Einträge, die du Daten eingegeben hast. Ist recht nett.

[27:02] Hab ich was vergessen? Ja, Konstiganz.
Okay, cool. Ah, ja gut. Ja. So, wenn ich vergessen bin, hab ich verdrängt.
Wir können später nochmal was über ihn am reden. Aber ich meine, die wichtigen Use Cases, die wirklich Menschen nutzen, sind tatsächlich ja die, die Konstvariable und die Konst Assertion und das jetzt Konst im Typparameter, was das ja im Prinzip bloß ein Mechanismus ist, dass man den Effekt von S-Konst kriegt, ohne dass diejenigen, die das am Ende aufrufen, das immer dahinschreiben müssen.
Ist ja im Prinzip bloß sozusagen eine Justage der Typ-Inferenz.
Normalerweise würde ja die Typ-Inferenz sagen, irgendwie, hey, hast du dir ein Wert reingesteckt?
Ich interpretiere den jetzt mal so großzügig, wie ich kann.
Das ist ja das Type-Widening und S-Konst macht ja im Prinzip das Gegenteil.
Interpretiere das so engstirnig, wie ich kann. Also Array von drei Strings ist halt eine Liste von exakt den drei Strings in der Reihenfolge und nichts anderes. Aber dazu muss ich ja als Const irgendwo da reinschreiben und wenn eine Funktion will, dass irgendwelcher Input so engstirnig interpretiert wird, kann das jetzt halt eben in Typparameter wandern und dann steht halt eben das Const auch noch möglicherweise da oben drin. Genau. Ja, ist, sagen wir so, ist, ja.

[28:21] Ja finde ich gut also ich habe ich hatte noch keine use cases dafür aber jetzt wo ich es hier was das zu fallen use cases sein das ist immer gutes zeichen wenn ich vorher keinen leidensdruck hatte und dann plötzlich wird er entwickelt indem ich erstmal was sehe.

[28:41] Frage ich mich ob da wirklich ein problem gelöst wird oder sozusagen hier hier hast ein problem und die lösung verkaufe ich dir gleich mit also ich sehe das gerade bei diesem feature eher so es macht einfach sinn oder es ergibt sinn dass das ding auch in generic type parameters landet es ist es macht das typ system meiner meinung stimmig meiner meinung noch stimmiger weil warum soll soll nicht die gleichen regeln innerhalb von generischen typ wie Brameter gelten wie außerhalb.

[29:09] Und deswegen macht es für mich absolut Sinn. Das ist eine ganz, ganz saubere Lösung dafür, dass es, dass ein fehlendes Puzzleteil dazu gebracht worden ist.
Ja, und das macht natürlich auch einen möglichen Verwirrungspunkt für weniger informierte Nutzerinnen und Nutzer weg, den du dann ja nicht mehr sagen musst. Schreibt es konstanter, dann funktioniert es.
Ja. Dass es ja nicht offensichtlich ist und nicht alle haben auf dem Schirm, was das tut.
Sozusagen die Arbeit verfrachten zu denen, die unter diesen Umständen halt arbeiten wollen, also Autoren der Funktion, macht halt insofern schon Sinn. Es macht es halt tatsächlich auch relativ, sagen wir mal, macht es halt relativ wortreich. Also so ein Typ Parameter kann ja schon sehr wortreich sein. Und wenn ich jetzt hier so sehe, Konst T, Extents Read Only, irgendwas.
Ich bin da, wie sagt man das, kampfgeprüft, ich schreibe Last. Also was da im generischen Umfeld passiert, das ist wild.

[30:13] Generic Constraint plus Cent plus Sync plus Tick Static. Und du brauchst eigene Zeile dafür und es gibt Sündtags, dass du das in eigene Zeile packen kannst.
Also du wirst irgendwann mal.
Irgendwann freust du dich, wenn du ein einfaches Konstigstens schreiben kannst. Also, ja.
Kleine Typ-Systeme haben alle für und wieder. Absolut. Ja, ich würde tatsächlich auch sagen, das ist sozusagen, auch wenn ich persönlich nicht vom Hocker gehauen werde, weil ich vorher keinen Leidensdruck hatte, würde ich zumindest sagen, für die meisten Entwicklerinnen und Entwickler, hat das keinen Effekt, und das ist gut so.
Die meisten werden davon profitieren, ohne das sozusagen im Arbeitsspeicher ihres Hirns haben zu müssen.
Mhm.

[31:00] Das ist was anderes als Decorators, das ist ein Feature, mit dem man sich auseinandersetzen muss.
Mit hier hast du weniger Notwendigkeit, überall es konntest, hinter zu schreiben und das ist ja eigentlich gut. Genau. Cool. Cool. So, das sind wohl glaube ich die beiden Flagship-Features aus dieser Release. Ja, ich schaue gerade auch über diese Liste drüber.
Es gibt, das sind die beiden Flagship-Features, es gibt dann sehr viel Compiler-Fu oder so Projektzeug, wo du die Projekte besser konfigurieren kannst und Tooling, wie auch immer, also dass du bessere Unterstützung im VS Code und so weiter hast.
Aber es gibt einen Feature, der ist noch sehr sehr interessant, ist eben diese 5.0 Veröffentlichung rechtfertigt meiner Meinung nach.
Und das sind diese Inums. Und ich glaube, über das möchte ich noch mal ganz kurz reden. Schließ los.
Also Inums sind ja ein bisschen so, kommt davon, woher du kommst natürlich, aber Inums sind ein sehr gern gesehenes Feature, je nachdem, woher du kommst, weil sie erlauben dir, dass du mit einer schönen Syntax mehrere Varianten, also mehrere Ausprägungen eines Typs definieren kannst. Es gibt Nummern-Inums und String-Inums in TypeScript. Nummern-Inums ist halt wirklich Enumeration so im klassischen C-Sinne, wo du jetzt sagst, du startest bei 0 und zählst weit hoch und hinter einem sprechenden Namen steckt halt ein Zahlenwert und das kannst du verwenden, um diverse Dinge zu lösen. Oder die String-Enam sagt einfach hinter einem.

[32:29] Feld oder hinter einem Property oder hinter einer Ausprägung steckt ein Stringwert und das kannst du dann so lösen. Das kann man nicht mischen. Und eigentlich schöne Syntax mit, Kunst innen, das ist eben das fehlende Kunst, verschwindet das sogar nachher nach dem Typ, nach dem Type Check, also nach dem Compile Schritt ist das weg und da hast du eigentlich keine Spuren mehr davon. Aber sie kommen mit einigen Einschränkungen mit, bis jetzt. Oder sagen wir so nicht mit einigen Einschränkungen, mit einigen eigenen Eigenschaften, genau Eigenheiten, die einfach im Sinn vom TypeScript Typ System nicht mehr richtig sind oder herausstechen, sagen wir mal so. Punkt Nummer eins bei den Number Enums, sie sind nicht Hypsif. Das ist das, was mich einmal total vom Hocker g'haut hat, weil du kannst dort beliebige Zahlen definieren, aber du kannst dann, wenn du irgendwo ein Enum als Funktionsparameter erwartest, einfach jede x-beliebige Nummer reingeben, weil in der originalen Spezifikation für Enums vorgesehen ist, dass du auch mit diesen rechnest. Dass du sagst, du machst jetzt eine Bitmaske und machst Bitvergleich zwischen Eintrag A und Eintrag B und da kommt dann eine Zahl aus, die du nicht definiert hast, aber die muss genauso gut funktionieren. Okay.

[33:44] Spannende Use-Kits hat es sicher mal gegeben, aber der Punkt von TypeScript war, damit Sie diesen Use-Kits unterstützen können, lasst mir einfach jede beliebige Zahl zu.
Das heißt, Number-Inams nicht typsicher.
Also das eine. Das andere String-Inams, wo jetzt zwischen hinter jedem Wert ein Stringwert steht.

[34:02] Das sind die einzigen nominellen Typen in TypeScript.
Also TypeScript hat aus Druck für Redes Typsystem, das heißt, so wie der Wert gleich ist, geht man davon aus, dass auch der Typ gleich ist, das passt.
Wenn du aber jetzt zum Beispiel in eine String-Innam schreibst, die heute zwei Ausprägungen hat, ab, und dann schreibst du eine zweite String-Innam auch mit einer Ausprägung ab, dann sind die nicht zueinander kompatibel.
Und das ist wie gesagt das einzige nominelle Feature in TypeScript.
Und bricht halt einfach auch mit der Idee vom strukturierten Typ-System.
Jetzt gibt es Änderungen in den Innams.
Wir einführen natürlich auch Runtime-Artifakte aus TypeScript und Tux, die jetzt keine ECMAScript-Entsprechung haben, was normale Inams ja machen. Die Pulsat sind ja wirklich eine Runtime-Lookup-Table.
Ist auch nicht mehr in dem Vibe, den TypeScript heutzutage verfolgen möchte.
Genau. Genau, weil TypeScript ja nur diese dünne Leer an Typinformation ist. Ist ganz richtig.
Es gibt jetzt ein paar Änderungen. Zum einen, Number-Inams sind jetzt nicht mehr oder können jetzt nicht mehr.

[35:09] So breit genutzt werden wie vorhin. Das heißt, wenn du eine NumberInnum hast, dann muss auch tatsächlich ein Innam-Wert reingegeben werden. Das ist einmal das eine, das passiert. Das ist schon mal richtig, richtig gut. Und das andere, das passiert, das auch sehr spannend ist, ist, dass die Einträge einer Innam, egal ob das jetzt NumberInnum oder StringInnum ist, jetzt als Einträge eines Union-Types zu werten sind. Das heißt, die können jetzt als Typ wiederverwendet werden. Das heißt, es ist ganz easy, dass du noch einen Union-Type schreibst, der auf die gleichen Felder zugreift und mit denen noch kompatibel ist.
Aber ist ein Inam als eine Auflistung von Werten nicht das Gleiche wie eine Union, was eine Auflistung von Werten ist? Ja.

[35:51] Meine Meinung nach schon. Warum würde ich das dann machen wollen?
Das verstehe ich nicht ganz. Also die lösen beide das gleiche Problem.
Eine Union und ein Inam lösen das gleiche Problem. Warum brauche ich denn denn Inams?
Also für was sind die gut?
Eigentlich für nichts. Die sind eine Relikt aus alter Zeit.
Aber die Änderungen, die jetzt dort sind, gleichen sich schrittweise dem Verständnis vom Typ-System heute an.
Das ist das, was ich eigentlich damit sage.
Und darum finde ich die Änderung gut. Ich würde immer noch keine Inams nehmen.
Es gibt einen Pattern, das kann ich gerne in die Schau-Notizen packen.

[36:24] Das ich ja in meinem Blog beschreibe, wo du mit einem JavaScript-Wert und einem davon abgeleiteten Typen das gleiche Verhalten erzeugen kannst, aber du 100 Prozent beim Typ-System bist und die gleichen Eigenschaften hast und die gleichen Features hast und die gleichen Typechecks hast.
Und das Schöne ist jetzt mit dieser Änderung in Inams ist der Unterschied zwischen diesen Dingen nicht mehr so groß.
Du hast immer nur die nominellen Features und das kann tatsächlich etwas sein, wo ich mir denke, okay, das will ich, wenn ich sicherstellen will, dass es einen Unterschied gibt zwischen Inam A und Inam B, dann ist die Inam das einzige, mit dem du das machen kannst.
Aber ansonsten ist die Angleichung zwischen diesen Welten besser. Und wenn du irgendwo Inam Union Werte erwartest, dann kannst du auch von einer Inam, die vielleicht schon in deinem Code existiert, leichter hingehen. Also der Migrationsschritt ist meiner Meinung nach.
Und deswegen bin ich happy, dass dieses Feature kommt. In Wirklichkeit hätte ich gern ein Feature, das man sagt, disallow Enums im Compiler und sie verschwinden. Das wäre das Allerbeste.
Aber zudem lassen sie es nicht hin. Weil, meine Meinung nach, werden sie zu stark genutzt.
Also ich habe Projekte, die ich sehe, wo Enums teilweise den Compiler in die Knie zwingen, einfach nur durch deren bloße Existenz. Ach, sind die so aufwendig?
Ja, wir haben ihn mit 2000 Einträgen.

[37:46] Autogeneriert für irgendeinem Code Generator. Aber wäre eine Union mit 2000 Einträgen dann besser?
Ja, wäre besser wegen der Syntax, weil nicht sofort alle Einträge evaluiert werden müssen, sondern nur der Typ Check interessant ist. Aber wenn du eine Inam definierst, dann muss die ganze Inam gepasst werden, damit überhaupt mal bekannt ist, was da ist.
Und weil du ja Syntax zur Verfügung stößt, mit der du das nutzt.
Und das ist einfach bei 2000 Strings in einer Union ganz was anderes.
Also da muss ich einfach sagen, hey da ist der Typcheck schon, bin ich dort drinnen.
Der Ray includes ist halt so schnell wie dein Compiler. Aber das Ganze aufzubereiten, puh, schwierig.
Meistig aus Erfahrung, hat für irrsinnig viel Diskussion gesorgt in einem Projekt, in dem ich mal wieder da war.
Okay, finde ich gut. Ich nehme gerne immer weitere Munition gegen Inams zur Hand.
Damit ich da pro Union argumentieren kann. Nehme ich gerne mit, war mir gar nicht klar, aber ist logisch.
Kunst ändert auch nichts dran. Das ist nämlich auch witzig. Also die Inam frisst einfach Kompilzeit, egal ob so Kunst Inam ist oder nicht.
Das ist interessant. Das hätte ich jetzt auch nicht unbedingt erwartet, aber macht ja immer noch irgendwie Sinn, auch wenn es halt ein Artifakt macht. Das ist jetzt das einzige, was Kunst Inam tut. Ich kenne ihn auch.

[39:07] Das sind meine Two-Sense dazu. Also ich bin froh, dass das Ding existiert.
Also diese Annäherung existiert. Es macht sicher einige Dinge einfacher und es sorgt nicht mehr für so viele Verwirrungen.
Also das war eigentlich das größte Problem, wo du gehst halt dann innerhalb deiner Inam aus, wenn du zum Beispiel das Which-Case-Statement machst bei einer Number-Inam, dann musst du jeden Case betreuen und dann hast du halt bei einer Inam mit drei Einträgen, hast du halt nur drei Cases und das Problem ist aber, dass von oben viel, viel mehr reinkommen kann.
Bitter, dass du diese Typ-Sicherheit nicht hast. Ja. Weil das willst du ja von TypeScript, zu dem existiert es. Und das kann ich dir nicht bitten und das ist halt traurig.

[39:45] Ja gut, okay. Dann wärme ich mich so langsam gegenüber dem Feature auf. Ich meine, das löst immer noch ein Problem, das am besten Fall gar nicht da ist, aber das kann man sich ja nicht ausprobieren. Aber hey, du weißt, du kennst die Ursprünge von TypeScript, das war jetzt sehr stark angelehnt. Ein Objekt orientierte Programmiersprachen, wie es hier schafft.
Wunsch für Java-Entwickler, die jetzt Web machen müssen.
Ja, genau. Und ich meine, wer hat's denn geschrieben? Das war irgendwie vorherzusehen und das ist ja jetzt nicht das Problem, sage ich jetzt mal. Und das Problem ist, wirst du auf lange Sicht damit umgehen und da hat es ja schon viele, viele Annäherungen gegeben. Namespaces haben nimmer die Wertigkeit wie vorher, Modules haben nimmer die Wertigkeit wie vorher, da gibt es jetzt einfach die ECMAScript Modules, die Triple Slash Directives haben nicht mehr die Wertigkeit wie vorher und jetzt endlich haben Inams auch nicht mehr die Wertigkeit wie vorher. Es ist eine weitere Annäherung und das ist immer das Beste, um über kurz oder lang wegzukommen davon und deswegen ist gut, dass es jetzt per Default in 5.0, sind es vorhin von Inams ändert, weil noch jeder und jede hoffentlich merkt, dass der Einsatz einer Inam es wahrscheinlich nicht wert ist. Also notwendige Vorarbeit für möglicherweise eines Tages wirklich das Compiler-Flag.
Genau, das wäre meine Hoffnung.

[41:02] Gut, die restlichen Features, so irgendwie JS-Doc und so Zeug, haut mich jetzt auch nicht vom Hocker, irgendwie exportiert.
Na, in guter Style, danke schön. Vielleicht mal verwenden, irgendwie so Multi-Extension-Config-Files, ist ja auch nur, was man sowieso haben möchte.
Ja, mit dem Release von dieser Revision, also wenn ihr das hört, sollte das TypeScript 5.0 veröffentlicht sein.
Falls ihr es anders seht, falls ihr große Inams-Fans seid, lasst es uns wissen.
Verfolgt uns auf Twitter und wenn es das noch gibt zu dem Zeitpunkt, wir nehmen das deutlich vor der Veröffentlichung aus, also wer weiß was sich der Elmo bis dahin noch ausdenkt. Ansonsten gibt es uns ja auch noch auf Mastodon und unseren Slack-Channel Community Draft gibt es noch. Also lasst uns wissen, überzeugt uns davon, dass Inams voll gut sind und wir komplett falsch liegen.
Ich wäre sehr interessiert an diesbezüglichem Input.

[41:55] Stefan, es war mir wieder ein großes großes Vergnügen. Ja, es war ein Volksfest.
Danke fürs Zuhören. Wir sehen uns dann in dieser Konstellation nächstes Quartal wieder, wenn es dann um TypeScript 5.1 geht.
Bis dahin, danke fürs Zuhören und Tschüssi.
Ciao!

Random Bonus Track


[42:29] Das passt. Also ich hab so ein fancy neues Mikro. Und das steht jetzt auf so einem Stand und da muss ich immer ganz nahe hingehen, damit man mich auch anständig versteht.
Und ich hoffe das passt. Und die darf nicht so am Sessel hin und her rutschen.
Ach so, ein bisschen Rassel und Ambience und so Knarz kommt da schon rüber.
Okay. Das ist wahrscheinlich das Bewegen.
Das ist wahrscheinlich... also ich habe jetzt gerade auch das Mikrofon gestreichelt, weil ich Staub entfernt habe.
Das ist natürlich auch Knarz. Das muss ja sein. Das wäre dann das hier.
Ja, genau. Man muss das Mikrofon ja streicheln, damit es hinterher schön zart wird.
Genau, ganz genau. Ich streichle jetzt nicht mehr, es ist genug gestreichelt.
Gut.
Jetzt sind drei Minuten drin und schon eine ganze Outtake Sendung geschafft.
Ich glaube, so viel haben wir jetzt ja gar nicht mit aufgezeichnet.
Außerdem, was erwartest du auch, wenn hier die beiden Clowns vom Dienst in der Sendung sind?
Ah ja. Verdammt. Ja, es ist cool, dass ich wieder mal dabei bin.
Ich bin eh so komplett weg eigentlich davon, weil Kinder und alles und alles eigentlich.
Das ist jedes Problem. Ja, ich war ja auch weg, aber...

[43:42] Irgendwann haben dann die Katastrophen aufgehört sich sozusagen aufzutürmen und nachdem dann sozusagen genug davon abgetragen war, dass man auch mal wieder was anders machen konnte, geht auch mal wieder was in Richtung Podcast.
Ich hab keine Ahnung wann dieser Zeitpunkt bei mir sein wird.
Vor allem diese regulären Mietungen. So auswärtig wie das geht, das passt.
Aber ich sehe bei meinen Kindern keine Chance, dass die Abendrituale sich zu meinen Gunsten in den nächsten Jahren verändern werden.
Ja und das muss ich heute mal fressen.
Ja ich mein man könnte ja hin und wieder auch mal bei äh also zur Diskussion stellen, ob vielleicht ein anderer Zeitslot, ein anderes Aufnahmeregime vielleicht...
Ja aber da bin ich tatsächlich auch, sag mal, der weakest link und das ist okay.
Es ist ja auch sogar so, dass ihr von uns jetzt am wenigsten Ahnung habt vor dem ganzen, weil ich einfach schon so lange nichts mehr gemacht hab in dem Bereich.
Also da haben Leute wie die Vanessa einfach viel mehr Insights und die Vanessa kennt sich irrsinnig.
Jedenfalls muss ja der Übernerd sein. Also ich meine.

[44:46] Ja, so generell Hugscheißen geht schon. Es ist ja nun tatsächlich so, ich weiß ja nicht, ich glaube wir sind ja ungefähr gleich lange, also wir sind ja zu ungefähr gleichen Zeitpunkt haben wir ja die Segel gestrichen und haben gesagt so Podcast bestellen wir jetzt mal hinten an.
Da hatte ich ja in der zeit tatsächlich auch ein etwas anderer vibe in den sendungen niedergeschlagen, Ich weiß nicht, wie kein Zeug gehört. Ich sehe mir immer so leid wenn ich dann sendungen höre wo ich nicht dabei bin Ne aber das sind halt dann so sachen drin wie irgendwie tech recruiting imposter syndrome ausbildung.

[45:21] Oder halt so kram wie die backup revision war auch eine ganz neueste weil da war halt einfach nur so ein Typ dabei, der hat halt über Backups erzählt und Backups Das betrifft dich halt, ob du jetzt irgendwie web machst oder nicht, ja ohnehin immer.
Oder die aktuelle wo hans und ich da über ai debattiert haben.
Das kannst du ja immer machen.

[45:44] Ja stimmt. ich glaube der hans selber steckt ja auch nicht mehr ganz so tief im schützengraben drin wie das schon mal der fall war.
Da würde ich mich jetzt nicht von abhalten lassen, von wegen keine ahnung haben.
Weil wenn du keine ahnung hast, hast du eine meinung. und wenn du keine meinung hast, kannst du immer noch witz machen.
Meinungen habe ich viel. wo ist denn scheiß?
Was? Mein Hauptmeinung gerade überwandt.
Ja, gut. Das führt uns ja mehr oder weniger direkt in den TypeScript rein.
Ja. Na, aber jetzt streiten sie wieder.
Die Communitys, die React-Community bettelt sich jetzt wieder mit der traditionellen Web-Dev-Community, weil irgendwer gesagt hat, hey, Server-Set-Rendering ist total cool. Und jeder sagt, ja, ist eh cool.
Das ist man seit 10 Jahren.

[46:35] Und das sind so mühselige Diskussionen. Wird er denn zurückgebattelt?
Also ich sehe das jetzt eigentlich, das mag auch daran liegen, wen ich da verfolge, aber ich sehe halt die Traditionenlisten, die halt eben in letzter Zeit echt die Samthandschuhe abgelegt haben.
Also kommt da aus der React-Seite irgendwas zurück? Ich nehme die ja nicht wahr.
Nein, die React-Seite ist, also das Thema, das ich jetzt sehe, das ist auf Mastodon, und die React-Seite ist nicht auf Mastodon, die ist immer nur drüben.
Und die Meinungen sind unterschiedlich, je nachdem, welche Seiten du aufmachst.
Die Trommeln schlagen schon sehr laut gerade im Moment. Ich finde, ich bin dieser Diskussion überdrüssig.
Das ist die ehrlichste Antwort, die ich geben kann.
Ich bin letztens auch zu dem Ergebnis gekommen, aber ich denke, lasse halt die Reaktleute so ein bisschen spielen.
Ich hab letztens hier mal so geguckt, was können die eigentlich bei PHP mit ihren Server-seitigen Frameworks oder so?
Und da hab ich dann irgendwie Laravel aufgemacht und einfach mal so, okay, hallo Welt und Zeug.
Und nachdem ich jetzt ja was betreibe, was so mit Next.js gebaut ist, wenn ich das so vergleiche mit dem, was mir da PHP liefert, also wo ich weder die Sprache noch das Framework kenne, aber wenn ich einfach so auf drei Knöpfe drücke und irgendwie alles ist da, was ich brauche, was ist, ich muss halt irgendwie ein extra Modul für Session-Management installieren auf eine bestimmte Version fest pinnen, damit das im Zusammenspiel mit Next.js und dem und jenem und und solchen irgendwie funktioniert. Versus, das geht einfach.

[48:05] Ja okay, es wird jetzt auch serverseitig gerendert, aber ich kann ja auch serverseitiges Rendering haben, ohne irgendwie groß was dafür zu tun und das ist schon echt ein bisschen armselig, was man da so in JavaScript-Land geboten bekommt.
Richtig einsteinisch.
Du hast da auch die Königin der Frameworks ausgesucht, weil Laravel ist halt wirklich krass, was das angeht.
Also die machen irrsinnig gute Sachen.
Und es gibt einen Kollegen, den Christoph Rumpel, der war ja schon mal bei uns, der sich viel damit beschäftigt und da immer so Code Screenshots rauf stellen, wo man denkt, da ist ja kein Code drauf, das sind ja drei Zeilen und du hast einfach diese Funktionalität implementiert.
Und dann komme ich her bei meinen Ras Snippets, der alles so, ich hätte bitte gerne größere Screenshots oder könnt ihr bitte diese Tweets nur auf einem 28 Zoll Monitor anschauen, weil ansonsten seht ihr halt einfach nicht, was ich da geschrieben habe.
Das ist schon beeindruckend, da wird wirklich sehr viel Wert auf Effizienz gelegt, das ist toll.
Ja, also ich bin sicher, dass das total nervt, wenn man irgendwie was machen möchte, was außerhalb der Reihe ist.
Aber für noch nicht einschreibzeichen die Datenbank und klemme da halt irgendwie noch, weiß ich nicht, 1, 2, 3 Services dran.
Ja, reicht's. Das ist schon echt nicht schlecht. Ich kann halt eben 0 PHP mehr. Ich habe das ja, ich habe das halt irgendwie 15 Jahren nicht mehr rezipiert.

[49:22] Aber es ist halt, sagen wir so, dass das Framework erfüllt halt auch relativ gut die Philosophie. So hier sitzt halt jemand, der keine Ahnung hat.
Ich copy und paste irgendwie Kram und pass den so an und der reimt sich mit Kram, den ich schon mal gesehen habe.
Und das funktioniert am Ende. Dann hast du vielleicht noch Tooling, irgendwelcher Autokomplete und du lernst die Sündungsturnalarm.
Das passt. Und die PRP-Sündung ist jetzt nicht so schwierig.
Also ich würde behaupten, ich konnte nie PRP. Ich habe zwar viel PRP entwickelt, aber ich konnte es nicht wirklich.
Das war eigentlich immer der Punkt, wo ich sage, mit denen das halt, wenn man ein bisschen schiebt, schaut so aus wie C oder Java, eben auch JavaScript, weil es heute ähnliche Syntaxprimitive hat, komme ich weit genug.

[50:00] Damit der Output passt.
Aber dass jetzt irgendwie jemals Best Practices adoptiert hat oder sonst irgendwas, war unmöglich.
Ich habe ja hauptsächlich WordPress gemacht, das ist sowieso unmöglich, weil da rennst du in der WordPress-Loop und versuchst halt irgendwie Dinge rein zu quetschen.
Aber es ist trotzdem beeindruckend, wie niederschwellig das Ganze nach wie vor ist.
Also dass das überhaupt möglich ist, dass es einfach irgendwen hinsetzt und und er oder sie können einfach los starten und werken und resultat, dann das ist halt immer echt so die stärke von dem ganzen ökosystem gewesen das ist ja immer noch der grund warum ich bei allen möglichen leute sagen die mir die mich irgendwie fragen ich will irgendwie eine webseite haben aber irgendwie so square space ist mir dann doch ein bisschen zu blöd ich möchte gerne irgendwie ein bisschen extra sein geht zu wordpress weil du musst halt nur irgendeine irgendein brecheisen finden dass du an irgendeiner stelle ein ansetzen kannst in diesem ganzen System und dann kannst du deine Funktionalität die du haben willst da irgendwie rein prökeln. Ich weiß zwar nicht wie, aber ich, weiß dass du es hinkriegen wirst. Musst du ein Theme installieren, ein Plugin oder Irgendetwas selber irgendwo reinpasten, aber es wird funktionieren.

[51:05] Und wenn ich das halt wie gesagt vergleiche mit ich darf halt irgendwie meine meine Suppe Library die eine von drei Komponenten für Session Management in meinem Next.
Konstruktor ist nicht updaten auf die Version so und so weil sonst geht alles kaputt ist halt echt schwach ist halt nicht mega schwach.
Das ist ja das Problem also also du kommst ja nicht mit dem Patch nach gerade wenn du jetzt sagst du hast irgendwie ein Hobby Projekt oder irgendein Projekt das du nicht regelmäßig anschaust das vielleicht einmal ein CMS hängt und du hoffst dass ich die Seiten automatisch aktuellisieren.
Du hast per Default einfach noch zwei Wochen einen Security-Bridge irgendwo.
Die einzigen Security-Nachrichten, die ich kriege, sind von React-Projekten oder Projekten, die halt frontendlastig sind, aber stark auf MPM oder MPM-Tooling legen.
Und da gibt es ja diese Diskussion, die ist mir auch wieder irrsinnig angangen, also so nervig, wo ich gesagt habe, aber es ist doch egal, weil da ist ja nur der Dev-Server betroffen dem Security Breach und der ist jetzt nicht kritisch, weil wer würde denn ein Development Server im Production deployen? Das macht auch keiner. Das ist die Annahme von dem Maintainer gewesen. Ja, haha, du Kind, wirklich super, dass du so.

[52:15] Blauäugig ins Leben gehst, weil natürlich jeder, der sich nicht auskennt, haut den Dev Server live, weil ein Resultat und ich möchte das Resultat weiter nutzen.
Also und du kannst ja nicht von allen erwarten, dass sie Profis sind, die überhaupt daran denken, dass das ein Problem sein könnte. Genau. Und das ist halt schon bitter, ne? Und das ist wirklich bitter. Und wir sind mittlerweile an einem Punkt, also die Scriptconf-Webseite, die haben wir seit 2019 nicht mehr betreut, aus Gründen, ne? Wo haben wir so ein bisschen Pandemie dazwischen. Die können wir nicht mehr zum Leben erwecken, ist glaube ich die richtige Wortwahl dazu. Oh. Weil... Ja, festgefahren. Extrem kurze Ja, also total festgefahren. Es ist Notweiter, es ist Nächstweiter, es gibt keine Migrationsfahrt, nichts. Mit Mühe und Not kriegen wir die alte Version noch hin, dass wir sie starten können, aber von dort jetzt weg zu migrieren mit fast drei, dreieinhalb Jahren Pausen, unmöglich.
Und tatsächlich ist es so, um am Ball zu bleiben, brauchst du.

[53:21] Iterations zügeln für zwei wochen das ist das was ja bei uns in der firme sie, wir kriegen bläck tags kennst das ist das ist so ähnlich wie das was du von die pender pot kriegst und.

[53:33] Fehler update security ist irgendwas keine ahnung ist halt echt schon übel.

[53:39] Du musst es halt auch updaten können das ist also im moment so mein problem mit meinem aktuellen nextjs stack da wohnt halt eine version von der library drin Und da ist halt ein bekannte großes Security-Lücke, kein Problem, ist auch gefixt, aber bei dem Major Update ist halt auch was eingebaut worden, was halt im Zusammenspiel mit einer anderen.

[53:57] Relevanten Library, die ich halt für meine Konstruktion brauche, halt eben einfach zu einem Fehler führt. Und das ist halt auch bekannt und gemeldet und etc. Und da gibt's irgendwie Workaround-Diesen, Workaround-Jenen, alle mit so Nachteilen. Aber es ist halt überhaupt gar nicht das Ziel, das wieder zum Funktionieren zu bringen in diesem Zusammenspiel. Und das ist halt, glaube ich, das Problem, wo halt dieses ganze Micro-Library-Krams mit halt auch seinem Semantic Versioning und was nicht allem einfach kaputt geht, weil selbst wenn man jetzt sagt, alle halten sich da an diese Versionskontakte, selbst wenn sie das probieren, hast du ja dann ja trotzdem als ein so ein ganz kleiner Baustein in einem so riesigen Ökosystem im Prinzip ja unendlich viele Berührungspunkte mit unendlich vielen Libraries, mit denen du interagieren können müsstest und das kannst du halt entweder nicht leisten das willst du möglicherweise nicht leisten möglicherweise ist einfach komplett unmöglich zu allem kompatibel zu sein und wie gesagt ich vergleiche das mit tipp dieses paste diesen kommand hier in dein terminal und dann hast du da irgendwie dein laravel mit irgendwie authentifizierung drin und session management drin und die datenbank packen wir dir gleich mit rein hier ist eine docker compose nicht mal das musste selber schreiben Ja. Okay, ich vermisse halt echt irgendwie so ordentliches Typsystem.

[55:10] Oh, versuchst du jetzt gerade einen auf Überleitung zu machen?
Ich weiß gar nicht, ehrlich gesagt, ich meine, die Aufnahme läuft ja eh schon.
Ja, ja, wir sind schon mitten drin. Eigentlich ja, ich würde sagen, wir machen das.
Also das ist halt so wirklich mein einziges wirkliches Problem damit.
Also ich weiß nicht, was ich tue, aber das ist okay, weil wie du richtig sagtest, es ist ja kaum Code. Du schreibst irgendwie drei Zeilen, deklarierst da was hin, bäm, funktioniert und wenn nicht ist halt auch der Vorteil der gesamte Stack wird, halt auch benutzt von Leuten die keine Ahnung haben die halt die exakten Fehlermeldungen so oft in irgendwelche Foren und so reingepastet haben du findest das hast du irgendwie ein Problem mit Next.js brauchst du ja Next.js plus Versionsnummer plus dieses plus dieses plus solches in der Kombination manifestiert sich dieses Problem und da gibt es halt eben exakt niemanden der das schon gemacht hat. Und wenn der Mond ein Grad schief steht dann funktioniert schon immer und du kriegst andere Fehlermeldungen. Es ist halt ja. Ja.
Das ist richtig. Also das, was mich halt eben interessiert, ist wirklich...

[56:07] Also das ist mir dann ja aufgefallen und ich hatte jetzt so irgendwie so den den verdacht dass das ohnehin schon immer so ist.
Weil ich erinnere mich an irgendwie so ein ganz altes cake php projekt dass ich vor.
20 jahren oder so mal gemacht habe und erinnerte mich da wie ich da so sagte ich denke einfach die datenbank tabelle und siehe da da fällt ein rudimentäres user interface raus und irgendwie funktioniert alles.
Das war vor 20 Jahren, dann baue ich halt irgendwie vor ein paar Jahren, fange ich halt so an und NextJail sieht gut aus, lass mal anfangen. Ah, okay, du bist also ein Framework und alles, was du machst, ist React-Komponenten anzeigen. Und alles, was irgendwie interessant ist, muss ich da irgendwie selber mir zurecht basteln. Geht's noch?
Ja. Aber trotzdem habe ich es geschluckt, ab das gemacht und jetzt stehe ich halt vor dem Problem, dass ich halt hier so den alten Stack habe, das soll zu meinem neuen Stack irgendwie werden, Aber jetzt muss ich halt eben eine Migration beschreiten von halt wirklich dem einen, was ich loswerden will, zu dem anderen, wo ich hin will.
Aber das Delta zwischen denen ist halt einfach so groß, weil natürlich mit seinen eigenen Konventionen daher, dass ich halt einfach jetzt riesig viel Arbeit habe, die ohne Zweifel zu bewältigen sein wird und dies ohne Zweifel wert sein wird.

[57:13] Aber ich meine, wie bin ich in dieses Loch überhaupt reingerannt? Warum check ich das nicht?
Nicht. Vielleicht bleiben wir ganz kurz noch bei Next.js bevor wir weitergehen, weil du sagst ein paar sehr interessante Sachen. Das Ding ist halt so, wenn du jetzt Next.js angeschaut hast von vor vier, fünf Jahren, sagen wir mal so. Da war es ja richtig cool, weil in Wirklichkeit hat Next.js gesagt, du kannst ReaComponenten schreiben, aber diesen ganzen Mist mit Routing oder Server-Site-Rendering Rendering und State-across-Sessions-weiten und so weiter übernehmen wir für dich.
Das war halt auch der nächste Hosting-Ökosystem transformiert, wo das Framework entscheidet, was die beste Hosting-Variante ist.
Und da gibt es leider ein kleines Problem. Am Anfang war es halt noch richtig cool, weil du sagst, das ist halt React-Batteries included, das ist eigentlich das, was du haben willst, ganz leichtes Tooling, ein paar Prozesse oder ein paar Konventionen, aber du hast schnell unter das Framework blicken können und hast noch sehr gut verstanden, was da eben passiert.
Und jetzt hast du halt das Problem, was ursprünglich ein Open-Source-Projekt, eine Start-up war, Startup-Sore ist jetzt der Hauptfunnel für Kunden.

[58:32] Also Next.js ist jetzt das Produkt. Es ist ein Open Source Produkt, ja, aber es ist das Produkt.
Also Vercell verkauft Next.js.
Sie machen Geld über das Hosting, aber das Produkt ist Next.js.
Und das Problem ist, wie du ein Produkt hast und du eine Firma bist, die ein Produkt hat, brauchst du eine Produkt-Roadmap.

[58:50] Das heißt, du musst irgendwie schauen, dass Features reinkommen oder dass die Dinge ändern.
Du kannst nicht einfach nein sagen, weil es nicht irgendeiner Philosophie entspricht oder Sondern das Problem ist halt, du hast ein Roadmap, du hast Investoren, die müssen klar sein, was wann wie kommt, wie sich das aufs Business auswirkt und das versaut halt alles.
Das ist halt wirklich ein Problem, weil im Moment kannst du das nicht mehr machen, du hast so viel Semantik in jeder Entscheidung und musst halt einfach und das Framework abstrahiert dir so viele Dinge weg, zwingt dich aber dann trotzdem zu Entscheidungen einfach nur, weil, sie diesen starken Teil haben zur Plattform Verselbe.
Ist der Grund. Und ich meine das coole ist, das Projekt wird weiterentwickelt, das ist ja besser als wenn ihr stirbt, aber du musst halt jede Entscheidung und jedes Feature, das reinkommt, musst du halt echt für dich hinterfragen, ob es das Framework immer noch für dich bringt oder, ob du immer noch mit diesen Entscheidungen einverstanden bist oder vielleicht eine andere Lösung nicht besser wäre für dich. Weil wenn das Framework das Produkt ist und das ist...

[59:52] Dann, dann kaufst du dich früh oder später halt zum Betreiber ein und nicht zum Framework.
Ja, weiß ich nicht so sehr.
Also, weil zum einen, ich halte das ja für keine so bescheuerte Idee, sozusagen.
Also, das Framework löst ja irgendwie so dein Problem. Du willst irgendwie dein Produkt da entwickeln, aber dazu gehört halt eben auch, das irgendwo zum Laufen zu bekommen.
Und halt irgendwie eine sozusagen mit dem Framework gut zusammenspielende Hostingplattform anzubieten, man gibt es ja bei Lavarel genauso, halte ich jetzt erstmal nicht für eine per se beknackte Idee.
Also ich würde das ja tatsächlich mehr so als Einheit sehen.
Also, weißt du, das ist jetzt getrennt so operationell und sicherlich auch im Marketing, aber de facto ist es wie du sagst.
Und man sollte das glaube ich auch so sehen dass nextjs Eigentlich zu diesem anderen ding dazugehört und man kann das auch unabhängig davon betreiben aber das kostet halt eben weil es ein nicht so gedachte Einsatz von diesem Tool ist.

[1:01:02] Aber trotzdem ist das mein Hauptproblem, das macht ja nichts.
Das tut nichts, das macht nichts, was ich haben will und ich muss aktiv dagegen ankämpfen, um simpelste Dinge zu tun.
Sehr viel Code für das, dass es nichts tut.
Ja, pass auf, ich habe hier so User Interface und in dem User Interface hast du so dein Projekt und da schraubst du drin rum.
Und dann kannst du aber auch aus dem User Interface sagen, mach mir einen Falk von diesem Projekt.
Dass du wirklich so ein neues Projekt mit neuer ID und was nicht allem hast.
Ich weiß ja nicht, was verkehrt mit mir ist, aber ich dachte so, ah wunderbar, dann machst du einfach einen Button da so rein in das User Interface, das nimmt den aktuellen Projekt State, so was da alles so eingefüllt ist in die Felder und macht einen Post zum Server.
Weil dann geht der Server nämlich hin, tut das neu in die Datenbank, kriegt eine neue ID und redirectet dich dann auf die neue ID zurück.
Das ist so radikal grundlegend, dass das eigentlich funktionieren müsste.
Ja geht halt nicht. Also wobei es geht, aber pass auf, es ist halt so, das ist definitiv nicht vorgesehen.
Weil die halt total ihre Single Page Application Brain Poison noch am Start haben.
Ich hab das Projekt jetzt mal auf, dann kann ich dir genau sagen, wie ich das rausgehackt habe.
Du kennst dich ja mit dem Next.js zumindest ein wenig aus. Oh, drei Jahre kein Next.js mehr.
Es ist leider wirklich so. Aber erzähl.
Ja, pass mal auf hier. Ich hab hier in meiner index-file irgendwie so ein...

[1:02:29] Wo ist denn das? Wo ist denn das?

[1:02:32] Fionna. Moment, ich muss mal kurz hier eine Katze bremsen, die ist gerade ein bisschen lästig.
Lass die noch abpennen, du Nerfsack!
Ich habe gesehen, dass der Napf wieder funktioniert.

[1:02:43] Irgendwie kriegt der Napf... die haben ja alle hier sensorgesteuerte Futterautomaten wegen diverser diätischer Einschränkungen.
Und Ira hat gestern Abend gesponnen, da musste ich Futterautomaten debatten.
Irgendwie so reset frequenzerweiterung blabla katzepfüttern war früher auch einfacher so wo haben wir es denn da guck ich finde es schon gar nicht wieder doch hier haha pass form ich habe ich also eine library genommen die heißt formidable die macht halt ein post passt halt so form data aus dem request raus und die habe ich dann halt irgendwie so mühsam in meine get server site props glaube ich reingesteckt genau wo ich halt so gucke wenn es ein post request ist und das ist halt wirklich alles so, ich gucke mir manuell das request objekt rein und gucken ob da die method irgendwie post ist und wenn ja mache ich halt so ein paar sich die form speichere das abkriegt eine neue id und redirected an manuell weil ich muss halt manuell in diesem request objekt rumfummeln weil es hat nicht einfach die Möglichkeit gibt zu sagen wenn post mach was und redirect dann. Ja ja ja das ist ich verstehe was was du machen musst und ich verstehe, wo dein Problem ist. Das ist Spitze, weil da bricht denke ich genau.

[1:03:56] Genau dieses grundlegende Feature von HTTP, dass du Daten hinschicken kannst und dass du nachher auch mit der Response den Output steuern kannst, durch die vielen Einstiegspunkte in diesem Framework, und halt einfach der Fakt, dass das Ding nicht für solche einfachen Sachen gemacht ist.
Weil die Alternative des Dostes, dass du halt mit einer API redest, das heißt, das ist irgendeine Serverless Function, die du schreibst, und das rennt ja irgendwo, wie willst du da Redirects machen?
Oder wie kannst du das sauber redirects machen? Weil das ist ja komplett detached von dem Rest deiner Software.
Machst das du über die Seiten, die du rendest, hast du das Problem, dass du halt nur den Initialpunkt kriegst, aber nie den verarbeiteten Daten, die über einen Request reinkommen.
Also ich kann mir vorstellen, dass das irrsinnig mühselig ist, das reinzukriegen.
Ja, das hört sich alles sehr richtig an, was du sagst, aber trotzdem, ich mache halt hier am Ende des Tages immer noch eine Web-Applikation.
Wenn ich mir ein Bein ausreißen muss, um Post zu machen, dann bin ich unwillig zu, da irgendwie Konzessionen bezüglich dessen zu machen, dass ich halt hier im Recht bin und dass die Blödsinn bauen.

[1:04:56] Ja, da hat Gott sei Dank versiell den Riesenvorteil, dass so Dinge wie HTTP-Post sowieso nicht mehr auf dem Schirm der meisten Entwicklerinnen und Entwickler heutzutage ist.
Und das ist ein bisschen bitter.
Ich bin halt zum Ergebnis gekommen, dass dieser ganze React-Kram, also das ist halt mehr so inklusive Ökosystem, Das darf man halt nicht wirklich als Web-Framework bezeichnen und mit Web-Erwartungen herangehen, sondern das ist halt irgendwie sein eigenes Ding. Das ist so semi-native.
Und wenn man halt irgendwie so sein Gehirn vergiftet hat mit so Dingen wie Postrequests oder irgendwie so der Web-Animation-API, meinem Lieblings-, ich heiße React-Beispiel.

[1:05:34] Wo man halt irgendwie imperativ einen Effekt auslösen kann.
Wenn man weiß, dass das da ist, dann ist man frustriert. Wenn man vergisst, dass das da ist und einfach nur so stumpf sagt, okay, wie macht man das im React nicht? Wie macht man das in einem Webbrowser?

[1:05:48] Dann geht das. Aber es ist so gut, du sagst so viel richtige Sachen.
Ich habe das vermisst.
Das Thema ist ja dann, genau durch solche Dinge, wo du sagst, jetzt kommt irgendein Case, der wäre einfach mit Bordmitteln einfach zu lösen.
Und du merkst, das ist eine riesige Anstrengung, dass du das mit dem Framework löst.
Schränkt es ja diese Bandbreite der möglichen Anwendungsfälle für das Framework ein, weil es steht nicht dafür, dass du sagst, du musst mehr auf- und betreiben für etwas, das eigentlich grundlegend sein soll, weil du auf diesen Abstraktionen vom Framework arbeitest. Wunderschön.
Und das Problem ist dann, wenn du drüber nachdenkst und mehr und mehr schaust, was da eigentlich was schief geht, dann hast du in Wirklichkeit ein Single Page Application Framework, mit dem du hauptsächlich semistatische Daten anschaust. Entweder Sachen, die aus einem JSON kommen, oder Sachen, die von einem CMS kommen, fertig.
Es ist a few. Es ist nicht das, was dir erlaubt, umfangreiche Applikationen zu schicken, die jetzt über einen einfachen JSON-Request rausgehen.
Und du hast teilweise aber die Fälle, wo du das machen musst.
Es geht gar nicht anders.
In vielen, vielen Fällen.

[1:06:52] Und darum ist auch der Großteil der Demos oder Projekte, die damit betrieben werden oder gezeigt werden, Webseiten und Blogs.
Und da musst du dich halt fragen, ist das dann den ganzen Aufwand von dem Framework, steht das dafür, wenn du nachher sowieso nur deine keine Ahnung 50-100 HTML Seiten hast, aber der Klick von A nach B geht halt ein bisschen schöner.
Also ja, ich glaube das ist gerade die Britulie, in der wir sind, die auch die Diskussion anregt. Punkt.

[1:07:23] Von dem her, also ja, also spannend. Es ist eine richtig, richtig schöne und interessante Feststellung für dich.
Fällt mir sehr gut. Ja, naja, das Ding ist halt eben, ist ja weiterhin irgendwie so, für was nützlich, das React.
Also in meinem konkreten Fall ist so das User Interface, wie es sich darstellt und wie man da drin rumklickt.
Das ist halt eine mega komplexe Angelegenheit mit irgendwie, da ist Track and Draft drin und da sind irgendwelche Dinge, die initialisiert werden, API Requests.
Das ist halt wirklich eine Single-Page-Application.
Mit dem Gramm bin ich ja auch einverstanden.
Aber dass halt irgendwie dann sozusagen das Backend darunter leidet und dadurch eingeschränkt ist, dass ich halt im Frontend diesen komplizierten Klumpatsch habe, da geh ich halt nicht mit.
Okay, die Leute, die sich mit React einen Blog bauen, jeder kann sich auf seine eigene Weise ans Kreuz nageln, ist nicht mein Problem.
Die könnten das sicherlich einfacher haben. Ist ja alles egal.
Das kriegst du halt eben auch noch hin. Ich nerf halt mehr so weißt du das hat deshalb so das back end auf mein front end irgendwie so direkt wechsel wirkt um, server side rendering zu machen dass ich ja gar nicht bräuchte wenn ich den ganzen kram auf, sagen wir mal die sinnvollen use cases beschränken würde.

[1:08:34] Mein aktueller schlagplan ist back end pap ich operiere das front end da aus next.js raus und betreibe das als eine normale single page application ohne server side rendering, Weil so kram wie der landing page und ein login formular mache ich halt irgendwie damit pap das kommt vom server das geht ohnehin schnell, Und wenn ich halt eingeloggt bin, Man wartet halt drei Sekunden bis das Ding sich initialisiert hat.
Ja.
Das ist mein Plan, weil, äh, nee, ey, nee. Das Spannende ist aber die Alternative, vielleicht bleiben wir noch ganz kurz dort.
Wir kommen heute sicher zu TypeScript, ich bin mir hundertprozentig sicher, wir schaffen das.
Aber die Alternative dazu ist ja, du sagst, es gibt andere Tools für einen Blog, ne?

[1:09:13] Und ich hab mir jetzt geschworen, ich möchte meinen nächsten Blog ohne einem Charscript-basierten Blog-Framework schreiben.
Ich nenne es jetzt mal Blog-Framework. Also es fallen daraus Dinge wie Next, es fallen Dinge raus wie Next, es fallen Dinge raus wie Eleventy, was meine aktuelle Webseiten laufen drauf und ich find's cool, man kann coole Sachen damit machen, es macht irrsinnig viel Sinn, aber es fällt auch Astro raus und alles andere, weil ich hab nicht vor, dass ich diese Webseite, ich bin jetzt nebenberuflich selbstständig Webseiter, dass ich mich da auch nur um ein bisschen Maintenance kümmere.

[1:09:49] Hab ich einfach nicht vor. Und das Problem ist, so wie du einen NPM Install machst, hast du einfach technical dept da und du bist im maintenance mode.
Mit der ersten Installation einer dependency. Und jetzt haben wir andere Sachen angeschaut und wow, die sind halt alle im Stich gelassen worden in den letzten Jahren.
Sämtliche damals populäre heute vielleicht nicht mehr Seitengeneratoren oder alles was von irgendeiner anderen Programmiersprache kommt, die Beineres produzieren kann, wie Hugo oder Solar, das ist in Rust geschrieben und so weiter, die sind entweder nicht dort oder nicht mit dem Interesse oder mit einer eigenen Komplexität, die schlecht dokumentiert ist. Also es hat sich einfach die Szene komplett auf diese JavaScript Tools gelegt und der Rest ist einfach ausgetrocknet. Ist irrsinnig, bitte, ich bin jetzt bei dem Punkt, wo jeder von uns irgendwann noch mal in seinem Leben ist, schreibe ich mir's halt selbst. Und vor dem hab ich eigentlich noch mehr Angst, als vor einem NPM-Install. Naja, das Ding ist halt, ein statischer Seitengenerator ist glaube ich, Das ist, glaube ich, echt so...

[1:11:01] Weißt du, du hast ein Flugzeug und das fliegt halt hoch. Und wenn es halt hoch fliegt und der Luftdruck irgendwie geringer ist und so.
Da muss das halt irgendwie so seine Geschwindigkeit ziemlich genau halten, weil sonst wird es halt eben zu schnell und dann fällt es auseinander oder zu langsam und dann reißt die Strömung ab und das fällt runter.
Das nennt man die Coffin Corner.
Und ich glaube, die Coffin Corner von Softwareentwicklung ist der statische Seitengenerator, weil das so, du kommst da halt sehr leicht rein.
So, aber du kommst aus der Nummer halt nie wieder raus. Es ist halt so einfach, dass du dir sofort sagen kannst, ah, ich weiß, was ich tun muss und was ich haben will.
Und dann baust du das ein. Und das funktioniert halt so lange, bis du es veröffentlichst und irgendwer da draußen das auch anfängt zu nutzen und ein bisschen andere Anforderungen hat. Weil dann geht die Komplexität durch die Decke, du musst also warten, was du nicht tun wirst, dann wird es abandoned und dann reißt du dich halt ein in die ganze lange Liste von den gerade genannten Tools, wo es halt nicht mehr weitergeht. Mein nächstes Blog wird ein WordPress, das sag ich dir, ohne irgendwelches JavaScript. Mal bitte ja. Und einfach einen fetten Cash davor dann das ist mein aktuelles cms auch das ist ein steinaltes irgendwie pp cms das kriegt hin und wieder noch ein security update das ist gänzlich schrecklich das backend ist irgendwie mit gott wie heißt es denn ich erinnere mich schon gar nicht mehr bei so ein altes javascript UIToolkit, also irgendwie so eine Generation nach jQuery UI, aber nur nach dem gleichen Paradigma.
Schlimm zu bedienen ganz schrecklich alles ist grausam aber weißt du wie xjs oder so das war es ja.

[1:12:25] So also kann ich auf mobile nicht benutzen alles blabla blabla aber weißt du das liefert halt html seiten aus und hat den genannten fetten cash davor, Es lädt halt super schnell ich muss nichts tun und da will ich halt gerne wieder hin nur in zukunft mit irgendeinem ding was halt ein bisschen besser support ist und vielleicht ein paar mehr Sicherheitsupdates bekommt das muss ich halt irgendwann mal alles nach wordpress migrieren Aber einfach nur weil ich habe halt für den ganzen Kram keine Zeit mehr.
Ich bin ein alter Mann, ich habe keine Zeit für den Scheiß. Und du sagst wieder was ganz richtiges, also danke an alle Hörerinnen und Hörer.
Ihr habt jetzt wieder mal 30 Minuten alte Männer beschweren sich, dass Samas alles besser war, gehört.
Es hat schon einen Grund gegeben, warum ich nicht mehr beim Podcast dabei bin.
So ist es ja nicht. Es sind ja nicht die Alten, es ist ja nicht früher war alles besser, sondern wir haben heutzutage Alternativen, die wohnen halt nicht so direkt in dem von uns wahrgenommenen Mainstream.
Weil, ich mein, ist ja nicht so, dass so was wie WordPress nicht weiterentwickelt würde.
Oder so was wie Laravel. Das spielt ja wirklich die ganze PHP-Klavier-Tour einmal runter.
Und das ist ja supermodern mit Package-Manager und... Docker-Deployment, blablabla.
Das ist ja von der Oberfläche, von der User-Experience her. Was kriegst du alles geliefert und was kannst du alles tun?

[1:13:41] Auf einer stufe mit dem ganzen next.js universum du kriegst das hier ein du generiert das hin da ist hallo weltrind rückst auf den knopf das wird die ploid du schmeißt da irgendwie fünf dollar rüber und dann läuft die kiste das ist ja das gleiche das ist halt nur mit aller technologie gebaut aber halt eben mit aller technologie die halt einfach besser abgehangen ist einfach und die halt schon so ich glaube die hatten die ganzen fehler die jetzt aktuell gemacht werden schon gemacht und hat so dann auch wieder zurückgerudert und war wahrscheinlich nie mit dieser großen Explosion an an Nutzern und Nutzern konfrontiert. Das weiß ich nicht.

[1:14:16] Es gibt ja durchaus Perlen und es hat ja durchaus Perlen gegeben im JavaScript-Ökosystem, aber es ist halt einfach irre durch NPM zu wandern.
Es ist einfach Wahnsinn, was da passiert. Und, ja, aber wir kennen die Probleme, das ist es.
Also gut, vielleicht beschweren Sie nicht, alte Männer, dass damals alles besser war, vielleicht haben wir halt einfach wirklich nicht mehr die Zeit für den Mist.
Weil damals war meine Toleranz gegenüber neuen Technologien weitaus größer.
Also, ja, und du hast halt auch möglicherweise mit möglicherweise weniger Erfahrung nicht ganz so viel Idee davon, wie es woanders aussehen könnte.
Ja, das stimmt. Ich meine, ich bin ja ich bin ja auch sehenden Auges in Next.js reingerannt und dachte, so macht man das halt eben.
Und so Krams wie halt irgendwie so Scaffolding und Postrequest gibt es halt nicht mehr.
Finde dich halt damit ab und dann bin ich zum Ergebnis gekommen, dass äh nee will ich aber jetzt haben.
Oh wey. Kann ich kriegen. So, so viel zum Intro. Genau, das war jetzt das Intro und ich glaube, es könnte mir endlich über TypeScript reden oder? Gibt es da eigentlich irgendwas zu sagen?
Weiß nicht, wollen wir jetzt nach dem Vorgeplänkel vielleicht so die Einleitung in die Sendung machen?
Ja, genau. Also, die Sabine wird sicher entscheiden, was sie jetzt mit der letzten halben Stunde macht.

[1:15:42] Genau, vielleicht kommt es davor, vielleicht kommt es danach, vielleicht kommt es irgendwann.
Aber jetzt können wir die Einleitung machen. auch Bonus Content wird das daraus erlöst oder so.

[1:15:53] Music.

[1:16:19] Beep! Beep! Beep!