WEBVTT

00:00:00.270 --> 00:00:05.417
JavaScript beziehungsweise TypeScript führen das Using-Schlüssel dort ein.

00:00:05.662 --> 00:00:09.821
Und mit Using kann man Bindings, also Variablen, deklarieren,

00:00:10.307 --> 00:00:13.494
die über ein explizites Ressourcenmanagement verfügen.

00:00:14.745 --> 00:00:17.817
Ich hatte ja vor ein paar Wochen, war ich ja ganz übel krank und lag wirklich fiebrig da nieder

00:00:17.817 --> 00:00:20.817
und mein bescheuertes Gehirn dachte sich, das ist die ideale Gelegenheit,

00:00:20.817 --> 00:00:22.217
eine JavaScript-Library zu schreiben.

00:00:23.882 --> 00:00:27.654
Hat's dann auch gemacht. Und leider ist das Ding auch relativ nützlich, sodass ich's benutzen muss.

00:00:28.384 --> 00:00:33.272
Wenn gleich die Code-Qualität ungefähr dem entspricht, was du da so unter dem Fieberwahn ausmalen kannst.

00:00:33.680 --> 00:00:58.320
Music.

00:00:58.640 --> 00:01:00.817
Working Draft Revision 581,

00:01:04.213 --> 00:01:08.138
Diese Revision von Working Draft wird euch präsentiert von Hörerinnen und Hörern wie euch.

00:01:08.822 --> 00:01:12.387
Auf patreon.com slash workingdraft könnt ihr uns ein paar Euro in den Hut werfen.

00:01:12.801 --> 00:01:18.967
Aus euren Beiträgen und unseren gelegentlichen Werbeeinnahmen bezahlen wir allerleite eure Software-Abos und das Honorar unserer Audio-Producerin.

00:01:19.562 --> 00:01:24.072
Wenn ihr euch auch beteiligen wollt, könnt ihr das unter patreon.com slash workingdraft sehr gerne machen.

00:01:24.648 --> 00:01:27.497
Wir danken euch tausendfach für die Unterstützung und fürs weitere Zuhören.

00:01:27.790 --> 00:01:36.857
Hallo und herzlich willkommen zu Working Draft Revision 581. Heute ist an Bord der Stefan.

00:01:37.593 --> 00:01:37.017
Hallo.

00:01:37.777 --> 00:01:43.616
Meine Wenigkeit, der Peter. Und das kann nur eins heißen, Nämlich bei Mike und schaff das mal wieder, was passiert.

00:01:45.092 --> 00:01:48.279
Ich seh schon wieder, was passiert. Na ja, einmal im Quartal, ne?

00:01:49.305 --> 00:01:51.602
Ja, Timescope hat sich mal wieder ein Update geleistet.

00:01:51.662 --> 00:01:58.002
Und wir wollen unter anderem, wie immer, über die drei, vier, eins interessanten Features reden,

00:01:58.062 --> 00:01:59.135
die es da so drin gibt.

00:01:59.496 --> 00:02:01.620
Und, ähm, Stefan, du wolltest mit einem anfangen.

00:02:02.169 --> 00:02:07.842
Ja, genau, also, äh, gleich ganz oben. Wir haben jetzt sehr viel über Sinn und Unsinn von Features gesprochen.

00:02:07.902 --> 00:02:12.442
Und jetzt ist ein Feature rausgekommen, es gibt ein Ectoscript-Proposal dazu,

00:02:12.693 --> 00:02:17.050
von dem ich, also das ich gerne ein bisschen spitzfindiger diskutieren möchte.

00:02:17.509 --> 00:02:20.442
Das glaube ich sofort. Ich hatte mir gedacht, dass du dich darauf stürzen würdest.

00:02:20.442 --> 00:02:24.315
Ja, ja, also das ist gleich das Erste. Also man muss ja ganz ehrlich sagen, es ist wahrscheinlich auch das

00:02:24.576 --> 00:02:31.442
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.

00:02:31.679 --> 00:02:37.044
Aber es geht um die Using Declarations, das explizite Ressourcenmanagement.

00:02:37.764 --> 00:02:42.442
Tatsächlich führt JavaScript und somit auch Typescript, das ist immer diese Dualität,

00:02:42.442 --> 00:02:46.662
Typescript ist die erste Referenzimplementierung von Features, die in JavaScript noch auch

00:02:46.662 --> 00:02:53.682
erscheinen, JavaScript bzw. Typescript führen das Using-Schlüssel dort ein und mit Using

00:02:53.682 --> 00:03:01.080
kann man Bindings, also Variablen, deklarieren, die über ein explizites Ressourcenmanagement verfügen.

00:03:01.575 --> 00:03:06.442
Explizites Ressourcenmanagement bedeutet, dass du nicht nur ein Objekt oder eine Instanz

00:03:06.442 --> 00:03:13.482
oder was auch immer für eine Struktur erstellen kannst, sondern auch beim Aufräumen du sicherstellen

00:03:13.482 --> 00:03:16.442
kannst, dass du diverse Aufräumarbeiten erledigst.

00:03:16.442 --> 00:03:19.322
Das Beispiel, das Sie dort geschrieben haben, ist, dass du zum Beispiel sagst, du öffnest

00:03:19.697 --> 00:03:27.082
eine Datei im Node.js-Filesystem und sowie dieser File-Handle verschwindet, wird auch

00:03:27.082 --> 00:03:33.322
die Datei geschlossen beziehungsweise wird die Datei gelöscht, wenn das jetzt deine Idee ist.

00:03:33.322 --> 00:03:36.558
Genau mit Anlink werden die Suchen gelöscht.

00:03:37.827 --> 00:03:41.557
Und das Problem ist jetzt das, wenn du jetzt davon ausgehst, dass diese Dateien auch immer gelöscht werden,

00:03:41.557 --> 00:03:46.208
hast du das Problem, was ist, wenn du einen Early Exit hast oder irgendwo ein Fehler geworfen wird und so weiter.

00:03:46.361 --> 00:03:49.944
Du hast in JavaScript nicht die Möglichkeit, dass du sagst, hey, egal was passiert,

00:03:50.899 --> 00:03:56.588
bitte schmeiß alle Sachen am Ende weg oder bitte führ diese Destructor-Tätigkeiten aus,

00:03:57.200 --> 00:03:58.929
zu dem Zeitpunkt, wo dieses Objekt weggeschmissen wird.

00:04:00.531 --> 00:04:03.617
Ja, du kannst ja schon ganz viele Try-Catches aneinander verschachteln, wenn du möchtest.

00:04:03.617 --> 00:04:06.013
Genau, und Binary-Blöcke und solche Sachen, die werden immer ausgeführt am Ende.

00:04:06.112 --> 00:04:10.695
Das kannst du schon machen, nur ist es halt wie immer nur so gut, wie du halt als Entwicklerin

00:04:10.957 --> 00:04:15.617
oder Entwickler auch bist. Das ist ein bisschen eine AP-Frage, wenn jetzt zum Beispiel so ein

00:04:15.617 --> 00:04:20.903
Objekt zur Verfügung steht für so einen temporären Fall und ich mache da ein Klasse-Grundherum. Gehe,

00:04:21.397 --> 00:04:26.977
ich von meinen Nutzerinnen und Nutzern aus, dass die nachher wissen, wie sie aufräumen oder mache

00:04:26.977 --> 00:04:32.857
ich das? Und wenn ich das mache, zu welchem Punkt mache ich das? JavaScript löst das so und das

00:04:32.857 --> 00:04:38.537
finde ich eigentlich eine sehr elegante Lösung. JavaScript führt das Dispose-Symbol ein. Also

00:04:38.537 --> 00:04:45.377
Symbols sind ja Möglichkeiten, dass du bei Klassen und Objekten diverse Accessoires hast,

00:04:45.377 --> 00:04:51.177
die zum Beispiel mit dem JavaScript direkt verbunden sind. Zum Beispiel ist es das

00:04:51.177 --> 00:04:57.777
Iterator-Symbol, wo du eine Generator-Funktion dahinter hast, mit der du neue Items rausjagen

00:04:57.777 --> 00:05:02.089
kannst und damit ist dann deine Klasse mit jeder For-Loop kompatibel.

00:05:02.251 --> 00:05:07.857
Das sind quasi Magic Keys für Sprachprotokolle, damit man sich andocken kann an Konstruktionen

00:05:07.857 --> 00:05:11.377
wie InstanceOfKeyword, ForOfLoop und so weiter.

00:05:11.377 --> 00:05:16.137
Genau, und ToStringTag, also was du in der Object-Object rausschmeißen willst, sondern

00:05:16.137 --> 00:05:24.225
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

00:05:24.477 --> 00:05:26.143
mit dem, was schon vorhanden ist.

00:05:27.061 --> 00:05:32.930
Und sie haben das Dispose-Symbol eingeführt, wo du sagst, in der Aufräumaktion führ bitte diese Schritte aus.

00:05:33.299 --> 00:05:39.655
Das heißt, da kannst du nachher so Dinge machen wie Datei schließen, Datei löschen, wenn das jetzt deine Idee ist.

00:05:39.916 --> 00:05:41.492
Das finde ich super, das finde ich cool.

00:05:41.834 --> 00:05:46.461
Also ich verstehe, dass man sowas braucht und wenn man da wirklich eine elegante API machen möchte,

00:05:46.767 --> 00:05:49.432
dann kann man das gerne mit dem Dispose-Symbol machen, finde ich spitze.

00:05:50.575 --> 00:05:54.357
Das Spannende ist aber jetzt das, und das habe ich jetzt nicht ganz verstanden, warum man das braucht,

00:05:54.357 --> 00:06:02.957
dass es für Dinge, die das Post-Symbol ausführen möchten beim Aufräumvorgang, gibt es jetzt dieses

00:06:02.957 --> 00:06:10.758
das Using Keyword. Und das Using Keyword sagt, hey, das Post wird am Scope-Ende nachher aufgerufen.

00:06:11.982 --> 00:06:17.825
Also man führt neben Kunst wahr und lädt ein weiteres Deklarationssymbol ein oder

00:06:17.992 --> 00:06:23.592
Deklarationsschlüsselwort ein und sagt, passt, Scope Ende, sprich geschlungene Klammer zu,

00:06:23.592 --> 00:06:30.923
jetzt räumt zusammen und schließt das Ganze. So weit, so gut. Warum brauche ich das? Warum

00:06:31.352 --> 00:06:35.632
macht das nicht der Garbage Collector für mich? Der Garbage Collector müsste am Ende von dieser

00:06:35.632 --> 00:06:40.952
geschlungene Klammer sowieso drauf kommen, dass dort keine weiteren Zugriffe mehr auf das Spanning

00:06:40.952 --> 00:06:46.011
gibt und die Aufnahmearbeit durchführen. Also simpel ja, aber warum brauche ich eigene Schlüsselwerte?

00:06:46.200 --> 00:06:49.792
Was sage ich der VM dadurch, was sage ich den Compiler dadurch? Das kapiere ich.

00:06:50.332 --> 00:06:55.952
Das kann ich dir sagen. Der Garbage Collector garantiert dir nicht, dass ab Scope-Ende sofort

00:06:55.952 --> 00:07:00.392
das Objekt verschwindet, sondern nur, dass ab Scope-Ende niemand darauf zugreifen kann und

00:07:00.392 --> 00:07:06.312
dass es dann irgendwann verschwindet. Weil es gibt ja zum Beispiel auch die Finalization Registry,

00:07:06.312 --> 00:07:08.812
Ich weiß nicht, ob du mit der mal zu tun hattest.

00:07:09.228 --> 00:07:12.772
Nö, glaub ich nicht. Das dachte ich auch, ich hab nämlich zuletzt erst,

00:07:12.832 --> 00:07:15.547
wie zum allerersten Mal, ernsthaft für eine Demo verwendet.

00:07:15.992 --> 00:07:21.075
Finalization Registry ist im Prinzip ein Mechanismus, um auf ein Objekt einen Callback draufzusetzen

00:07:21.426 --> 00:07:22.515
on garbage collected.

00:07:23.667 --> 00:07:26.872
Und der wird dann halt eben ausgeführt, wenn das Objekt dann eingesammelt wird.

00:07:26.932 --> 00:07:31.535
Die Finalization Registry hält nur eine schwache Referenz auf das betroffene Objekt natürlich.

00:07:31.852 --> 00:07:35.672
Und dann kriegst du das eben. Und daran kannst du sehr gut nachvollziehen,

00:07:35.672 --> 00:07:42.014
der Garbage-Collector bei Objekten in JavaScript teilweise erst relativ spät greift.

00:07:42.230 --> 00:07:48.153
Der wird während erwartet wieder mal einen Garbage-Collection-Zyklus machen und fertig, ne?

00:07:48.459 --> 00:07:53.552
Genau, genau. Also, ne, das ist halt das eine. Das andere ist halt eben auch, dass so Sachen wie Garbage-Collection

00:07:53.879 --> 00:07:57.472
ist ja gar nicht Gegenstand der ECMAScript-Spezifikation.

00:07:57.472 --> 00:07:59.559
Da wird ja nicht festgelegt, wie einer zu funktionieren hat,

00:07:59.901 --> 00:08:03.610
sondern nur, dass es einen zu geben hat und wie die dann das organisieren.

00:08:04.105 --> 00:08:09.552
Da gibt's ja verschiedenste Möglichkeiten, das zu machen. Und man kann ja irgendwie so, wie nennt man das dann,

00:08:09.592 --> 00:08:14.592
so, dass man die Objekte in Generationen einteilt, irgendwie die kurzlebigen und die langlebigen,

00:08:14.632 --> 00:08:16.212
die checkt man halt seltener.

00:08:16.252 --> 00:08:22.252
Das ist alles in der Implementierung freigestellt, sodass du tatsächlich, wenn du wirklich die Garantie geben willst,

00:08:22.569 --> 00:08:27.637
in der Sprache, dass, wenn Scope ende, dann werden diese Funktionen ausgeführt, die das Disposen machen.

00:08:28.024 --> 00:08:32.632
Dann brauchst du dafür ein neues Sprachkonstrukt, weil die Garbage Collection macht das nicht.

00:08:32.632 --> 00:08:34.515
Wenn man bessere Garbage-Kollektoren braucht.

00:08:36.703 --> 00:08:39.106
Nee, du bräuchtest keine besseren, du bräuchtest einen einheitlichen.

00:08:39.376 --> 00:08:40.529
Ja, vielleicht das. Okay.

00:08:41.042 --> 00:08:45.753
Und das kannst du natürlich machen, aber dann musst du den Leuten wieder vorschreiben,

00:08:45.753 --> 00:08:49.081
wie ihre ECMA-Skript-Implementierung aussieht und das tust du halt normalerweise nicht.

00:08:49.378 --> 00:08:55.753
Ja, aber das ging doch da mit dem Using-Keyword wie Garbage-Collector-Vorschreibung mit extra Schritten.

00:08:55.753 --> 00:09:00.753
Im Grunde sagt man ja damit, hey, okay, das Copy ist am Ende, schmeiß' weg.

00:09:01.162 --> 00:09:02.854
Und das könnte ja ein super Default sein, eigentlich.

00:09:03.908 --> 00:09:12.493
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.

00:09:12.493 --> 00:09:15.791
Da gibt es ja noch so eine andere Programmiersprache, mit der du dich jetzt wieder mal befasst.

00:09:16.052 --> 00:09:20.589
Ja, da ist eigentlich das Gang und Geben. Also da ist ja, gesprungene Gammel bedeutet, Ressourcen werden frei.

00:09:20.940 --> 00:09:22.578
Genau. Das funktioniert eigentlich relativ gut.

00:09:23.559 --> 00:09:26.353
Aber ich kenne mich jetzt ja in Rust, das ist die Programmiersprache, von der wir reden,

00:09:26.353 --> 00:09:31.364
die ja tatsächlich genauso funktioniert wie der Stefan, das jetzt gerade sozusagen sich für JavaScript erträumt hat.

00:09:31.896 --> 00:09:35.293
Da muss man nicht beischreiben, wann was eingesammelt werden soll.

00:09:35.353 --> 00:09:39.853
Da hat man keinen Garbage-Collector, sondern einfach der Compiler findet automatisch raus

00:09:39.913 --> 00:09:43.953
durch Betrachten des Codes und der Typen, wie langlebig ein Objekt ist.

00:09:44.148 --> 00:09:47.253
Dann kann er dir garantieren, dass du keine Memory-Leaks hast.

00:09:47.313 --> 00:09:52.093
Aber was er dir auch garantiert, ist, dass das Debuggen teilweise ein bisschen mühsamer wird.

00:09:52.153 --> 00:09:57.993
Weil man muss eben da sehr komplizierte Typen alle so organisieren und so zusammenstecken, dass es auch funktioniert

00:09:58.053 --> 00:09:59.993
und für die Maschine verständlich ist.

00:10:00.847 --> 00:10:08.953
Aber Rust funktioniert doch, stand jetzt, wenn ich mich nicht täusche, quasi wie ein Produkt.

00:10:09.255 --> 00:10:12.633
As in, das gibt es einmal.

00:10:12.343 --> 00:10:16.610
Es gibt eine Rust-Implementierung und es gibt nicht irgendwie eine Spezifikation dafür, ist das so?

00:10:17.375 --> 00:10:27.193
Es gibt mittlerweile eine Spezifikation und es gibt schon zwei Implementierungen.

00:10:27.193 --> 00:10:33.363
Es gibt eine, die auf den GCC hinzielt und eine, die auf die LLVM hinzielt.

00:10:33.723 --> 00:10:39.393
Okay. Das gibt es mittlerweile schon und es wird gerade eine Spezifikation für den Automotive-Sektor erarbeitet,

00:10:39.393 --> 00:10:43.491
Also für Rast in kritischen Umgebungen, das ist das Ferro-Scene,

00:10:44.166 --> 00:10:48.451
wo auch festgelegt wird, wie sich der Compiler zu verhalten hat in dieser Situation.

00:10:48.658 --> 00:10:51.404
Damit ganz klar wird, das ist das Ergebnis, das wir erwarten.

00:10:51.953 --> 00:10:55.599
Okay. Ist das so ... Ich muss ganz ehrlich sein. Okay.

00:10:56.112 --> 00:11:01.033
Aber dann würde ich ja trotzdem annehmen, dass wegen der ganzen Garantien, die das beinhaltet,

00:11:01.093 --> 00:11:07.193
eben sehr genau beschrieben ist, wie sich tatsächlich am Ende auf der Ebene der Nullen und Einsen

00:11:07.401 --> 00:11:08.693
die ganze Mechanik verhält.

00:11:08.693 --> 00:11:13.720
Wann da was Garbage Collected wird oder freigegeben wird oder verwendbar ist oder nicht, ne?

00:11:14.440 --> 00:11:18.493
Und das ist halt eben bei den ECMAScript-Spezifikationen so komplett anders.

00:11:18.581 --> 00:11:23.893
Ich hab aus Gründen der Vorbereitung für einen heißen Herbst voller Advanced-JavaScript-Workshops

00:11:23.893 --> 00:11:28.259
mich da so reingefressen in so diverse, wirklich mal ECMAScript-Spezifikationen lesen und Zeug.

00:11:29.168 --> 00:11:32.453
Und da steht wirklich nicht drin, wie irgendwas zu funktionieren hat. Null.

00:11:32.453 --> 00:11:36.253
Da wird immer nur beschrieben, wir haben hier irgendwelche abstrakten Operationen deklariert

00:11:36.253 --> 00:11:39.093
und die am Ende beschreiben ein beobachtbares Verhalten,

00:11:39.251 --> 00:11:42.293
aber es ist an keiner Stelle irgendein Wort darüber verloren,

00:11:42.353 --> 00:11:45.264
wie etwas am Ende implementiert zu sein hat. Null.

00:11:45.561 --> 00:11:52.393
Und das ist halt der ganze Geist, der da drinnen atmet. Und insofern ist halt eben diese Explicit Resource Management

00:11:52.453 --> 00:11:55.518
mit dem Using-Keyword tatsächlich eine Ausnahme,

00:11:56.616 --> 00:12:02.521
wo man halt eben wirklich generell sagt, dieser Effekt muss passieren, wenn diese Syntax so und so evaluiert ist.

00:12:02.855 --> 00:12:08.993
Aber das ist eben nicht auf die gesamte Sprachmechanik Collection ausgedehnt.

00:12:08.715 --> 00:12:16.173
Und deswegen würde das, also man müsste im Prinzip die Spezifikationen neu schreiben und einfach einen komplett anderen Ansatz wählen,

00:12:16.173 --> 00:12:22.560
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.

00:12:22.813 --> 00:12:32.436
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,

00:12:33.471 --> 00:12:34.263
weil man sonst nicht weitergekommen wäre.

00:12:35.650 --> 00:12:42.411
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.

00:12:43.050 --> 00:12:47.553
Weil du kannst ja nicht sagen, wie ein Modul geladen wird, weil du ja nicht mal weißt, ob du als JavaScript-Engine

00:12:47.553 --> 00:12:50.553
in einem Browser, auf einem Server oder weiß Gott wo existierst.

00:12:50.891 --> 00:12:55.554
Also, du kannst nicht irgendwie sagen, lade eine Datei, weil Datei gibt's ja gegebenenfalls konzeptionell nicht mal.

00:12:56.247 --> 00:12:58.723
Dann bin ich aber gespannt zum Beispiel, ob das Using-Keyword jetzt...

00:12:59.929 --> 00:13:05.153
Also was das für einen Einfluss hat auf die Objekte, die erzeugt werden.

00:13:05.483 --> 00:13:09.786
Ob die vielleicht sogar am Stack erzeugt werden und nachher weggeschmissen werden.

00:13:10.471 --> 00:13:15.353
Und ob ich das auch für Dinge verwenden kann, die kein Dispose-Symbol verwenden.

00:13:15.353 --> 00:13:20.319
Also wirklich als Alternative zu LED-Kunst-Waren.

00:13:22.012 --> 00:13:29.473
Also, du... Okay. Das habe ich jetzt natürlich nicht nachgelesen, was passiert, wenn du irgendwie so using 42 machst.

00:13:29.798 --> 00:13:36.033
Das habe ich jetzt natürlich auch nicht auf dem Zettel. Aber die Frage ist, warum würdest du?

00:13:36.033 --> 00:13:42.193
Also damit ich gleich Dinge wegschmeißen kann, wo ich mir denke, okay, das ist viel zu groß.

00:13:42.933 --> 00:13:47.193
Ah, da musst du, glaube ich, dein Rust-Gehirn da fahren lassen und wieder sagen,

00:13:47.193 --> 00:13:48.753
der Garbage Collector, der macht das schon.

00:13:49.802 --> 00:13:52.753
Ja, aber das würde ich generell gerne sagen, der Garbage Collector macht das schon. Warum brauche

00:13:52.753 --> 00:13:53.988
dann unbedingt dieses Usen-Keyword.

00:13:54.402 --> 00:13:56.184
Ist mir ja gut, ob das jetzt später aufgeschlüsselt wird oder nicht.

00:13:56.562 --> 00:14:01.253
Weil das halt eben nicht Garbage Collection ist. Du willst halt von Usen eine Garantie haben,

00:14:01.253 --> 00:14:03.053
dass wenn Scope Ende Sachen passieren.

00:14:03.215 --> 00:14:06.789
Und beim Garbage Collector hast du die Garantie, die Finalization Registry,

00:14:07.053 --> 00:14:11.038
du kannst das ja damit umsetzen, wenn du willst. Aber das würde halt eben bedeuten, dass die Datei halt

00:14:11.137 --> 00:14:15.053
irgendwann geclosed wird. Und dieses irgendwann könnte halt eben auch bedeuten,

00:14:15.206 --> 00:14:17.520
Nutzer macht beim Browser oben das X.

00:14:17.826 --> 00:14:21.553
Und das sind alles so Sachen, die willst du nicht haben.

00:14:21.553 --> 00:14:28.277
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,

00:14:28.754 --> 00:14:36.073
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.

00:14:36.622 --> 00:14:40.993
Und für sowas wie ein User Interface, wo ich am Ende einfach nur ein paar Buttons anklicke, ist das ja okay.

00:14:40.993 --> 00:14:43.536
Das ist halt eben nicht eine Automotive-Rust-Echtzeitanwendung.

00:14:45.030 --> 00:14:49.009
Nee, ich versteh. Ich fühl sie trotzdem nicht richtig. Nee.

00:14:49.120 --> 00:14:55.780
Und ich meine, es passt halt auch so ein bisschen zu dem, was du so ganz zu Beginn sagtest in unserer sogenannten Vorbesprechung,

00:14:55.820 --> 00:14:57.780
weiß Gott, wo die hingeschnitten wird.

00:14:58.129 --> 00:15:03.240
Als du so gesagt hast, TypeScript wird das neue C++ durch diese vielen, vielen Sachen, die da so drin sind.

00:15:03.280 --> 00:15:05.403
Weil genau daran hab ich halt eben auch gedacht.

00:15:06.186 --> 00:15:10.580
Ich meine, in der Ankündigung da bei TypeScript, da machen sie ja im Prinzip das Szenario auf

00:15:10.620 --> 00:15:11.884
mit ihrer temporären Datei,

00:15:12.120 --> 00:15:19.920
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

00:15:19.920 --> 00:15:25.757
an C++, dass man halt eben eine sehr große Kanone auf seinen Fuß richtet und dann ist vorbei. Und,

00:15:26.800 --> 00:15:30.840
als Gegenargument kommt dann von den C++-Freunden immer, ja, haha, aber hier im allerneuesten

00:15:30.840 --> 00:15:36.080
Standard gibt es dieses spezielle Sprachmittel und wenn du das verwendest, dann ist diese Fußkanone

00:15:36.080 --> 00:15:40.600
entschärft. Aber sie existiert immer noch, das ist das Problem. Die Fußkanone ist halt eben noch

00:15:40.600 --> 00:15:44.328
Und du kannst halt eben, wenn du, wenn du vorsichtig bist und umsichtig bist,

00:15:44.986 --> 00:15:47.920
dann verwendest du halt das neue Sprachmittel, womit das halt eben nicht mehr passiert.

00:15:47.920 --> 00:15:53.640
Allein, das ist ja irgendwie nicht der Punkt. Der Punkt ist ja, dass man vielleicht die Existenz

00:15:53.640 --> 00:15:57.040
einer Fußkanone per se ausschließen möchte, was ja der Rust-Ansatz ist.

00:15:57.373 --> 00:16:02.240
Und das ist wirklich mehr so der C++-Ansatz. Wenn du alles richtig machst, geht's nicht schief,

00:16:02.240 --> 00:16:04.394
aber wenn du es falsch machst, dann geht es halt richtig schief.

00:16:06.501 --> 00:16:10.030
Nein, es stimmt schon. Es stimmt schon. Ich meine, das ist vielleicht auch ein bisschen,

00:16:10.771 --> 00:16:14.144
dem geschuldet, dass die Programmiersprache jetzt auch schon sehr alt ist und weiter wächst.

00:16:14.252 --> 00:16:17.070
Ich glaube, wir haben eh wieder genau das auch in der Vorbesprechung gehabt.

00:16:17.358 --> 00:16:21.778
Da gibt es jetzt Leute, deren Beruf ist es, JavaScript-Proposals zu schreiben.

00:16:22.615 --> 00:16:26.027
Die werden nicht einmal zu ihrem Chef sagen und sagen, hey, ich bin fertig,

00:16:26.072 --> 00:16:30.465
wir machen bei der Sprache nichts mehr, jetzt ist es vorbei, ich gebe mir eine andere Arbeit.

00:16:30.663 --> 00:16:33.553
Sondern die werden halt weiter Proposals machen, die werden sich weiter Features ausdenken.

00:16:33.787 --> 00:16:37.883
Und wir sind halt dort mittlerweile in einem Punkt, wo ich mir denke, die Features, die wir jetzt haben,

00:16:38.423 --> 00:16:43.391
die sind vielleicht für gewisse Cases jetzt gut, aber sie haben jetzt nicht mehr diese Tragweite,

00:16:43.391 --> 00:16:48.351
wie wir halt damals zum Beispiel in Echmascript 6 oder so, das Spread-Syntax bekommen haben,

00:16:48.351 --> 00:16:54.751
oder das Structuring. Ich glaube, das hat viel mehr verändert, als wie jetzt dieses Simple Dispose,

00:16:54.751 --> 00:16:57.911
wo du dich halt da wirklich fragen musst, okay, wie viele Leute werden das jetzt tatsächlich einsetzen,

00:16:57.911 --> 00:17:02.009
vor allem wenn eh wirklich jeder mit einem Framework arbeitet. Vielleicht wird das Framework das verwenden.

00:17:02.279 --> 00:17:09.571
Und soweit, während die Features immer nuancierter, das kapiere,

00:17:09.931 --> 00:17:15.831
muss man sich aber auch fragen, ob man das Feature wirklich noch irgendwie in sein Verständnis von der Programmiersprache reinziehen will.

00:17:15.831 --> 00:17:22.525
Oder ob man jetzt sagt, im Vergleich zu C++, wir als Team entscheiden uns jetzt, dass wir dieses Subset der Sprache verwenden

00:17:22.651 --> 00:17:26.045
und mit diesem Subset der Sprache kommen wir jetzt klar.

00:17:26.585 --> 00:17:29.751
Ja, ob man damit klarkommt, wird sich dann eben an den Dependencies bemessen,

00:17:29.751 --> 00:17:30.751
die man sich dann reinzieht.

00:17:30.751 --> 00:17:37.991
Also wir sind hier jetzt so der funktionale Shop und wir wollen jetzt hier definitiv hier so Klassen

00:17:37.991 --> 00:17:44.191
irgendwie voll nicht verwenden. Allein dann kommen die Web Components um die Ecke. Und ich habe ja

00:17:44.191 --> 00:17:47.791
dann schon den Fall gedacht, dass die im Laufe der Zeit so ein bisschen das Front entfressen werden

00:17:47.791 --> 00:17:52.711
und das zumindest in irgendeiner Form sicherlich mitbestimmen werden. Es wäre mal Zeit, weil sonst

00:17:52.711 --> 00:17:57.591
wäre es einfach der traurigste Webstandard, den wir je gehabt haben. Weil existieren dann ja schon

00:17:57.591 --> 00:18:02.071
seit ewig. Sie haben keine Ahnung, wie viele Iterationen schon hinter sich, aber ich seh diese

00:18:02.071 --> 00:18:09.631
Adaption davon eigentlich noch nicht. Aber vielleicht bin ich da mittlerweile verblendet.

00:18:09.631 --> 00:18:15.551
Ach du, das hatte ich tatsächlich letztens erst, weil neben Advanced JavaScript habe ich im Herbst

00:18:15.551 --> 00:18:19.711
ganz ganz viele Next Level Web Components mit TypeScript für Workshop und da muss ich natürlich

00:18:19.711 --> 00:18:22.951
auch am Anfang erstmal den Case machen, warum würde man sich damit befassen. Jetzt suche ich

00:18:22.951 --> 00:18:28.331
in meinen Notizen natürlich, wo das ist. Aber irgendein Link, den ich da ausgegraben hatte,

00:18:28.331 --> 00:18:33.411
meinte halt irgendwie so, ja, auf 20 Prozent der Webseiten finden sich halt irgendwelche Tags,

00:18:33.823 --> 00:18:38.891
die Custom Elements sind. Also irgendwas, das ist irgendwas anderes. So, klingt mir jetzt auch

00:18:38.891 --> 00:18:42.091
noch viel. Sehe ich jetzt nicht so richtig. Viele in meinem Universum verwenden immer noch

00:18:42.091 --> 00:18:44.887
auch alle React und Angular, also div, div, div, div, div, div.

00:18:46.588 --> 00:18:51.468
Ne? Aber, ähm, ja. Wahrscheinlich hat's irgendwo App minus Boot.

00:18:52.233 --> 00:18:56.176
Und das ist ein Angular-Web-Komponente, wobei 20 Prozent ist schon viel.

00:18:57.049 --> 00:19:01.798
Ja, das glaub ich nicht. Aber ich hab den Link zu dem Zeitpunkt noch nicht genau angesehen.

00:19:01.858 --> 00:19:04.198
Der kommt noch auf meinen großen Haufen von.

00:19:05.529 --> 00:19:07.464
Vielleicht der Google-Tech-Manager. Ist der ein Web-Component? Vielleicht jetzt.

00:19:08.698 --> 00:19:10.098
So kann man's auch machen.

00:19:10.158 --> 00:19:14.657
Wenn man die Zahl hochpushen will, wenn das ist, wonach sich deine Beförderung bemisst,

00:19:14.918 --> 00:19:16.413
Das können wir mal machen.

00:19:16.458 --> 00:19:20.758
Nee, also, ich glaub, das Problem ist halt einfach ultra, ultra haarig,

00:19:20.798 --> 00:19:22.098
an dem sie da arbeiten.

00:19:22.138 --> 00:19:30.159
Und ich bin ja durchaus der Meinung, dass das was wird. Es ist halt nur wirklich eine sehr undankbare Aufgabe,

00:19:30.303 --> 00:19:35.338
die ganze Legacy, die in den ganzen DOM-APIs und HTML und so drinsteckt,

00:19:35.516 --> 00:19:39.418
irgendwie nachträglich durch eine High-Level-API erklärbar zu machen.

00:19:39.549 --> 00:19:40.008
Ja.

00:19:40.498 --> 00:19:45.978
Also, so machst du ja nicht deinen API-Design. Du machst ja erst mal so, so soll's am Ende aussehen.

00:19:46.038 --> 00:19:49.208
Ich bau mir irgendwie so einen Dummy und dann bau ich das Framework darunter.

00:19:49.958 --> 00:19:56.498
Und man macht ja nicht erst irgendwelchen Low-Level-Kram, dann 20 Jahre Legacy on top und baut dann eine High-Level-API drauf,

00:19:56.558 --> 00:19:58.898
die ein konsistentes Weltbild erschaffen soll.

00:19:58.958 --> 00:20:03.618
Das ist halt einfach die undankbarste aller Aufgaben. Klappt halt schon ganz gut, aber ...

00:20:03.678 --> 00:20:10.578
Es wird halt irgendwann zum Problem werden für diejenigen, die sagen, ich werde niemals eine Klasse nur mit der Kneifzange anfassen.

00:20:10.578 --> 00:20:14.438
Manche Probleme, würde ich behaupten, sind für Klassen ganz gut zu lösen.

00:20:14.498 --> 00:20:16.566
Irgendwelche ORMs oder so gedöhnt, wenn man das verwenden möchte.

00:20:18.880 --> 00:20:23.878
Es ist schwierig, da irgendwie wirklich zu sagen, wir sind jetzt hier der Shop, der sich auf dieses Subset einigt.

00:20:23.938 --> 00:20:26.531
Weil das hast du halt nicht komplett unter Kontrolle.

00:20:26.738 --> 00:20:31.366
Du sitzt dann irgendwie auf dein Framework und plötzlich sagt dein Framework in der Version 2.0,

00:20:33.643 --> 00:20:37.658
hier ist jetzt alles anders. Und dann? Ja, ja. Das sind die harten Probleme in der Softwareentwicklung. Ja.

00:20:38.938 --> 00:20:46.298
Ja, ich würde tatsächlich auch sagen, also was du da so beschrieben hast, von wegen so dem

00:20:46.298 --> 00:20:51.218
relativen Impact von der Spread-Syntax bis hin zu jetzt diesem Using-Symbol, da würde ich halt

00:20:51.218 --> 00:20:55.138
einfach so sagen, das ist glaube ich nicht jetzt irgendwie ein programmiersprachenspezifisches

00:20:55.138 --> 00:20:59.048
Problem, sondern einfach so der Fortschritt der Technik allgemein. Da findest du, das muss da

00:20:59.378 --> 00:21:03.018
glaube ich auch wieder. Also wenn ich jetzt mal ganz plakativ werden möchte, so die Erfindung

00:21:03.018 --> 00:21:07.698
des Rades hat sicherlich insgesamt mehr Impact gehabt, als jetzt so die Erfindung vom E-Bike,

00:21:08.059 --> 00:21:12.818
was jetzt relativ jung ist, heißt aber jetzt ja nicht, dass irgendwie ein E-Bike in den so Form

00:21:12.818 --> 00:21:16.738
der menschlichen Fortbewegungsmittel einzufügende schlechte Idee ist oder dass man irgendwie jetzt

00:21:16.738 --> 00:21:20.498
davon nicht beeindruckt sein soll oder Zeug, sondern ist halt eben einfach so eine inkrementelle

00:21:20.498 --> 00:21:26.018
Verbesserung. Daran ist jetzt ja erst mal nichts verkehrt. Ja, das ist sehr schön gesagt.

00:21:28.566 --> 00:21:33.456
Okay. Wollen wir zum nächsten kommen? Stichwort Klassen. Ja, bitte, das darfst du beschreiben,

00:21:33.496 --> 00:21:38.696
weil ich glaub, ich hab mir das gar nicht durchgelesen, aber es klingt ja jetzt nicht so aufregend.

00:21:38.736 --> 00:21:42.141
Es klingt nicht aufregend, das ist, glaub ich, auch nicht so aufregend,

00:21:43.033 --> 00:21:44.096
aber es ist dringendst nötig.

00:21:44.136 --> 00:21:47.576
Nämlich Decorator-Metadata. Worum geht's?

00:21:48.704 --> 00:21:52.216
Es gibt ja schon seit ewig und drei Tagen die Arbeit an Decorators.

00:21:52.256 --> 00:21:55.186
Das heißt so mit etsyntax versehene Annotationen.

00:21:55.753 --> 00:21:59.396
Da haben wir uns schon ewig ausgesprochen über das Thema. Genau.

00:21:59.456 --> 00:22:02.296
Das holt uns mit jeder Typescript-Folge wieder ein.

00:22:02.622 --> 00:22:04.917
Das ist richtig. Aber pass auf, jetzt wird's lustig.

00:22:05.349 --> 00:22:10.396
Weil Typescript hat ja so Legacy-Decorators und unterstützt ja auch die neuen Decorators,

00:22:10.456 --> 00:22:12.996
die jetzt der aktuelle ECMA-Script-Standard sind.

00:22:13.056 --> 00:22:16.926
Wo ich übrigens tatsächlich jetzt einen Beitrag zur Spezifikation geleistet habe.

00:22:17.456 --> 00:22:18.565
Wo? Ja, aha.

00:22:19.556 --> 00:22:23.556
Ich hab mich auf Social Media aufgeregt, über was, was nicht funktionierte.

00:22:23.556 --> 00:22:27.836
Das war echt schräg und dann habe ich das tatsächlich mal da zum Spezifikationsschreiber

00:22:27.836 --> 00:22:31.756
nach GitHub getragen und der hat dann gesagt du hast das falsch gemacht und das falsch gemacht

00:22:31.756 --> 00:22:36.076
dein Babel Plugin macht das falsch aber wenn man alles richtig macht zeigt sich dieser Fehler in

00:22:36.076 --> 00:22:41.636
den Spezifikationen den muss ich ernsthaft reparieren. Also meine Inkompetenz gepaart

00:22:41.636 --> 00:22:46.236
mit Bugs in Babel führt zu einer Verbesserung der zukünftigen Decorators Spezifikation.

00:22:46.236 --> 00:22:53.899
Ich leiste meinen Beitrag. Evaluationsreinfolge.

00:22:54.236 --> 00:22:58.236
Also das ist tatsächlich dafür, dass das Stage 3 ist, ist das teilweise noch ausgesprochen

00:22:58.236 --> 00:23:06.160
doll im Flux, habe ich so den Eindruck. Aber egal. Also TypeScript hat so olle Decorators. Es gibt jetzt die tollen neuen Decorators.

00:23:06.565 --> 00:23:14.236
Die ollen Decorators hatten einen TypeScript Flag, einen Compiler Flag namens Emit Decorator Metadata.

00:23:13.145 --> 00:23:17.250
Da haben sie dann Runtime-Typ-Informationen noch mit ausgegeben, wenn sie das Zeug evaluiert haben.

00:23:17.395 --> 00:23:22.832
Für den Angular-Compiler, der hat das dann aufgenommen und hat so gewusst, welche Komponenten er irgendwie...

00:23:23.435 --> 00:23:26.541
Wo er die Templates kompiliert, kompilieren sie für welche Komponenten.

00:23:27.189 --> 00:23:31.789
Genau, so Zeug ist das jetzt. Und jetzt gibt es für die neuen Decorators ein Feature namens Metadata.

00:23:32.176 --> 00:23:38.316
Stefan, du darfst einmal raten, mit welcher Funktionalität dieses neue Feature nichts zu tun hat.

00:23:38.586 --> 00:23:45.075
Mit den Metadatas vom TypeScript-Compiler. Natürlich hat das damit nichts zu tun, deswegen heißt es ja genauso.

00:23:45.212 --> 00:23:47.595
Mhm, mhm, mhm, mhm. Also ...

00:23:47.813 --> 00:23:49.416
Ah, wunderschön. Ach.

00:23:49.775 --> 00:23:55.515
Oh. Und man darf halt nicht den Legacy-Kram verwenden, man muss den coolen neuen Kram verwenden,

00:23:55.575 --> 00:23:59.735
auch wenn der extrem instabil ist und selbst Honks wie ich da noch Fehler drin finden.

00:23:59.795 --> 00:24:02.315
Der Punkt mit der neuen Metadata ist der folgende.

00:24:02.375 --> 00:24:08.235
Du hast ja bei Decorators in den ganzen Beispielen, in Hello World und so weiter, immer relativ isolierte Use Cases.

00:24:08.295 --> 00:24:13.635
Mach irgendwie ein Logger an das dran, die Nebenwirkung bei dem Ding, das sind alles isolierte Sachen.

00:24:13.695 --> 00:24:19.537
Du hast selten Dinge, die zusammenarbeiten sollen. Obwohl das natürlich in der Realität wahrscheinlich so sein wird.

00:24:19.795 --> 00:24:24.675
Also, machen wir mal die Idee von der Web-Component. Du willst einen Decorator haben, der sagt,

00:24:24.735 --> 00:24:30.175
das ist eine Klasse, die ist dekoriert mit irgendwas, das sagt, du bist unter dem HTML-Tag jetzt zu finden.

00:24:30.235 --> 00:24:34.724
Und du hast hier einen Accessor, der ist ein Attribut, bla, bla, bla. So Zeug.

00:24:35.183 --> 00:24:38.460
Und die müssen ja möglicherweise irgendwie miteinander arbeiten können.

00:24:38.622 --> 00:24:46.031
Die müssen irgendwie wissen, dass sie alle auf der gleichen Klasse rumhacken, um irgendwie durch Komposition tatsächlich eine gemeinsame Wirkung zu erzielen.

00:24:46.301 --> 00:24:49.740
Die müssen irgendwie Daten teilen. Und das geht im Moment nicht.

00:24:50.253 --> 00:24:54.575
Also jeder Decorator sieht nur sein eigenes isoliertes Objekt, das er dekoriert.

00:24:54.575 --> 00:24:59.695
Klassendecorator sieht nur die Klasse und Methodendecorator sieht nur die Methode.

00:25:00.263 --> 00:25:02.946
Und die haben kaum eine Möglichkeit, miteinander zu reden.

00:25:03.819 --> 00:25:07.789
Und jetzt hast du ein Metadata-Objekt, wo du einfach Zeug reinschmeißen kannst,

00:25:07.789 --> 00:25:12.569
das du über alle Dekorator-Aufrufe trägst, oder? So sieht's aus. Okay.

00:25:13.416 --> 00:25:16.791
Und das ist total sinnvoll, weil du halt irgendwie so Sachen hast, also...

00:25:17.341 --> 00:25:20.389
Ich hatte ja vor ein paar Wochen, war ich ja ganz übel krank und lag wirklich fiebrig da nieder

00:25:20.389 --> 00:25:23.469
und mein bescheuertes Gehirn dachte sich, das ist die ideale Gelegenheit,

00:25:23.469 --> 00:25:24.876
eine JavaScript-Library zu schreiben.

00:25:25.092 --> 00:25:27.450
Hat's dann auch gemacht.

00:25:27.729 --> 00:25:31.109
Und leider ist das Ding auch relativ nützlich, sodass ich's benutzen muss.

00:25:31.109 --> 00:25:36.326
Wenn gleich die Codequalität ungefähr dem entspricht, was du da so dir unterm Fieberwahn ausmalen kannst.

00:25:36.750 --> 00:25:40.709
Und es geht tatsächlich um Web Components, wo ich halt so Sachen machen möchte, wie was ich grad beschrieben hab.

00:25:40.709 --> 00:25:43.309
Ein Decorator für eine Klasse, du bist jetzt dieses HTML-Tag.

00:25:43.309 --> 00:25:46.760
Ein Decorator für einen Accessor, du beschreibst jetzt einfach ein Attribut.

00:25:47.075 --> 00:25:51.149
So was ähnliches gibt's auch bei, hier, Lit, dem Web Component Framework,

00:25:51.149 --> 00:25:55.789
aber bei mir halt eben mit viel, viel weniger und mit on top lustiger Fiebersyntax.

00:25:55.915 --> 00:25:58.669
Der Punkt ist halt der, dass man da wirklich so Dinge machen muss wie,

00:25:58.877 --> 00:26:01.209
Naja, ein Attribut muss sich irgendwie initialisieren.

00:26:01.614 --> 00:26:03.774
Wie initialisiert sich das? Na, wenn sich die Klasse konstruiert.

00:26:04.008 --> 00:26:10.749
Wie bringe ich den entsprechenden Callback an? Naja, gar nicht, weil der Attribut-Decorator halt einfach überhaupt keinen Kontext hat,

00:26:10.886 --> 00:26:12.687
dass er zu einer Klasse oder Instanz gehört.

00:26:12.939 --> 00:26:18.457
Und so, wie ich das im Moment halt manage, ist, ich hab halt eben ne ganze Haufen von Weakmaps,

00:26:18.511 --> 00:26:23.066
wo die Dinger sich halt eben, sobald sie sich initialisieren, es in Instanziieren,

00:26:23.579 --> 00:26:28.429
anmelden und sagen, jo, hier, ich bin die Callback-Sammlung von dieser und jenen Instanz,

00:26:28.429 --> 00:26:35.389
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.

00:26:35.444 --> 00:26:37.551
Und genau das ist die Decorators Metadata.

00:26:37.629 --> 00:26:38.919
Und das ist voll nötig.

00:26:39.864 --> 00:26:46.148
Mhm, ich verstehe das, ja. Es klingt ja ziemlich einfach. Also, du hast einfach dieses Metadata-Objekt im Kontext

00:26:46.454 --> 00:26:48.399
und kannst dort ein Property setzen, wie du lustig bist.

00:26:48.777 --> 00:26:53.926
So sieht's aus. Ja. Und dann kannst du es sogar über ein Symbol auf der Klasse,

00:26:54.556 --> 00:26:57.239
kriegen, oder auf der Instanz. Nein, auf der Klasse.

00:26:58.499 --> 00:27:04.666
Ähm, ja, weil du dekorierst ja die Klassendeklaration. Und damit hat die Instanz ja per se nichts zu tun.

00:27:04.666 --> 00:27:07.666
Also klar, wenn du immer noch Daten mit der Instanz teilen willst,

00:27:07.666 --> 00:27:13.306
dann ist sicherlich eine Weakmap mit dem This als Key immer noch der richtige Weg.

00:27:13.524 --> 00:27:18.124
Aber für so Sachen wie, ne, die Dinger, die halt im Prinzip jede Instanz betreffen.

00:27:18.412 --> 00:27:24.516
Wo eben gesagt wird, das sind Initialisierungscallbacks, die müssen ausgeführt werden, wenn z.B. eine Webcomponent sich connectet.

00:27:24.876 --> 00:27:31.866
Du musst dann ja irgendwie eine Möglichkeit haben, im Connected Callback auf Daten zuzugreifen, die befüllt werden von diesen ganzen Deklarationen.

00:27:31.866 --> 00:27:36.666
Und wir reden da noch nicht über das Timing. In welcher Reihenfolge sich was initialisiert, das macht das alles noch viel komplizierter.

00:27:36.831 --> 00:27:38.469
Und das geht damit halt eben einfach mal alles weg.

00:27:39.522 --> 00:27:43.150
Weil es halt eben so den Scope gibt, der sagt so, das ist die Klasse.

00:27:43.412 --> 00:27:46.506
Und sobald sich halt eben was konstruiert, ist die Klasse komplett evaluiert.

00:27:46.506 --> 00:27:50.746
Und dann finde ich da alles drin, was sich dort registriert hat und kann das halt eben alles bequem ausführen.

00:27:51.460 --> 00:27:55.547
Ohne irgendwie Timing-Probleme und lauter Verrenkungen, die ich da machen musste.

00:27:56.582 --> 00:28:02.289
Das wird voll gut. Ja, okay, das klingt wirklich sinnvoll und brauchbar. Nötig, würde ich sagen.

00:28:02.361 --> 00:28:06.506
Weil das halt eben, wie gesagt, die Hallo-Welt-Beispiele, die funktionieren ohne. Sobald du was

00:28:06.506 --> 00:28:11.906
Ernsthaftes bauen willst, brauchst du Kontext. Und den gab es vorher nicht oder nur unter großen

00:28:11.906 --> 00:28:18.026
Mühen und damit geht das dann viel besser. Ich bin schon gespannt, wann dieses Feature rund um

00:28:18.026 --> 00:28:21.106
die Decorators wirklich in einer populären Bibliothek aufschlägt. Das werden wir lang

00:28:21.106 --> 00:28:24.660
darüber gesprochen, dass das ja wirklich, dass man mit mit Klassen und Deckgeräten,

00:28:24.826 --> 00:28:27.826
das kann man wirklich tolle Sachen designen. Also da kann man wirklich, glaube ich, schöne,

00:28:28.522 --> 00:28:32.946
schöne Frameworks, die minimalistisch sind, machen. Ich warte nur, dass das passiert. Ich

00:28:32.946 --> 00:28:35.106
glaube, ich glaube, Peter, das musst du machen. Ich glaube, du...

00:28:35.106 --> 00:28:40.586
Nee, nee, nee. Du kannst, du kannst dir LIT nehmen. Also wirklich LIT.dev, das ist ja die

00:28:40.586 --> 00:28:45.506
Web Component Library da. Also es hat nicht auch irgendein Google-Produkt, das demnächst

00:28:45.506 --> 00:28:49.546
eingestampft wird. Ich habe keine Ahnung. Wenn du da mal auf die Seite gehst und dir da unten

00:28:49.546 --> 00:28:51.973
das Code-Sample anschaust, das verwendet die.

00:28:54.205 --> 00:28:57.026
Da hast du so ein Decorator-Custom-Element mit einem Tag-Namen.

00:28:57.026 --> 00:29:02.073
Das mit einem Decorator Property für eine IDL DOM Property.

00:29:05.467 --> 00:29:09.113
Und das ist halt schon ganz gut. Vor allen Dingen, wenn du halt mal vergleichst,

00:29:09.824 --> 00:29:13.317
wenn das jetzt ein Attribut wäre, das ist jetzt bei denen da alles ein bisschen anders, als es bei mir ist,

00:29:13.317 --> 00:29:17.317
also von der Syntax her, von der Oberfläche her sieht das, was ich da im Fieberwahn zusammengehauen habe,

00:29:17.317 --> 00:29:19.088
genauso aus wie das, aber

00:29:19.317 --> 00:29:21.317
funktioniert schon ein bisschen anders, weil ich halt wirklich so nach den Spezifikationen

00:29:21.317 --> 00:29:25.317
gegangen bin, und da ist es halt wirklich so, wenn du sowas hast wie ein Attribut auf einer Web-Component,

00:29:25.317 --> 00:29:27.317
das ist ja irre kompliziert.

00:29:27.317 --> 00:29:31.317
Du musst ja irgendwie aus dem String des HTML irgendwie zum Beispiel eine Zahl rausparsen,

00:29:31.547 --> 00:29:35.238
die willst du gegebenenfalls irgendwie klempen, höchstens so groß, höchstens so klein.

00:29:35.317 --> 00:29:39.317
Du musst irgendwie mit Unter Number umgehen, du musst das irgendwie in einen Getter und Setter verpacken,

00:29:39.317 --> 00:29:42.853
du willst es vielleicht Read-Only machen, Black-X. Das ist halt monströs komplex,

00:29:43.317 --> 00:29:47.317
aber im Prinzip ja für jedes Attribut gleich.

00:29:47.913 --> 00:29:51.317
Sodass du wirklich das machen kannst, wie hier in dem Beispiel. Du sagst einfach, es gibt ein Ding, das heißt

00:29:51.317 --> 00:29:52.936
Name, und das verhält sich wie eine,

00:29:53.377 --> 00:29:59.317
IDL-JavaScript-Property auf einem HTML-Element. Und das ganze Handling von Attribute-Change-Callbacks

00:29:59.317 --> 00:30:05.517
und Initialisierung und aus einem String parsen und zunehmende Strings serialisieren, das kannst du alles vereinheitlichen damit und dann kannst du

00:30:05.517 --> 00:30:10.437
wirklich Web-Components bauen, wo du nicht mal sagen kannst, das Äquivalent von Hand geschrieben

00:30:10.437 --> 00:30:13.757
wäre so lang, weil du würdest das nicht so schreiben, weil du wahnsinnig werden würdest

00:30:13.757 --> 00:30:18.854
und sagen würdest, das mache ich so nicht, ich nehme halt hier irgendwelche Shortcuts. Und das

00:30:19.157 --> 00:30:24.357
kann halt eben echt schon sehr, sehr nice werden und ich glaube, dieses Lit ist halt im Moment unter

00:30:24.357 --> 00:30:29.278
den Dingern, die wirklich publik sind, das, was das beste Beispiel ist, wie das aussehen kann.

00:30:30.647 --> 00:30:33.997
Es ist halt natürlich in dem Ding, weil es ein Framework sein will,

00:30:33.997 --> 00:30:35.301
wieder viel zu viel Scheiß noch mit drin.

00:30:35.526 --> 00:30:39.437
Mit HTML-Renderer und DOM-Diffing und CSS und JavaScript, bla bla bla.

00:30:39.550 --> 00:30:44.510
Das ist alles Scheiß, den keine alte Sau braucht. Aber der Kern mit den Decorators, wie sie es hier verwenden,

00:30:44.753 --> 00:30:46.130
das ist, glaube ich, genau, wie es sein kann.

00:30:46.887 --> 00:30:48.237
Wenn man auf den ganzen Rest verzichtet.

00:30:49.029 --> 00:30:55.214
Ja, das stimmt schon. Wie populär es liegt, kann man das irgendwie beziffern?

00:30:55.664 --> 00:31:01.077
Äh, nö, aber ich glaube, unsere Web Component Library ist sicherlich eins der populäreren.

00:31:01.077 --> 00:31:03.793
Es ist ja so der Nachfolger von Polymer.

00:31:04.018 --> 00:31:07.877
Das sind ja so die Dinger, die da so...

00:31:09.906 --> 00:31:17.251
Ja, Vorpreschen. Es ist halt immer noch so, die Developer Experience von dem ganzen Kram ist halt immer noch zu schlecht.

00:31:17.675 --> 00:31:20.240
Ja, das mit dem steht zum Fall selber leider, guckt das gar nicht.

00:31:20.436 --> 00:31:25.956
Ja, also das war halt eben auch so meine Überlegung mit meinem Teil, mit meinen Decorators,

00:31:26.073 --> 00:31:31.034
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.

00:31:32.276 --> 00:31:38.983
Und das ist schon dann echt schon ziemlich kompliziert, aber das muss man halt eben, glaube ich, machen, weil sonst,

00:31:39.280 --> 00:31:43.516
Du kannst halt, also das Beispiel, was wir hier halt eben auf der Lit-Webseite haben,

00:31:43.745 --> 00:31:47.516
das ist, würde ich sagen, schon konkurrenzfähig zu Angular oder React oder so.

00:31:47.516 --> 00:31:50.716
Das kannst du irgendwie einem Entwickler oder einer Entwicklerin aus dem Angular- oder React-Feld zeigen

00:31:50.716 --> 00:31:54.251
und die würden sagen, das ist jetzt nicht so eine arg üble Zumutung,

00:31:55.268 --> 00:31:56.429
wenn du dir das Beispiel anschaust.

00:31:56.861 --> 00:32:00.416
Aber trotzdem hast du halt dadurch, dass das halt eben wirkliche Web-Components,

00:32:00.416 --> 00:32:04.855
wirkliche HTML-Elemente sind, da ein Layer an Komplexität noch on top,

00:32:05.044 --> 00:32:09.221
den du in React nicht hast, weil React halt keine Attribute zum Beispiel hat.

00:32:09.447 --> 00:32:13.476
Da musst du dir nicht überlegen, wie wird was zu einem String oder aus einem String rausgepasst.

00:32:13.476 --> 00:32:20.177
Das Problem existiert da einfach nicht. Das ist aber notwendigerweise bei Web Components als essentielle Extrakomplexität on top.

00:32:20.348 --> 00:32:23.445
Das heißt, du hast ohnehin verloren, wenn es jetzt darum geht,

00:32:23.688 --> 00:32:26.116
die Developer Experience so gut zu machen wie React.

00:32:26.299 --> 00:32:28.261
Das kannst du aufgrund des anderen Scopes gar nicht schaffen.

00:32:29.297 --> 00:32:33.780
Aber du kannst halt andere Dinge rausholen, mit denen du die Web Components vielleicht verkaufen kannst.

00:32:34.329 --> 00:32:35.634
Zum Beispiel, funktioniert überall.

00:32:35.823 --> 00:32:38.659
Kannst du auch in dein Angular-Projekt reinwerfen, bist nicht auf React beschränkt.

00:32:39.253 --> 00:32:41.693
Wird bis in alle Ewigkeit halten, weil's ein Browser-Standard ist.

00:32:41.900 --> 00:32:44.240
Trifft vielleicht weniger zu, wenn du LIT hast mit irgendwie,

00:32:44.528 --> 00:32:48.498
da musst du aus NPM irgendwie 70 Sachen installieren, aber von der Theorie könnte es halt so sein.

00:32:48.849 --> 00:32:51.796
Und es könnte halt mit klassischen DOM-Programmiertechniken,

00:32:51.796 --> 00:32:53.882
so jQuery-Style, kombiniert werden,

00:32:54.188 --> 00:32:58.167
mit so Sachen wie Event-Delegation, das könnte ja auch in solche Decorators reingegossen werden,

00:32:58.316 --> 00:33:01.556
dass du so ein Ding hast, addListen, das Ding lauscht auf seinem Shadow DOM,

00:33:01.556 --> 00:33:06.998
und wenn da ein Klick passiert auf einem Ding, auf das der Selector matcht, dann wird diese Methode ausgeführt und so weiter.

00:33:08.204 --> 00:33:12.574
Das könnte also alles sein, aber es sind halt unglaublich harte, dicke Bretter, die da gebohrt werden müssen.

00:33:12.574 --> 00:33:17.774
Verglichen zu, ich bin React, ich vereinfache meinen Scope, für mich gibt es kein HTML, ich bin nur das DOM.

00:33:18.035 --> 00:33:27.134
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.

00:33:27.134 --> 00:33:29.477
Du hast mit React ja da ganz anderen Schwungen Probleme drinnen.

00:33:30.350 --> 00:33:35.121
Wir haben damals auch entschieden, dass wir React verwenden.

00:33:35.715 --> 00:33:42.294
Der Grundführerjekt war ganz ganz einfacher, macht jeder andere. Das heißt, wir haben dort viel weniger Probleme mit Onboarding.

00:33:43.844 --> 00:33:47.958
Es gibt genug Komponenten draußen, Bibliotheken draußen, wo sich wirklich eine Vielzahl an Entwicklerinnen und Entwicklern.

00:33:48.850 --> 00:33:50.994
Daran bedienen können und wir als,

00:33:51.854 --> 00:33:59.154
Applikations-Framework-Bereitsteller müssten uns nicht darum scheren. Erstens ein sehr gutes Argument, zweitens ein Argument.

00:33:59.670 --> 00:34:10.674
Ja, genau. Das Problem dabei ist noch das, dass du trotzdem, auch wenn React wirklich nur minimalistisch

00:34:10.674 --> 00:34:19.314
im Framework approach ist, musst du dich mit den inneren Begebenheiten der Bibliothek auseinandersetzen

00:34:19.314 --> 00:34:29.674
über kurz oder lang. Diese Schuld kriegst du nicht weg. Es kommt irgendwo der Punkt,

00:34:29.674 --> 00:34:33.914
wo die Applikation langsam wird, weil du ständig Layout-Freshen machst oder wo du eine State-Management-Lösung

00:34:33.914 --> 00:34:37.714
auswählst, die nicht zu dem passt, wie die Applikation sein soll. Du musst dich über

00:34:37.714 --> 00:34:43.794
kurz oder lang wirklich mit dem Ding beschäftigen und damit machst du ein hornistenes Dauf.

00:34:43.980 --> 00:34:48.854
Also da merkst du nachher, dass du vom Hundertsten ins Tausendste kommst und vielleicht auch die

00:34:48.854 --> 00:34:52.854
Bibliotheken, die du verwendest, die Komponenten, die du verwendest, nicht zusammenspielen mit dem,

00:34:52.854 --> 00:34:56.734
wie du deine Applikationen strukturiert hast, wird alles sehr schwierig, wird alles sehr,

00:34:56.734 --> 00:35:03.654
sehr schwierig. Diese Probleme hast du nach wie vor und da hilft dir auch React nicht,

00:35:03.654 --> 00:35:07.894
egal wie einfach das ist. Das ist richtig, aber pass auf, für den Marketing-Pitch sind das ja

00:35:07.894 --> 00:35:11.934
irgendwelche Externalitäten, die irgendwelche anderen ausbaden müssen. Ja, aber das sind die

00:35:11.934 --> 00:35:13.867
die Probleme, die du hast, wenn du wirklich damit arbeitest.

00:35:15.163 --> 00:35:22.707
Ja, das muss ja keiner mitkriegen. Ich bin mir nicht gegangen, das kriegen sie halt früher oder später mit.

00:35:22.934 --> 00:35:26.884
Glücklich der, der nach einem Projekt nach drei Wochen gehen kann und das nächste macht

00:35:26.947 --> 00:35:29.934
und sich nicht mehr über die ganzen Sachen, die er verbrochen hat, kümmern muss.

00:35:30.134 --> 00:35:34.934
Ich würde mal sagen, das hast du vielleicht bei Webstandards, die werden schon anders gestaltet.

00:35:34.934 --> 00:35:39.934
Die werden so gestaltet, dass du halt in dem großen ganzen Web-Ökosystem auch gut damit umgehen kannst.

00:35:39.934 --> 00:35:45.774
Kannst. Du musst halt auch ein paar Techniken lernen, ganz klar, aber das weißt du dann auch schon. Also

00:35:45.774 --> 00:35:49.774
die Sachen haben ja eine Langlebigkeit dahinter und die sind auch inspiriert von dem, was schon

00:35:49.774 --> 00:35:53.054
da war und solche Sachen. Von dem her denke ich mir, das ist vielleicht gar nicht so schlecht.

00:35:53.207 --> 00:36:00.814
Es ist trotzdem der schwerste Weg, den man beschreiben kann.

00:36:06.512 --> 00:36:09.402
Meine Meinung zu React hat sich ja sehr stark konkretisiert,

00:36:09.462 --> 00:36:13.862
als ich letztens mal an einem JSF-Projekt ein bisschen Legacy-Beratung machen durfte.

00:36:13.922 --> 00:36:15.062
Du armer Mensch, ja.

00:36:15.122 --> 00:36:19.522
Na ja, ich meine, Codebase. Ich war dann derjenige, der nach so drei Wochen

00:36:19.582 --> 00:36:22.802
und so hier, damit könnt ihr die dringendsten Feuer austreten,

00:36:22.862 --> 00:36:26.462
sagen konnte, guten Tag, noch viel Spaß, ich mach jetzt was anderes.

00:36:26.947 --> 00:36:32.462
Mir geht's gut. Ich hab nur das Zeug aufgemacht, hab so dieses XML-Zeug gesehen mit irgendwelchen Komponentennamen,

00:36:32.522 --> 00:36:35.904
die nix mit HTML zu tun haben, mit irgendwelchen On-Click-Geschichten.

00:36:36.310 --> 00:36:39.055
Und dachte so, ach, das ist genau wie React, das kenn ich.

00:36:40.235 --> 00:36:45.102
Und weißt du, was es ist? Es ist genau wie React, und das kenn ich. Ja, ja.

00:36:45.807 --> 00:36:50.515
Ja, genau. Es ist die gleiche Idee. Du machst halt einfach ein, du machst Tabula rasa

00:36:50.794 --> 00:36:52.883
und sagst, ich mach jetzt hier einen neuen Überbau.

00:36:53.402 --> 00:36:59.002
Der Überbau war halt eben da bei dem JSF-Java-XML-Gebimsel. Wir machen alles in XML, wir haben Komponenten,

00:36:59.062 --> 00:37:00.642
die sind da drin implementiert.

00:37:00.702 --> 00:37:06.242
Wir haben auch so Sachen wie UI-Frameworks und so was. genau da ist es halt nur eine andere Darreichungsform, aber die gleiche Idee.

00:37:06.502 --> 00:37:08.502
Und hinterher hast du genau die gleichen Probleme.

00:37:09.069 --> 00:37:12.502
Nämlich, es ist viel zu viele Abstraktionsschichten. Wie kriege ich diese einfache Sache jetzt zum Funktionieren?

00:37:12.502 --> 00:37:15.145
Und du kämpfst irgendwann einfach gegen das Framework an.

00:37:17.801 --> 00:37:21.906
Und auch das ist einfach wirklich so ein Pattern, das man dann einfach wiederkehrend sieht.

00:37:22.806 --> 00:37:26.502
Also genau der Scheiß, auf den ich keinen Bock habe. Weswegen ich vielleicht sage,

00:37:26.502 --> 00:37:30.502
Web Component, okay, muss man vielleicht irgendwie mehr Energie reinstecken,

00:37:30.502 --> 00:37:32.493
aber vielleicht lohnt es sich irgendwie auf lange Sicht.

00:37:32.808 --> 00:37:37.082
Unter der Voraussetzung, dass du für die lange Sicht daran interessiert bist.

00:37:37.082 --> 00:37:41.662
Wenn deine Perspektive ist, ich bin da Startup, und wenn ich in zwei Jahren nicht die Kiste am Laufen habe,

00:37:41.765 --> 00:37:43.602
dann ist sowieso Feierabend Mai.

00:37:43.755 --> 00:37:47.362
Dann nimmst du Next.js, Material.UI und dann nach mir die Sintflut.

00:37:47.509 --> 00:37:50.299
Das ist dann der richtige Approach. Nur, das sind halt nicht alle.

00:37:50.444 --> 00:37:51.415
Das sind halt nicht viele.

00:37:51.812 --> 00:37:55.062
Ja, na, absolut. Also, bei mir ist halt auch der Anspruch jetzt der,

00:37:55.062 --> 00:37:58.933
möchte ich in einem halben Jahr wieder aufmachen können und weiter daran arbeiten.

00:38:00.175 --> 00:38:12.670
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.

00:38:13.002 --> 00:38:16.748
Also, das sind auch Probleme.

00:38:17.756 --> 00:38:21.348
Ja, muss man ja nicht haben. Man kann sich ja dazu entscheiden.

00:38:22.465 --> 00:38:26.849
Man muss ja nicht komplett runter auf Stom gehen. Aber man kann ja vielleicht wirklich sagen,

00:38:27.242 --> 00:38:31.962
weniger Libraries, weniger Dependencies, weniger fanzige Framework.

00:38:32.790 --> 00:38:36.895
Ich schreib mal ein paar Sachen mehr. Ich hab ja den Eindruck, manche da draußen haben ernsthaft eine Code-Allergie.

00:38:37.372 --> 00:38:41.927
Die wollen so wenig tippen wie möglich, aber so viel npm install tippen wie möglich. Ja, ja, das stimmt.

00:38:42.216 --> 00:38:44.042
Und vielleicht ist ja gar nicht so schlecht, wenn so Sachen,

00:38:44.042 --> 00:38:46.042
ich mein, das predige ich, glaube ich, jetzt hier auch nicht zum ersten Mal,

00:38:46.267 --> 00:38:49.762
aber so Sachen wie die Dinge, mit denen die Nutzer interagieren, so das User Interface,

00:38:49.762 --> 00:38:53.202
mit dem, was so die unmittelbare Erfahrung meines Produkts ist.

00:38:53.774 --> 00:38:56.202
Wenn ich das nicht vielleicht zu 100% aus der Hand gebe.

00:38:57.934 --> 00:39:01.883
Ist das vielleicht eine Idee? Schaffe ich einen Wert in meiner Firma,

00:39:01.943 --> 00:39:06.764
der da drin bleibt, egal wie der Framework- und Design-Wind sich da grade dreht?

00:39:07.206 --> 00:39:12.583
Ja, das sehe ich genauso. Ich möchte jetzt was fragen. Wollen wir noch ein paar Features durchgehen,

00:39:12.643 --> 00:39:15.083
die grad so in dieser TypeScript ...

00:39:15.938 --> 00:39:19.827
Im TypeScript-Release drinnen sind? Oder sind die eh wohl eher so nett?

00:39:19.971 --> 00:39:22.643
Ich find, zwei können wir erwähnen.

00:39:22.852 --> 00:39:24.184
Ja. Die nächsten zwei?

00:39:24.661 --> 00:39:32.637
Äh ... äh, warte mal, Reihenfolge. Genau, die nächsten zwei, ja, würde ich sagen, genau, die sind das.

00:39:33.033 --> 00:39:34.943
Das erste ist relativ einfach erklärt.

00:39:35.032 --> 00:39:41.943
Du hast die Möglichkeit gehabt, mit Tuple-Typen, sprich, Tuple kannst du dir vorstellen wie ein Array mit fixer Länge,

00:39:41.943 --> 00:39:44.565
wo jedes Element einen spezifischen Typ hat,

00:39:45.546 --> 00:39:50.507
wohingegen das Array eine Variable-Länge hat und alle Elemente haben den gleichen Typ.

00:39:51.407 --> 00:40:00.643
Du hattest die Möglichkeit, dass du in Tuple-Typen mit Labels den einzelnen Stellen im Tuple einen Namen geben konntest.

00:40:00.643 --> 00:40:03.683
Das ist rein auf der Typ-Ebene, das ist nur ein ganzer Anhängsel,

00:40:03.992 --> 00:40:06.723
damit du mehr Metainformationen bekommst,

00:40:06.723 --> 00:40:15.843
beziehungsweise nimm TypeScript auch diese Labels her, wenn du die Parameterliste einer Funktion extrahieren willst,

00:40:15.843 --> 00:40:17.162
dass die Namen der Parameter dort aufscheinen.

00:40:19.899 --> 00:40:21.603
Das ist quasi die Idee. Das funktioniert soweit ganz gut,

00:40:21.603 --> 00:40:27.983
Problem ist, wenn du irgendwelche Typen hast, die jetzt kein Label haben oder Tuple-Elemente,

00:40:27.983 --> 00:40:32.063
die kein Label haben, dann hast du die nicht mischen können. Also du hast nicht was mischen

00:40:32.063 --> 00:40:36.423
können zwischen hat ein Label und hat kein Label, das hat dann Fehler geworfen und diese Änderung

00:40:36.423 --> 00:40:39.983
macht es jetzt möglich, dass du die mischen kannst. Die Labels werden nachher weggeschmissen,

00:40:39.983 --> 00:40:44.503
aber zumindest gibt es keinen Fehler mehr, wenn du diese Tuple irgendwie miteinander kombinierst.

00:40:45.042 --> 00:40:46.951
Ja. Nett.

00:40:48.503 --> 00:40:54.503
Findest du? Ich hab folgendes Problem. Wenn mein Turpel so komplex ist, dass es Namen bräuchte,

00:40:54.855 --> 00:40:58.384
tragen die Namen zur Übersichtlichkeit nicht bei, sondern machen nur noch mehr Line Noise.

00:41:00.580 --> 00:41:06.503
Das kann ich nicht ganz bestätigen. Ich finde diese Labels dann gut,

00:41:06.503 --> 00:41:11.003
wenn du zum Beispiel so was wie einen React-Hook schreibst. schreibst.

00:41:12.121 --> 00:41:20.326
Also React-Hooks verwenden hauptsächlich tuple, weil du die Rückgabe-Werte dann gut benamsen kannst.

00:41:20.448 --> 00:41:26.566
Das heißt, wenn du setState schreibst, kannst du genau sagen, welchen Namen hat das jetzt,

00:41:26.566 --> 00:41:29.550
beziehungsweise welchen Namen hat die set-Funktion dazu.

00:41:29.766 --> 00:41:35.766
Und damit klar ist, was an welcher Stelle kommt, ist es schon hilfreich, dass du dort im Typen auch die Annotation hast,

00:41:35.766 --> 00:41:39.281
hey, das ist jetzt der Wert und das andere ist der setter, zum Beispiel.

00:41:39.650 --> 00:41:46.825
Da finde ich das gut. Beziehungsweise wenn du halt Funktionen, also Parameterlisten von Funktionen generierst,

00:41:47.545 --> 00:41:50.507
dann ist ja auch der Name dieses Parameters wichtig.

00:41:50.795 --> 00:41:54.144
Der darf nicht nur Strings sein oder Numbers, sondern der hat halt auch einen Sinn.

00:41:55.170 --> 00:41:59.766
Username und Passwort sind beide Strings, aber sind sehr unterschiedliche Sachen in der Parameterliste.

00:41:59.766 --> 00:42:00.766
Genau, und da finde ich das super.

00:42:01.184 --> 00:42:06.886
Man kann darüber streiten, ob es jetzt wichtig ist, ob man dieses Mischen kann mit etwas, das keine Labels hat.

00:42:06.886 --> 00:42:11.886
Es ist wahrscheinlich ein nerviger Fehler und dass der jetzt nicht mehr stattfindet, finde ich okay.

00:42:12.518 --> 00:42:14.886
Ja, ich habe dir jetzt auch nichts dagegen, dass sie das eingeführt haben.

00:42:14.886 --> 00:42:16.886
Ich denke halt nur so, ah, nett, ich werde das nicht benutzen.

00:42:16.886 --> 00:42:20.886
Genau, nett. Ich verwende Labels bei Doppeltypen sehr oft.

00:42:20.886 --> 00:42:25.886
Ich bin ja auch von React runtergekommen, von daher bin ich da vielleicht dann einfach weniger betroffen.

00:42:25.886 --> 00:42:30.886
Das nächste Feature ist eigentlich, oh gut, dass das endlich funktioniert.

00:42:30.886 --> 00:42:34.846
Endlich funktioniert. Das hat einen ziemlich spannenden Fehler gegeben, dass wenn du jetzt

00:42:34.846 --> 00:42:41.246
zum Beispiel einen Union-Typen von StringArray oder NumberArray, dann hast du dort nicht auf

00:42:41.246 --> 00:42:46.326
Array-Funktionen zugreifen können, weil es laut Typescript zwischen String und Number keinen

00:42:46.326 --> 00:42:52.046
Schnitttyp gegeben hat. Das heißt, du hast gesagt, Moment, wenn du dort jetzt auf ein Element

00:42:52.046 --> 00:42:55.206
zugreifst oder einen Filter machst und so weiter, was ist das für ein Typ, weil du hast zwei

00:42:55.206 --> 00:43:01.806
unterschiedliche Arrays, passt irgendwie nicht zusammen. Und dieses Beispiel wird jetzt transformiert,

00:43:01.806 --> 00:43:05.766
also vom String Array oder Number Array, wird in ein String oder Number Array transformiert.

00:43:05.928 --> 00:43:11.646
Und damit hast du jetzt nicht eine Schnittmenge dazwischen, sondern eine Vereinigungsmenge fürs

00:43:11.646 --> 00:43:15.446
Element und kannst eben wieder solche Filteroperationen und so weiter anwenden.

00:43:17.595 --> 00:43:22.445
Ja, das ist voll okay. Also auch sowas, wo man denkt, ja gut, das hätte eigentlich schon existiert.

00:43:22.708 --> 00:43:27.445
Genau, das wird den meisten halt nur auffallen, weil plötzlich Code, der vorher nicht funktioniert hätte,

00:43:27.839 --> 00:43:30.445
plötzlich funktioniert. Und zwar genauso, wie man es erwarten würde.

00:43:30.445 --> 00:43:33.445
Und keiner wird das hier mitkriegen, dass diese Arbeit geleistet wurde.

00:43:33.445 --> 00:43:36.445
Genau. Aber ich bin sehr froh, dass sie das gemacht haben.

00:43:36.445 --> 00:43:43.445
Naja, das ist super. Und weitere kleine Editor-Verbesserungen und so weiter.

00:43:43.445 --> 00:43:46.445
Ja, Performance hier, Refactoring da.

00:43:46.445 --> 00:43:51.445
Es gibt jetzt einen ziemlich coolen Performance-Pool-Request von Prof. Blumberg.

00:43:51.445 --> 00:43:53.919
Ich muss mir das mal im Detail anschauen.

00:43:54.445 --> 00:43:59.329
Aber die gehen mit isolated declarations, machen so ein paar Abkürzungen,

00:44:00.194 --> 00:44:03.587
in dem welche Deklarationen nachher vom Typ-Check geermittet werden.

00:44:04.803 --> 00:44:10.445
Und der soll ziemlich einen Performance-Gewinn vorsorgen, soweit ich das mitbekommen habe.

00:44:10.445 --> 00:44:13.382
Das ist aber dann wahrscheinlich was für das nächste Release.

00:44:13.445 --> 00:44:15.929
5.3, so ein kleiner Spoiler. Aha.

00:44:17.613 --> 00:44:21.445
Interessant. Also dann, wenn mich Kompilierzeit interessiert, verwende ich ja meistens nicht den

00:44:21.445 --> 00:44:25.445
TypeScript-Compiler. Ja. Das stimmt. Also bei mir ist auch

00:44:25.445 --> 00:44:27.445
so Typ-Checken im Hintergrund während dem Entwickeln

00:44:27.445 --> 00:44:31.278
und Compilen noch mit irgendwas, was schnell ist und Typen ignorieren.

00:44:32.115 --> 00:44:35.445
Ja, nee, also halt so, ne, Dev-Mode heißt halt, das Babel-Plugin streicht

00:44:35.445 --> 00:44:37.445
einfach die Typen raus und ich hab halt einfach einen besseren

00:44:37.445 --> 00:44:41.445
Linter in meiner IDE. Exakt. Und wenn ich's dann baue, dann jag ich's durch CSC durch,

00:44:41.445 --> 00:44:43.045
um die DTS-Dateien zu kriegen.

00:44:43.105 --> 00:44:46.204
Aber irgendwie scheint mir so, mein TypeScript kompiliert zu langsam,

00:44:46.705 --> 00:44:49.760
ist da doch ein Anforst-Error auf Benutzerseite, würde ich fast sagen.

00:44:51.101 --> 00:44:53.705
Aber das weiß auch nicht jeder, ist auch geheimes Templar-Wissen.

00:44:53.765 --> 00:44:57.145
Du würdest meinen, okay, ist ein Compiler, also verwende ich den.

00:44:57.205 --> 00:45:00.248
Dass man den nicht verwenden sollte, weil's ewig lange dauert,

00:45:00.505 --> 00:45:01.391
ist ja nicht offensichtlich.

00:45:02.957 --> 00:45:06.108
Vielleicht sollten die einen No-Check-Flag in ihren Compiler einbauen, das würde helfen.

00:45:06.665 --> 00:45:10.505
Ich meine das ernst. Ja, ich glaub, das gibt's sogar.

00:45:11.482 --> 00:45:17.825
Ist wahrscheinlich auch langsam. Ja. Also, ich glaub, Peter, ich muss ein bisschen auf die Uhr schauen.

00:45:18.054 --> 00:45:18.666
Leider kann ich das nicht.

00:45:19.425 --> 00:45:26.025
Aber wir haben eine feste Sendung. Dann schauen wir einfach mal auf den Aufnahme-Anhalten-Button.

00:45:26.065 --> 00:45:28.865
Liebe Hörerinnen und Hörer, wir danken fürs Zuhören.

00:45:28.905 --> 00:45:35.185
Wir sehen euch in unserem Slack, im FairDiverse und hier auf ... unter welchem Namen jetzt auch immer.

00:45:35.185 --> 00:45:38.825
Gerade da Ilons Trümmergruppe da jetzt gerade unterwegs ist.

00:45:38.825 --> 00:45:45.385
Da sehen wir euch und auch in der nächsten Sendung, in der es gehen wird um dich, Stefan.

00:45:45.835 --> 00:45:47.425
Das war spannend.

00:45:47.969 --> 00:45:51.813
Wir danken fürs Zuhören. Bis zum nächsten Mal. Tschüssi. Tschüss.

00:45:52.560 --> 00:46:15.120
Music.

00:46:15.111 --> 00:46:36.400
Ich höre dich geklaut deutlich. Und jetzt, jetzt, jetzt kannst du auch endlich gehen.

00:46:36.400 --> 00:46:39.640
Mit denen du vor tausenden und abertausenden Standing Ovations bekommst.

00:46:39.640 --> 00:46:44.000
Standing Ovations, ich weiß nicht, ob ich Applaus bekomme. Das waren Standing Ovations.

00:46:44.287 --> 00:46:50.720
Der Inhalt von meinem Vortrag war ja das, dass ich Dinge in Typescript herzeige, die nicht funktionieren,

00:46:50.720 --> 00:46:57.916
wo Typescript uns anlügt, wo das Typ-System etwas anderes vorgibt, als wie die Realität widerspiegelt.

00:46:58.790 --> 00:47:04.800
Und gebe eben vier Probleme an, vier Lösungen und finde nachher wieder vier Probleme zu den Lösungen.

00:47:04.992 --> 00:47:08.680
Und das bauscht sich halt so auf, bis du halt wirklich merkst, okay, also eigentlich alles,

00:47:08.680 --> 00:47:12.160
was wir irgendwie schreiben, ist total verloren und kaputt und am besten sollte man mit der

00:47:12.160 --> 00:47:18.440
Programmiererei aufhören und dann kommt eben dieser Kniff, wo ich sage, aber Moment, trotzdem ist Typescript meine zweite Lieblingsprogrammiersprache,

00:47:19.198 --> 00:47:27.000
weil Typescript macht mich produktiv und diese Schnitzer im Typsystem, diese Kompromisse, die Typescript macht,

00:47:27.741 --> 00:47:33.140
sind ja nicht von irgendwoher, sondern ganz bewusst gemacht und ich verweise eben auf diesen Eindruck, dass Typescript nicht vorhat, ein,

00:47:33.916 --> 00:47:37.481
korrektes Typsystem zu sein, sondern ein produktives Typsystem zu sein.

00:47:38.427 --> 00:47:42.991
Und Philosophie ein bisschen, würde ich sagen, und das war einfach eine Entscheidung, die die Entwickler damals gemacht haben.

00:47:44.440 --> 00:47:50.880
Und genauso wie wir als Entwicklerinnen und Entwickler auch Entscheidungen treffen müssen. Also ich gehe ein wenig so auf den Kniff hin.

00:47:51.570 --> 00:47:52.938
Unsere Aufgabe ist nicht,

00:47:53.388 --> 00:48:00.560
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,

00:48:01.175 --> 00:48:04.506
zu verstehen, was die tut und diese Entscheidung getroffen zu haben, dass die jetzt in unser Codebase,

00:48:05.487 --> 00:48:11.920
kommt. Das würde ich als unsere Aufgabe sehen, weil immerhin sind wir alle Entwickler. Und ich

00:48:11.920 --> 00:48:16.880
habe eben dann diese Slides gehabt, das war der Übergang, we are all developers, also we are

00:48:16.880 --> 00:48:21.240
developers, es war die we are developers Konferenz, und da habe ich da ein ziemlich blödes Gesicht

00:48:21.240 --> 00:48:26.920
gezogen und habe diese Wojack-Geist gehabt, die nachher hinzeigen, diesen tollen Witz. Und das

00:48:26.920 --> 00:48:33.920
hat die Leute komplett überrascht und die sind gestorben verlochen. Das hat einen wunderschönen

00:48:33.920 --> 00:48:39.400
langen Applaus vorsagt und ich habe mich gar nicht mehr eingekriegt, aber gesagt, okay echt jetzt,

00:48:39.858 --> 00:48:46.240
das kommt so gut an, spitze. Also ich bin ein Boomer-Mimer, ich habe absolut keine Ahnung,

00:48:46.240 --> 00:48:52.047
was dieses Meme überhaupt bedeutet, aber ich habe es lustig gefunden und es ist anscheinend auch gut

00:48:52.160 --> 00:48:52.677
dann auch mal ein komisches Video von mir.

00:48:54.451 --> 00:49:07.621
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.

00:48:54.451 --> 00:49:00.160
Das war's für heute. Ich hoffe, ich konnte euch helfen. Wenn ja, dann abonniert meinen Kanal.

00:49:00.160 --> 00:49:03.984
Wenn euch das Video gefallen hat, dann lasst ein Abo da, dann das Video hier oben unten.

00:49:04.335 --> 00:49:08.160
Und dann abonniert den Kanal. Und dann sehen wir uns beim nächsten Video.

00:49:07.819 --> 00:49:15.165
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.

00:49:15.570 --> 00:49:20.476
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.

00:49:20.836 --> 00:49:28.794
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,

00:49:29.353 --> 00:49:39.261
und der Arne Typ von SAP, der der Chief Innovation Typ ist, der halt ganz große, wichtige Zukunftsthemen behandelt

00:49:39.261 --> 00:49:47.555
und dann kommt halt dazwischen der Pausenclown und macht halt die Strichmännchen auf einer weißen Folie, also spannend minimalistisches Design.

00:49:47.825 --> 00:49:56.661
Es dürfte glaube ich zielpublikumgerecht gewesen sein und ich freue mich sehr darüber.

00:49:56.661 --> 00:49:59.661
Ich bin sehr happy mit dem Ergebnis.

00:49:59.661 --> 00:50:06.661
Sicher von meiner Sprecherkarriere, wenn ich tatsächlich eine haben sollte, war das einer

00:50:06.661 --> 00:50:10.502
von den schönsten Momenten. Irrsinnig nervös.

00:50:10.862 --> 00:50:14.661
Aber ich habe auch das Gefühl gehabt, dass ich irrsinnig stabil war im Vortrag.

00:50:14.661 --> 00:50:16.038
Das passiert mir auch nicht oft.

00:50:17.478 --> 00:50:23.789
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.

00:50:24.581 --> 00:50:26.454
Ja, das kann ich nicht sagen.

00:50:27.048 --> 00:50:31.621
Aber ist zumindest.

00:50:33.854 --> 00:50:41.650
Zumindest weiß ich, was ich da präsentiere, glaube ich. Also das ist das schon. Die Themen habe ich ja relativ oft durchgekaut.

00:50:42.775 --> 00:50:49.704
Mein Englisch war sehr stabil. Das hat mich auch gefreut. Normalerweise harte ich da immer recht herum, aber ich habe

00:50:49.704 --> 00:50:53.641
so eine Entschlackungskur gemacht bei dem Vortrag und habe einfach viele Details weggegeben,

00:50:53.992 --> 00:50:57.704
dass ich mich nur auf die Geschichte fokussiere und dann war mein Englisch auch gut.

00:50:57.809 --> 00:51:01.704
Man hat halt so seine Bewegchen oder Problemchen, wenn man präsentiert.

00:51:01.704 --> 00:51:03.282
Präsentiert und das war dann Gott sei Dank eins mehr.

00:51:04.191 --> 00:51:09.704
Hervorragend. Persönlich war ich sehr, sehr zufrieden und vor allem der Ansturm nachher. Ich glaube, ich habe die drei

00:51:09.704 --> 00:51:13.704
Stunden danach mit 70 Leuten gesprochen. Ich bin nicht mehr aus den

00:51:13.704 --> 00:51:15.597
Räden gekommen. Es war beeindruckend.

00:51:15.704 --> 00:51:19.288
Nicht schlecht. Auch der Menge geschuldet. Es sind ja glaube ich vor Ort,

00:51:19.936 --> 00:51:21.704
12.000 Leute gewesen. Das ist halt

00:51:21.836 --> 00:51:25.527
eine Masse. Mit der musst du halt umgehen können.

00:51:26.130 --> 00:51:29.704
Und ich glaube halt, das Thema ist halt auch wirklich so eins,

00:51:29.704 --> 00:51:33.024
Also, gerade so TypeScript, das ist halt so unhandlich im Sinne von,

00:51:33.024 --> 00:51:35.024
das hat halt so viele Ecken und Enden.

00:51:35.762 --> 00:51:40.984
Da ist halt auch immer sehr viel Nachfragebedarf und ist das wirklich so, mache ich das richtig und so.

00:51:40.984 --> 00:51:43.081
Weil ich hatte ja letztes Jahr TypeScript da als Thema.

00:51:43.252 --> 00:51:46.007
Und wie gesagt, ich hatte halt eine Größenordnung weniger Läutchen da.

00:51:46.619 --> 00:51:51.704
Aber trotzdem, wenn ich das jetzt mal so verrechne, dürfte da der Ansturm hinterher ungefähr gleich viel gewesen sein.

00:51:51.704 --> 00:51:56.206
Mit halt so, mache ich das richtig, ist das wirklich so gedacht oder ...

00:51:56.467 --> 00:52:07.844
Ja, es ist spannend, weil die Sprache wirft doch einiges an Nuancen auf, wo sich manche Entwicklerinnen und Entwickler nicht ganz sicher sind.

00:52:07.844 --> 00:52:15.912
Ich habe schon mittlerweile das Gefühl, dass TypeScript so ähnliches Schicksal wie C++ erleben wird,

00:52:16.488 --> 00:52:21.971
wo sie Teams auf ein Subset einigen müssen, um sinnvoll produktiv gemeinsam zu sein.

00:52:23.465 --> 00:52:29.605
Weil die du ja ausdrucken kannst mit unterschiedlichste Techniken.

00:52:30.334 --> 00:52:35.635
Nimmst du Function Overloads, nimmst du Conditional Types, nimmst du Klassen, nimmst du Interfaces, nimmst du Types,

00:52:36.537 --> 00:52:38.679
nimmst du die objektorientierten Features.

00:52:39.678 --> 00:52:43.815
Also du hast einfach viele Ausdrucksmöglichkeiten. Ich könnte jetzt mittlerweile nicht einmal sagen,

00:52:43.815 --> 00:52:50.112
wie viel die richtige oder einzig wahre ist, weil vor diesen dogmatischen Tipps geht mir sowieso nichts halt.

00:52:50.751 --> 00:53:02.275
Aber zu wissen, dass man eine Auswahlmöglichkeit hat, und zu wissen, welche Implikationen jede Möglichkeit besitzt,

00:53:02.275 --> 00:53:10.412
das gehört, glaube ich, mittlerweile zur täglichen Arbeit einzelner Teams dazu.

00:53:10.673 --> 00:53:13.435
Ja, und ich würde ja sagen, ist ja nicht mal TypeScript spezifisch,

00:53:13.435 --> 00:53:15.525
sondern ist ja mehr so JavaScript an sich.

00:53:15.635 --> 00:53:21.395
Die großen Schismen, so OOP und Funktional und so, Die finden sich ja da auch drin.

00:53:21.548 --> 00:53:25.395
Und dann packst du halt eben noch Klasseninterfaces und was nicht alles on top und dann wird es nicht einfacher.

00:53:25.554 --> 00:53:28.395
Ich habe so ein spannendes Erlebnis gehabt vor kurzem.

00:53:28.669 --> 00:53:37.395
Ich habe ein sehr, sehr altes Programm für mich, ein ganzes Note-Skript, das ich verwendet habe,

00:53:37.395 --> 00:53:45.395
um aus YAML-Files JSON-Files zu generieren, damit ich so eine Statistik machen kann.

00:53:45.395 --> 00:53:51.635
Ich bin über sämtliche Meetups von unserer Meetup-Gruppe drüber gegangen, habe die Hosts

00:53:51.635 --> 00:53:56.595
rausgezogen und ich bin über eure Sprecherinnen und Sprecher drüber gegangen und habe die

00:53:56.595 --> 00:54:00.675
Sprecherinnen und Sprecher rausgezogen und habe dann so eine Statistikliste gemacht,

00:54:00.675 --> 00:54:05.395
die ich wieder in einem statischen Seitengenerator packen kann, der nachher so Highscores oder so

00:54:05.395 --> 00:54:11.635
ewige Bestenliste produziert hat. Und habe das mit einem 100 Zeiler gemacht, also wirklich nur.

00:54:12.105 --> 00:54:14.635
Daten.

00:54:13.581 --> 00:54:21.656
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.

00:54:21.971 --> 00:54:33.494
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.

00:54:34.493 --> 00:54:42.298
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.

00:54:42.694 --> 00:54:48.753
Und alleine die Einschulung vom Typen, einfach nur, dass ich mir Gedanken machen muss, wie mein Modell ausschaut,

00:54:49.347 --> 00:54:53.794
hätte komplett verändert, wie das Programm geschrieben worden wäre.

00:54:54.514 --> 00:54:59.051
Also komplett. Zum Besseren? Auf jeden Fall zum Besseren.

00:54:59.313 --> 00:55:04.551
Nein, also ganz gerade zum Besseren, weil ich habe dann dort noch ein paar Techniken drin gehabt, wo ich halt einfach abgekürzt habe.

00:55:04.795 --> 00:55:08.551
Ich habe auch nicht den Anspruch gehabt, dass das Ding stabil funktioniert,

00:55:08.551 --> 00:55:12.551
weil es war ein kleines Helfer-Skript für mich, damit ich die Liste nicht selbst manuell warten muss.

00:55:12.551 --> 00:55:16.138
Aber jetzt gehe ich halt sechs Jahre später oder sieben Jahre später dran und denke mir,

00:55:16.551 --> 00:55:21.551
ich habe keine Ahnung, was das Ding tut. Ich könnte es dir nicht sagen auf der Basis von den Objekten,

00:55:21.551 --> 00:55:24.551
die ich dort lese. Und ich habe das wieder mühsam erarbeiten müssen.

00:55:24.690 --> 00:55:29.551
Das gefällt mir so gut, weil mittlerweile ist das nämlich eines meiner Beispiele,

00:55:29.551 --> 00:55:33.971
um die Sinnhaftigkeit von TypeScript zu manifestieren, wenn ich Workshops mache.

00:55:34.551 --> 00:55:40.552
Mache ich mit einer Gruppe gerne mein altes Programm durch und ich versuche, dass die Gruppe redet, was ich mit dem Programm gemeint habe.

00:55:41.020 --> 00:55:48.213
Das ist die Idee geworden. Das stellt sich sehr spannend heraus.

00:55:48.483 --> 00:55:51.733
Das mache ich immer ganz gerne, aber mit dem Code von dem Kunden.

00:55:52.525 --> 00:56:00.671
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.

00:56:00.870 --> 00:56:02.995
Wie wäre es, wenn wir über das reden, was ihr nicht wisst? Gibt mal Code.

00:56:03.292 --> 00:56:04.615
Ja, das ist natürlich die beste Art.

00:56:05.151 --> 00:56:08.811
Ja, geht natürlich nicht, weil NDA und man kann dir doch nicht den Zugriff geben,

00:56:08.811 --> 00:56:14.284
bla Keks und dann muss man sich da älter machen. Ihr unterzeichnet ein Alman-NDA und uns geben halt dann ausgewählte Beispiele.

00:56:15.697 --> 00:56:24.147
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.

00:56:24.147 --> 00:56:26.526
Von wegen, oh, unsere Geschäftsgeheimnisse.

00:56:26.599 --> 00:56:35.844
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.

00:56:35.988 --> 00:56:40.489
Du kriegst von mir eine gratis Antwort, aber ich verwende dein Problem anonymisiert für einen Blogpost.

00:56:41.506 --> 00:56:48.227
Das sowieso. funktioniert sehr gut, also da kommt echt viel raus dabei. Das ist der einzige Grund,

00:56:48.227 --> 00:56:52.747
wie meine Serie hier Fragen zu HTML5 beantwortet jemals Inhalt bekommen hat.

00:56:52.747 --> 00:56:59.107
Ich finde, das ist ein guter Deal. Total, weil dann hat man es auch schon fertig formuliert

00:56:59.107 --> 00:57:05.547
und dann geht es ab in die Zweitverwertung. Es ist interessant, dass du diesen Weg gegangen bist,

00:57:05.547 --> 00:57:10.707
von früher mein unordentliches Programm hin zu einem ordentlichen mit TypeScript und so. Ich

00:57:10.707 --> 00:57:12.609
Ich habe mich letztens den umgekehrten Weg beschritten.

00:57:14.184 --> 00:57:20.707
Wieder weg mit den Typen. Weg mit allem. Weg mit dem ganzen smarten Zeug.

00:57:20.707 --> 00:57:22.707
Also ich habe halt meinen Präsentationstool mal wieder neu geschrieben.

00:57:22.707 --> 00:57:26.635
Das muss man ja alle paar Jahre mal machen. Bei welcher Nummer bist du jetzt?

00:57:27.139 --> 00:57:33.980
Pick 10? Pick 11? Ich habe aufgehört zu zählen. Es heißt tatsächlich jetzt einfach nur N. Ja.

00:57:35.673 --> 00:57:38.707
Aber da bin ich halt tatsächlich hingegangen. Ich habe so gesagt,

00:57:38.707 --> 00:57:45.962
Ich versuche, das jetzt einfach mal so reudig wie möglich zu machen und mit so dem Ziel, maximale Stabilität herzustellen.

00:57:46.268 --> 00:57:52.387
Und halt eben einfach so native DOM-Methoden, Blahkeks. Das Einzige, was daran bisschen fancy ist,

00:57:52.387 --> 00:57:54.353
dass ich halt für meine Web-Components Decorators verwende.

00:57:55.298 --> 00:57:57.907
Und dafür halt eben auch Parcel, aber Parcel verwende ich sowieso zum Bundlen,

00:57:57.907 --> 00:58:00.069
dass ich halt irgendwie sagen kann, mach aus meiner Slidesammlung,

00:58:00.996 --> 00:58:03.587
also irgendwie, ich hab, das ist so Produktreihe irgendwie so,

00:58:03.587 --> 00:58:05.992
TypeScript-Workshop, diese Größe, jene Größe, solche Größe.

00:58:06.272 --> 00:58:11.583
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.

00:58:12.285 --> 00:58:14.647
Und da ich sowieso den Bundler habe, kann ich halt eben auch da Decorators reinbauen,

00:58:14.647 --> 00:58:18.647
aber der Rest ist halt wirklich so, also ich hab hier so, wenn ich mal so zitieren darf,

00:58:18.647 --> 00:58:23.583
irgendwie so, eckige Klammern, .indexof, .call, document, query, selector, all.

00:58:24.591 --> 00:58:27.647
So Zeug ist da halt eben drin, weil, es ist halt eine Zeile,

00:58:27.647 --> 00:58:32.647
und die Zeile wird bis in alle Ewigkeit funktionieren, und ich hab keine Bock, das Ding noch mal neu zu schreiben,

00:58:32.647 --> 00:58:33.989
jetzt gefälligst bis zur Rente zu halten.

00:58:35.682 --> 00:58:40.592
Und deswegen hab ich alles rausgeschmissen. Also kein RxJS mehr da drin, kein jQuery mehr da drin,

00:58:40.652 --> 00:58:43.132
was da alles in den vorherigen Dingern drin war.

00:58:43.192 --> 00:58:46.952
Einfach nur Funktionen, paar globale Variablen, die Wahrheit lebt im DOM.

00:58:47.012 --> 00:58:49.897
Also nicht irgendwie so aus dem State die Daten oder so was,

00:58:50.232 --> 00:58:54.263
sondern das sind einfach irgendwie so 100 Prozent OOP und ein bisschen Glue-Code on top.

00:58:55.037 --> 00:59:00.420
Herrlich. Also ich hätte gern wieder so ein Projekt, wo man einfach mit Basismitteln komplett frameworkfrei,

00:59:01.051 --> 00:59:01.689
was Tolles schaffen kann.

00:59:02.012 --> 00:59:06.929
Ich schreibe halt nur viel zu wenig JavaScript im Moment.

00:59:08.108 --> 00:59:11.012
Ja, ich weiß nicht, ob du das unbedingt haben willst. Schön ist es halt nicht.

00:59:11.012 --> 00:59:14.012
Es muss nicht schön sein, es muss nicht zufriedenstellend sein.

00:59:14.012 --> 00:59:23.012
Mein Anspruch ist sehr minimalistisch. Du wirst ja dann gern die neuen Werkzeuge und Tools von JavaScript verwenden.

00:59:23.012 --> 00:59:26.012
Das hat natürlich auch einen Sinn.

00:59:26.545 --> 00:59:35.772
Ich habe mich mit Klassen nun nie so auseinandergesetzt, dass ich sage, okay, ich setze jetzt mein eigenes Programm nur auf Komponenten- und Klassenbasis

00:59:35.772 --> 00:59:41.372
auf, ohne dass ich irgendein Framework verwende oder so. Das würde ich gerne mal machen.

00:59:41.372 --> 00:59:47.812
Es ist schwierig, weil ich glaube, um, sagen wir mal so, ich habe das jetzt so formuliert,

00:59:48.627 --> 00:59:52.252
aus einer bestimmten Risikoüberlegung heraus. Nämlich die Risikoüberlegung ist irgendwie,

00:59:52.252 --> 00:59:56.333
die ganze Software geht über einen Dicer und ich kann irgendwann das tatsächlich nicht mehr

00:59:56.772 --> 00:59:59.112
weil irgendwie die Dependencies nicht da sind.

00:59:59.172 --> 01:00:02.612
Ich hab auch kein Node-Modules außerhalb eben für das Build-System.

01:00:03.499 --> 01:00:04.772
Sondern alles ist da schön in Vendor drin.

01:00:05.156 --> 01:00:08.874
Ganz klar. Aber das ist sozusagen das Szenario, wogegen ich mich verteidige.

01:00:09.396 --> 01:00:12.240
Und das kann ich halt eben machen, weil das andere Risikogebiet,

01:00:12.664 --> 01:00:15.032
nämlich dass ich irgendwie das Scope-Creep habe,

01:00:15.391 --> 01:00:22.012
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,

01:00:22.242 --> 01:00:32.412
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

01:00:32.412 --> 01:00:37.372
ich nicht schlecht, dass du sowas hast. Ja, das stimmt. Andererseits brauchst du dann

01:00:37.372 --> 01:00:40.492
wieder gute Architektur und die kennst du mittlerweile eher. Also du weißt ja mittlerweile,

01:00:40.492 --> 01:00:41.471
der SlideTool funktioniert.

01:00:42.492 --> 01:00:46.492
Ja, äh, pfff, ja. Wie das? Weiß ich nicht.

01:00:48.331 --> 01:00:50.880
Ich hab ja mal tatsächlich mir angeschaut, wie so andere funktionieren hier.

01:00:50.880 --> 01:00:53.291
Wie heißt denn das? Ja, Reveal zum Beispiel.

01:00:53.750 --> 01:00:55.780
Das hatte ich mir ja angeschaut, als ich da ein Plugin für geschrieben habe,

01:00:55.780 --> 01:00:56.964
für dieses Code-Animations-Ding.

01:00:57.693 --> 01:01:02.880
Das ist definitiv sehr viel komplexer und sehr viel smarter.

01:01:02.880 --> 01:01:04.742
Also meine main.js hat 218 Zeilen.

01:01:05.120 --> 01:01:07.667
Wunderbar. Ja, aber bitte, das sind ja nicht die tollen Dinge.

01:01:08.082 --> 01:01:12.106
Aber es sind dann noch so ein paar Klassen für die Web-Components und Zeug, aber trotzdem.

01:01:12.898 --> 01:01:17.480
Na, herrlich. Ja. Einfacher Code, simpler Code, dependencyfrei.

01:01:17.552 --> 01:01:19.379
Wunderschön. Nicht die unbedingt haben.

01:01:19.532 --> 01:01:22.629
Ja, das ist nicht dependencyfrei. Die sind halt nur jetzt in einem Folder.

01:01:23.998 --> 01:01:31.760
Okay, gut, fair enough. Ja, aber immerhin bin ich NPM-frei, was alles außer das Bildsystem angeht.

01:01:31.760 --> 01:01:36.502
NPM ist ja Technical Dead mit der ersten Zeile. Das ist leider so.

01:01:37.357 --> 01:01:40.499
Also, mir graust richtig davor, wenn ich ein Node-Modul sehe.

01:01:40.760 --> 01:01:44.760
Aber ich bin ja auch in einem komischen Platz gerade im Moment.

01:01:44.760 --> 01:01:53.760
Das Problem ist halt, dass npm immer nur Probleme löst, aber halt auch Probleme macht und das ist halt sehr schwierig.

01:01:55.397 --> 01:02:02.760
Ja, was glaube ich so wirklich fehlt, ist so irgendwie das Bewertungskriterium.

01:02:03.076 --> 01:02:06.760
So recht. Also du findest ja manchmal, wenn du irgendwie verzweifelt nach einem npm-Modul findest,

01:02:06.760 --> 01:02:13.519
findest du ja diese ganzen Bewertungsseiten, die irgendwie da versuchen diese Packages zu scoren anhand von Aktivität und Zeug.

01:02:14.914 --> 01:02:17.800
Ich weiß ja nicht, was das richtige Kriterium ist, um zu entscheiden, ob jetzt irgendwas ein gutes

01:02:17.885 --> 01:02:23.611
Package ist oder nicht, aber was die machen, ist es definitiv nicht. Ja, es ist eine gute Frage. Ich,

01:02:24.480 --> 01:02:31.280
könnte es da nicht beantworten. Es hat über den Zeitraum, wo ich es brauche, am wenigsten Probleme

01:02:31.280 --> 01:02:34.720
gemacht. Das ist, glaube ich, das einzige Kriterium, das ich wirklich nennen kann. Aber da fällt mir

01:02:34.720 --> 01:02:41.720
auch nicht mehr recht viel ein, was ich da reingeben würde. Was heißt Problem? Also Problem

01:02:41.720 --> 01:02:48.680
ist jetzt ja auch sehr allgemein. Naja, das Ding ist, beschäftigst du länger mit der Wartung und

01:02:48.680 --> 01:02:58.000
der Instandhaltung vom Framework, also wie dass du das Framework tatsächlich nutzt, dann wird

01:02:58.000 --> 01:03:03.320
das schon ein Problem sein. Also wir haben teilweise das Problem gehabt, bei Leuten,

01:03:03.320 --> 01:03:08.200
die ich kenne, die haben halt Angular verwendet, als Beispiel jetzt nur Angular, ist beispielhaft

01:03:08.200 --> 01:03:12.480
coole anderen Sachen und haben halt das Problem, dass wirklich quartalsweise, wenn die nächste

01:03:12.480 --> 01:03:19.110
Version kommt, die gesamte Firma einmal einen Tag Pause hat, damit das Kern-UI-Team die,

01:03:19.600 --> 01:03:21.252
Möglichkeit hat, die Dependencies zu aktualisieren.

01:03:22.062 --> 01:03:24.997
Und da würde ich schon sagen, wenn das...

01:03:25.906 --> 01:03:31.756
Wenn das mein Anspruch ist, dass alle 100 UI-Entwicklerinnen und Entwickler einen Tag Pause machen,

01:03:31.756 --> 01:03:36.412
vier Tage im Jahr mindestens Pause haben, dass sie aktiv an Features arbeiten.

01:03:37.276 --> 01:03:40.756
Dann ist das nicht das richtige Framework, so stabil es auch sein kann.

01:03:40.756 --> 01:03:45.261
Das andere, was ich habe, ist Next.js. Das hat gut angefangen.

01:03:45.819 --> 01:03:49.756
Und das Problem, was du jetzt hast, ist, dass die so viele Versell-Plattform-Features reinbauen,

01:03:49.756 --> 01:03:53.756
dass das einfach nicht mehr wirklich nutzbar ist für andere Dinge.

01:03:53.756 --> 01:04:01.465
Bzw. du dir versteckte technische Schuld einkaufst, die dir nicht einmal bewusst ist.

01:04:01.756 --> 01:04:05.756
Ja, sie haben im Prinzip einen Garten gepflanzt und jetzt fangen sie langsam an, die Mauer hochzuziehen.

01:04:05.756 --> 01:04:07.343
Ja, genau, genau, genau.

01:04:07.756 --> 01:04:13.756
Also Park geschaffen, jeder darf rein, den Zahn runterholen und bitte ein Ticket kaufen. Ja.

01:04:14.329 --> 01:04:19.659
Das ist so die Idee. Aber gut, das ist halt ja sozusagen, das hätte man vorhersehen können, glaube ich. Ja, sicher.

01:04:19.929 --> 01:04:24.076
Also, da weiß ich jetzt nicht, ob das jetzt in die gleiche Kategorie wie so ein Angular rein muss.

01:04:24.076 --> 01:04:28.256
Angular hat ja wenigstens den Anspruch, das nicht zu sein, und ist es dann vielleicht trotzdem.

01:04:29.021 --> 01:04:34.876
Ja, also das Problem ist halt, man verbringt irrsinnig viel Zeit mit der Wartung, mit der Instandhaltung von dem Programm,

01:04:34.876 --> 01:04:37.429
wenn man das Framework hat, oder irgendwelche Bibliotheken.

01:04:37.762 --> 01:04:41.916
Es gibt ja genauso gut Notbibliotheken, die ständig Pflege brauchen, und ich weiß nicht.

01:04:41.916 --> 01:04:46.716
Also, ich habe generell das Problem, da werde ich jetzt aber schon sehr, sehr philosophisch,

01:04:47.043 --> 01:04:54.116
dass Dinge ja scheinen, wie wenn sie nie fertig werden würden und gerade mit Frameworks,

01:04:54.116 --> 01:05:00.476
die jetzt zum Beispiel unterstützt sind von Venture-Capitalists und von Startups.

01:05:01.321 --> 01:05:06.156
Die werden auch nie abgeschlossen. Das Thema ist, dass dieses Framework weiterlebt und dass dort

01:05:06.156 --> 01:05:10.956
Features reinkommen. Das ist die Arbeit und der Job dieser Leute, dass dort Dinge erschaffen werden.

01:05:11.890 --> 01:05:17.036
Und solange das deren Beruf ist, werden auch Dinge erschaffen, ob sie sinnvoll sind oder nicht.

01:05:18.596 --> 01:05:21.947
Die Frage stört mir nicht, sondern es muss halt ein Roadmap geben.

01:05:21.987 --> 01:05:23.656
Es ist nie ausentwickelt, meinst du?

01:05:23.947 --> 01:05:27.067
Genau, und auf der Roadmap steht nie, wir sind jetzt fertig.

01:05:27.107 --> 01:05:31.623
Das Einzige, was wirklich einen finalen Stand feature-technisch bekommen hat, war die Query.

01:05:33.288 --> 01:05:36.907
Ich ... also, ich ... Ich glaub, es gibt noch Sicherheitsupdates.

01:05:37.402 --> 01:05:41.084
Aber tatsächlich, ob da jetzt Features implementiert werden,

01:05:42.191 --> 01:05:42.498
glaub ich nicht. Ich glaub, das ist ...

01:05:44.027 --> 01:05:49.087
Was man ja problemlos rechtfertigen könnte. und neue Versionen rechtfertigen mit irgendwie, sagen wir mal,

01:05:49.492 --> 01:05:53.647
etwas gestreamlainteren APIs, die so gleichsam dein YAML-Beispiel von früher, ne?

01:05:53.707 --> 01:05:58.783
Also, da sind halt so viele Patterns drin in jQuery, nach dem Motto, die Signatur dieser Methode ist halt,

01:05:59.167 --> 01:06:02.915
steck irgendwas rein, und unter der Haube machen wir ganz viel Ducktyping,

01:06:03.047 --> 01:06:04.967
um rauszufinden, was du gemeint hast.

01:06:05.027 --> 01:06:09.447
Das ist ja heutzutage nicht mehr so en vogue, und man könnte problemlos rechtfertigen,

01:06:09.507 --> 01:06:14.007
ein Update zu machen, irgendwie Version 4.0 oder so, wo man das halt eben mal aufräumt.

01:06:14.007 --> 01:06:22.767
Vom Feinschleifen und von nuancierten Verbesserungen, aber an dem Grobkonzept wird sich ja nix ändern.

01:06:23.719 --> 01:06:27.698
Und ich glaube, diese Feinverbesserung will auch keiner haben von denen, die das noch nutzen.

01:06:29.111 --> 01:06:32.407
Da liegt der Wert mehr so darin, dass man halt eben was hat, worauf man sich verlassen kann,

01:06:32.407 --> 01:06:34.087
was halt gleichsam Infrastruktur ist.

01:06:34.087 --> 01:06:38.113
Absolut und das Schöne ist ja, ich habe vor kurzem so ein Twitter-Wall gebaut,

01:06:39.248 --> 01:06:44.767
ist schon länger her jetzt, als es noch Konferenzen gegeben hat, also vor Corona. Und da haben wir das

01:06:44.767 --> 01:06:51.194
Problem gehabt, dass wir die Sprecher und Sprecherinnen in so einem Karussell durchfahren,

01:06:51.647 --> 01:06:55.607
lassen wollten, automatisch. Das heißt, du hast Twitter-Wand auf der einen Seite gehabt und die

01:06:55.607 --> 01:07:03.447
Sprecher-Bild links oben und die Sponsoren-Bild links unten. Und Sponsoren und Sprecherinnen

01:07:03.447 --> 01:07:07.695
sind über unterschiedliche Timings durchgeschaltet worden.

01:07:09.477 --> 01:07:16.128
Unsere Digitalistik gemacht, Flexbox im CSS und eine Jiquiri Plugin draufgeschnalzt,

01:07:16.128 --> 01:07:21.128
die sich konfiguriert hat nach dem Timing. Fertig, erledigt, 30 Minuten, 30 Minuten

01:07:21.128 --> 01:07:26.448
Aufwand und ich habe die perfekte Twitter-Wall gehabt für unser Problem. Jetzt habe ich es nur

01:07:26.448 --> 01:07:29.768
erweitert und habe ein CMS dran gehängt und ein paar Konfigurationsmöglichkeiten und solche Sachen,

01:07:29.768 --> 01:07:40.488
Aber mir erschließt sich da der ganze Trend nach diesen Frameworks, die unbedingt konstant neue

01:07:40.488 --> 01:07:46.448
Features brauchen, nicht, wenn es mir nicht hilft, dass ich genau bei diesen rudimentären Tasks

01:07:46.448 --> 01:07:50.648
einfach schneller werde. Warum kann ich das nicht auch in Next.js einfach aktivieren? Warum ist das

01:07:50.648 --> 01:07:54.768
nicht einfach da, als irgendwelche Komponente, die funktioniert und nicht ewig und Stunden

01:07:54.768 --> 01:07:58.048
braucht, dass ich das habe, wo ich auch noch Entscheidungen treffen muss. Renne ich das jetzt

01:07:58.048 --> 01:08:01.528
am Server oder am Client oder was auch immer. Also ich finde, da ist das Framework ein bisschen,

01:08:02.285 --> 01:08:07.688
innoviert an der falschen Stelle. Mein Wunsch war eigentlich gewesen, dass ich, genauso wie es die

01:08:07.688 --> 01:08:12.488
Web-Components versprechen, dass ich in React einfach irgendwelche React-Komponenten kombinieren

01:08:12.488 --> 01:08:17.728
kann und das Ding flutscht und ich brauche nichts mehr machen. Aber ich sehe das nicht. Also ich sehe

01:08:17.728 --> 01:08:22.688
in React, Angular oder wie sie auch heißen mögen, sehe ich einfach nur mehr Entwicklungsaufwand.

01:08:25.042 --> 01:08:51.688
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,

01:08:51.688 --> 01:08:53.661
das passt auf genau, was ich brauche,

01:08:53.728 --> 01:08:55.688
sondern das rekrutiert sich aus dem,

01:08:56.010 --> 01:09:00.068
das kann ich mit ein bisschen Gewalt dazu bringen, dass es auch für mich funktioniert,

01:09:00.108 --> 01:09:04.648
aber dann kommt direkt danach der Bug-Report, kannst du das nicht irgendwie rundermachen?

01:09:04.895 --> 01:09:07.614
Und damit hast du ja so quasi automatischen Scope-Creep mit drin.

01:09:08.148 --> 01:09:10.945
Und das braucht wahrscheinlich irgendwie ganz gewaltige ...

01:09:11.962 --> 01:09:16.988
Ja. Disziplin hauptsächlich. Ja. Ich mein, es ist ja jetzt auch nicht falsch,

01:09:17.028 --> 01:09:18.489
irgendwie die Software zu verbessern oder so.

01:09:19.452 --> 01:09:25.308
Deswegen keine Ahnung, was es da braucht. Bringt mich zu einer sehr guten Überleitung. Pass auf, Peter.

01:09:25.308 --> 01:09:27.308
Dinge, von denen wir nicht wissen, ob wir sie unbedingt benötigen.

01:09:27.308 --> 01:09:35.305
Es gibt jetzt ein neues JavaScript-Feature, das jetzt in TypeScript 5.2 auch zur Verfügung steht.

01:09:36.035 --> 01:09:41.308
Soll ich irgendwie zwischendurch mal die Sendungsnummer ansagen?

01:09:42.048 --> 01:09:47.308
Bitte sehr gern. Das ist wie immer so das Sahnehäubchen des Quartals, wenn man aus unserem

01:09:47.308 --> 01:09:49.537
hier irgendwie eine kohärente Sendung zusammenschnipseln muss.

01:09:51.185 --> 01:09:55.708
Okay, ich tue einfach mal so, als hätte es das ganze Vorgespräch nicht gegeben.