WEBVTT

00:00:00.017 --> 00:00:05.329
Also da gibt es auf YouTube eine Sache, die mir richtig gut gefällt bei den Signals und das ist das Automatic Dependency Tracking.

00:00:05.941 --> 00:00:10.379
Statt dem Dependency Array wissen die selber, wo die Änderungen herkommen.

00:00:10.829 --> 00:00:13.251
Und das finde ich schon einen schönen Selling Point von Signals.

00:00:14.517 --> 00:00:23.517
Und wenn extrem kompetente Leute mit einem extrem stabilen Produkt, sagen wir mal, kreativ umgehen, kriege ich jetzt nicht unbedingt da Angstzustände?

00:00:24.756 --> 00:00:26.517
Das wird eigentlich in JavaScript generell gehen, genau.

00:00:26.517 --> 00:00:30.247
Genau, das ist natürlich, wenn du sowas machst wie React, ist natürlich alles wieder ein bisschen anders.

00:00:30.346 --> 00:00:34.154
Weißt du, das kann doch bissl weh.

00:00:34.160 --> 00:00:59.440
Music.

00:00:59.797 --> 00:01:01.638
Working Draft Revision 572,

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

00:01:08.677 --> 00:01:12.900
euch. Auf patreon.com slash working draft könnt ihr uns ein paar Euro in den Hut werfen.

00:01:13.647 --> 00:01:17.157
Aus euren Beiträgen und unseren gelegentlichen Werbeeinnahmen bezahlen wir allerleite eure

00:01:17.157 --> 00:01:19.769
Software-Abos und das Honorar unserer Audio-Producerin.

00:01:20.408 --> 00:01:24.918
Wenn ihr euch auch beteiligen wollt, könnt ihr das unter patreon.com slash working draft sehr gerne machen.

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

00:01:32.561 --> 00:01:35.342
Hallo und herzlich willkommen zu Working Draft Revision 572.

00:01:35.712 --> 00:01:37.098
Heute sind am Start der Stefan.

00:01:37.719 --> 00:01:42.557
Servus. Meine Wenigkeit, der Peter. Und wir haben einen Gast aus dem fernen Portugal zugeschaltet.

00:01:42.557 --> 00:01:44.138
Ist Bernhard. Hallo.

00:01:45.416 --> 00:01:48.066
Bernhard, ich weiß nicht, hatten wir dich schon mal im Podcast?

00:01:48.066 --> 00:01:52.006
Und wenn ja, wie viele Jahre ist es her? Was ich sagen will, stelle ich doch mal vor.

00:01:52.888 --> 00:01:59.866
Ja, danke. Ja, genau, ich bin der Bernhard und ich bin ehemaliger Student von Stefan.

00:01:59.866 --> 00:02:01.575
Das ist schon einige Jahre aus.

00:02:02.043 --> 00:02:07.346
Und wir sind aber seitdem in Kontakt geblieben über Konferenzen, Meetups und so weiter.

00:02:07.850 --> 00:02:14.866
Und ich studiere selbst Mobile Computing und Psychologie. Bin da aber schon recht fertig geworden

00:02:14.866 --> 00:02:20.546
und bin trotzdem der Technikbranche immer noch, teilweise immer noch treu.

00:02:21.236 --> 00:02:24.826
Und der Stefan hat letztens etwas sehr Schönes über mich gesagt,

00:02:24.826 --> 00:02:29.506
dass ich es liebe, konstant so Assumptions zu challengen.

00:02:30.040 --> 00:02:36.531
Und ich glaube, das würde ich in Kombination mit meinen beiden Studien sehe das mittlerweile, glaube ich, oft als Aufgabe.

00:02:40.114 --> 00:02:49.766
Okay, das mit den Assumptions-Challengen finde ich ja gerade im Kontext des heutigen Themas. Eine ziemlich gute Idee. Ich will ja mal meine Karten auf den Tisch legen.

00:02:49.766 --> 00:02:54.446
Ich stehe da so ein bisschen vor, so ungefähr wie vor Cryptocurrency und AI, dass ich so denke, ja,

00:02:54.446 --> 00:03:01.186
okay, aber wirklich so krass? Ich weiß es halt nicht. Aber alle Welt redet darüber und deswegen

00:03:01.186 --> 00:03:07.246
müssen wir halt eben auch mal drüber reden. Und zwar geht es um das breitere Konzept von Signals,

00:03:07.859 --> 00:03:12.966
was ja so in meiner User Experience irgendwie sowas ist, wie plötzlich kräht alles, was irgendwie

00:03:12.966 --> 00:03:17.006
React macht darüber rum und dann baut man das ein und das funktioniert und dann hat sich exakt

00:03:17.006 --> 00:03:21.486
nichts am Leben geändert und man macht so weiter wie zuvor. So sehen Signals für mich aus.

00:03:22.343 --> 00:03:28.766
Aber es ist natürlich noch alles besser, weil wenn man nicht konstant neue Dinge

00:03:28.766 --> 00:03:35.166
einführen würde, dann würde generell nichts besser werden. Aber ja, Signals ist das Thema,

00:03:35.166 --> 00:03:40.246
was ich spannend gefunden habe bei dem Thema ist, dass es genauso bei mir aufgeschlagen ist in der

00:03:40.246 --> 00:03:45.426
React-Bubble nicht, aber das anscheinend überall jetzt so...

00:03:44.453 --> 00:03:51.303
Das große Ding ist und der Trend, auf den alle aufspringen. Also am spannendsten eigentlich gesehen bei der NG Belgium,

00:03:51.303 --> 00:03:54.303
also ich war in Belgien auf einer Angular-Konferenz eingeladen,

00:03:54.303 --> 00:03:58.226
habe dort meinen üblichen Typescript-Radanz gemacht

00:03:58.303 --> 00:04:05.303
und drei von diesen zwölf Vorträgen waren rund um Signals, also von einer Alternativimplementierung zur Implementierung,

00:04:05.303 --> 00:04:11.226
die ins Framework kommt, zu einem über generelle Konzepte, also das schlagt auch dort ganz, ganz gewaltig auf.

00:04:11.973 --> 00:04:16.978
Und dann siehst du, dass das ja auch in Wirklichkeit das System des Futures hat, dieses Reaktiv.

00:04:18.383 --> 00:04:22.902
Diese Reaktiv-Funktion, keine Ahnung, wie sie es dort nennen, ja eigentlich auch sowas ähnliches ist.

00:04:23.604 --> 00:04:30.943
Und dann ist einer vom Podcast bekannt, der Entwickler, der Marvin Hagemeister, den wir

00:04:30.943 --> 00:04:34.863
auch sehr gut kennen, der auch bei uns recht oft zu Gast war, hat dann auch Signals für

00:04:34.863 --> 00:04:35.863
Pre-Act implementiert.

00:04:35.863 --> 00:04:39.103
Das heißt, das Ding ist überall, es ist einfach überall da, jeder will Signals haben

00:04:39.103 --> 00:04:44.463
und Signals, Signals, Signals, und ich habe einfach keine Ahnung, was jetzt dieses besondere

00:04:44.463 --> 00:04:48.828
Ding an Signals ist, warum jetzt jeder und jede darauf aufspringen will.

00:04:51.061 --> 00:04:58.023
Tja, Bernhard, hast du eine Idee? Ja, ich habe da einen Punkt da richtig interessant gefunden, also vor allem, dass man das erste

00:04:58.023 --> 00:05:02.583
Mal sich für mich so anfühlt, als ob wir jetzt etwas hätten, was über alle Frameworks,

00:05:02.583 --> 00:05:07.023
Libraries, wie auch immer man sie nennt, dass sich die Leute einig sind, dass jeder das

00:05:07.023 --> 00:05:10.383
haben möchte oder ausprobieren möchte und das kenne ich so nur gar nicht so wirklich.

00:05:10.956 --> 00:05:15.543
Das interessante beim reinlesen ist aber dann, dass glaube ich, das Wort mit sehr

00:05:15.543 --> 00:05:20.343
vielen vergangenen Konzepten konnotiert ist und wenn man es sich dann genauer

00:05:20.343 --> 00:05:24.023
anschaut, ist zwar einiges ähnlich, es ist aber trotzdem wieder irgendwie jede

00:05:24.023 --> 00:05:29.263
Implementierung nur sehr unterschiedlich und da bin ich sehr gespannt, wie das dann,

00:05:29.263 --> 00:05:33.543
dieses Promise, das ich gelesen habe, kann sein, dass es sogar auf Twitter war,

00:05:33.957 --> 00:05:36.663
dass wir jetzt endlich was haben, was über alle Frameworks ähnlich funktioniert oder

00:05:36.663 --> 00:05:41.203
gleich funktioniert, ob das dann sie zu einem Gleich oder zu einem Ähnlich entwickelt und man

00:05:41.583 --> 00:05:46.023
dann erst wieder sehr, sehr, sehr aufpassen muss, mit welcher Signalimplementierung man arbeitet.

00:05:46.830 --> 00:05:52.103
Oder ob dann genau diese kleinen Unterschiede es wieder unmöglich machen, dass man mit

00:05:52.103 --> 00:05:56.858
unterschiedlichen Projekten kontributiert und nicht mehr zerstört, wie man richtig mag.

00:05:57.354 --> 00:06:01.943
Erinnert mich so ein bisschen an Hooks, wie sie da in React eingeführt wurden und dann

00:06:01.943 --> 00:06:08.903
hinterher sofort alle gesagt haben, okay, das Konzept lässt sich generalisieren auf ganz normale Funktionen und dann sieht so die,

00:06:09.543 --> 00:06:13.023
Benutzeroberfläche, die API genau gleich aus, aber die Implementierung sind so

00:06:13.023 --> 00:06:16.223
dermaßen unterschiedlich, dass man linke Hand und rechte Hand auf keinen Fall

00:06:16.223 --> 00:06:19.343
vertauschen darf oder irgendwas, was für A gebaut ist, auf keinen Fall für B

00:06:19.343 --> 00:06:21.705
verwenden kann, weil dann alles den Bach runtergeht.

00:06:22.488 --> 00:06:26.863
Ziemlich genauso. Was ja irgendwie auch Sinn macht. Also ich meine, klar, du kannst irgendwie das zu einem

00:06:26.863 --> 00:06:31.383
Konzept hin vereinheitlichen wie Hooks, aber letztlich hat man ja so was wie

00:06:31.383 --> 00:06:38.463
Frameworks, um irgendwie eine Top-Down-Kontrolle darüber zu haben, wie Dinge funktionieren und das Konzept dann diesbezüglich anzupassen, ist ja erstmal

00:06:38.463 --> 00:06:43.783
nicht verkehrt, nur das würde ja halt eben dann...

00:06:42.914 --> 00:06:47.164
Dann noch irgendwie zu sagen, das ist tatsächlich irgendwie ein guter Aspekt von etwas,

00:06:47.164 --> 00:06:50.444
nämlich dass es überall einheitlich ist und wo es dann halt eben nicht einheitlich ist,

00:06:50.444 --> 00:06:53.168
sondern auf so eine hinterhältige Weise dann doch unterschiedlich,

00:06:53.501 --> 00:06:56.764
wo man es halt gegebenenfalls nicht mitbekommt und sich in Schwierigkeiten baut,

00:06:56.849 --> 00:06:59.847
wäre ja dann jetzt vielleicht auch eher ein Nachteil als ein Vorteil.

00:07:00.423 --> 00:07:07.022
Du hast da gerade was sehr interessantes angesprochen, dass Frameworks irgendwie top-down sagen sollen, wie Sachen funktionieren.

00:07:07.436 --> 00:07:11.298
Und für mich sind gerade Signals da wieder mal komplett orthogonal dazu,

00:07:11.451 --> 00:07:16.744
Weil es ist ein Konzept, wo es um reactive data management geht.

00:07:17.159 --> 00:07:20.684
Und außer dem Namen habe ich bis jetzt nicht groß das Gefühl,

00:07:20.684 --> 00:07:25.027
dass da irgendwas am Top-Down vorgibt, wie was zu funktionieren hat.

00:07:25.621 --> 00:07:30.014
Sondern einfach nur, wie man weiterpropagieren kann, dass sich gewisse Daten geändert haben.

00:07:31.130 --> 00:07:33.804
Das sollten wir vielleicht auch noch mal sagen für diejenigen,

00:07:33.804 --> 00:07:36.964
die jetzt im Vortrag dieser Aufnahme bis jetzt immer noch nicht gesagt haben,

00:07:36.964 --> 00:07:38.917
was zum Henker geht denn hier ab.

00:07:39.538 --> 00:07:44.164
Also es geht schon darum, Der primäre Fokus ist halt schon irgendwie so Datenhaltung in der,

00:07:44.733 --> 00:07:49.764
klassischen Single-Page-App-artigen Konstruktion mit so Sachen wie React,

00:07:49.764 --> 00:07:53.884
Angular oder Vue, wo man Objekte hat, denen man sagen kann, hey, die Welt sieht

00:07:53.884 --> 00:07:57.924
jetzt so aus und dann kriegen alle damit zusammenhängenden, mit der Datenquelle

00:07:57.924 --> 00:08:04.439
zusammenhängenden Teile einer Applikation mit, dass sich die Daten geändert haben und versetzen sich in den dazu passenden Zustand.

00:08:05.663 --> 00:08:09.884
Grob wie es im Prinzip seit Alters her funktioniert, mit so Sachen wie Redux

00:08:09.884 --> 00:08:17.897
und, ja, useState, ja auch zu gewissem Grad, nur halt eben heißt es hateSignal und funktioniert subtil anders.

00:08:20.219 --> 00:08:25.828
Also das Erste, an das mich Signals erinnert haben, waren diese auch oft und lange diskutierten Observables,

00:08:26.107 --> 00:08:30.851
wo es halt einfach hauptsächlich darum geht, du hast irgendwo ein Event,

00:08:31.607 --> 00:08:35.559
das schießt halt einen neuen Wert raus und du kannst es an einer anderen Stelle konsumieren.

00:08:35.766 --> 00:08:41.884
Und dieses Konzept jetzt angeglichen auf diese, ich weiß nicht, ob GSX der Haupttreiber war,

00:08:41.884 --> 00:08:46.695
aber zumindest auf diese Template-basierten, aha, GSX ist ja gar nicht Template-basiert,

00:08:46.924 --> 00:08:51.324
aber auf diese, naja, Komponenten-basierten Frameworks.

00:08:51.324 --> 00:08:59.044
Ich glaube, dass das eher so der Gedanke ist. Das heißt, dass du die Konsumation von diesem Wert mit deinem Markup direkt verbinden kannst.

00:08:59.044 --> 00:09:00.586
Also das war meine...

00:09:01.693 --> 00:09:06.230
Neue Sicht dieser Dinge gewesen. Wobei ich glaube, dass das eigentlich auch mit Observables gehen hätte müssen.

00:09:06.851 --> 00:09:09.327
Und Observables sind in Wirklichkeit nichts anderes als wir Eventimiter.

00:09:10.335 --> 00:09:18.509
Ja, naja, würde ich nicht unbedingt sagen, weil es sind ja also wenn ich jetzt an Observables denke, denke ich ja an meine wilde Vergangenheit mit RXJS

00:09:18.590 --> 00:09:22.543
und das sind ja tatsächlich keine Eventimiter, sondern ja tatsächlich lazy Datenquellen,

00:09:22.695 --> 00:09:26.543
wo ja gar nicht erst irgendwas zustande kommt, sofern man nicht subscribt.

00:09:26.543 --> 00:09:30.356
Okay, ja, gut, das ist ein wichtiger Unterschied zum Eventimiter, ja.

00:09:31.004 --> 00:09:36.343
Genau, also der Eventimeter ist ja dann sozusagen die, ich hau halt eben einfach alles raus, das ist halt so wie der angeklickte Button,

00:09:36.343 --> 00:09:38.843
das Observable ist halt mehr so das zielgerichtete, ich hau was raus,

00:09:38.843 --> 00:09:40.295
sobald ich weiß, dass mir jemand zuhört.

00:09:42.869 --> 00:09:44.843
Punkt. Und ich glaube, der Punkt ist halt wirklich der, den du gerade ansprachst,

00:09:44.843 --> 00:09:49.828
nämlich die Integration mit diesen Sprachen, wie halt eben dem React-Dialect, der JSX,

00:09:50.170 --> 00:09:53.843
dass man so die Einheit aus der Logik und dem Template herstellen kann,

00:09:53.843 --> 00:09:56.229
dass man nicht irgendwie eine extra Template-Sprache schreibt,

00:09:56.343 --> 00:09:58.101
wo man dann irgendwelche Variablen rein interpoliert

00:09:58.343 --> 00:10:03.643
und man in einer Extraschicht die Übertragung von der Datenquelle in das Template machen muss, sondern dass man einfach eine Funktion hat,

00:10:03.643 --> 00:10:07.508
sie alle zu knechten, da drin gibt's die Datenquelle, sei sie Signal, Observable oder sonst irgendwas,

00:10:08.220 --> 00:10:11.551
und man kann das direkt in sein Template, in sein JSX hineinsplicen.

00:10:12.415 --> 00:10:14.643
Und mit Observables wäre halt natürlich das Problem diesbezüglich,

00:10:14.643 --> 00:10:19.843
dass man ja irgendwie so der Template-Funktion, der React-Komponente oder Ähnlichem, mitteilen muss,

00:10:19.843 --> 00:10:23.839
dass wenn neue Daten dort, dann bedeutet das ein Re-Rendering dieser Komponente,

00:10:24.190 --> 00:10:26.443
und das ist ja das, was so ein Signal,

00:10:27.160 --> 00:10:28.443
in der gelebten Praxis automatisch macht.

00:10:28.443 --> 00:10:32.443
Ich subscribe darauf und das bedeutet, wenn neue Daten aufschlagen, gibt es ein Update

00:10:32.443 --> 00:10:36.443
und das würde jetzt ein Observable nicht ohne weiteres tun. Da müsstest du halt ein bisschen extra

00:10:36.443 --> 00:10:38.035
Hexerei betreiben, damit das...

00:10:38.443 --> 00:10:42.443
Genau, entweder setState oder oder mit einem

00:10:42.443 --> 00:10:46.443
mit einem Getter-Setter Proxy-Objekt Werte setzen und solche Sachen.

00:10:46.443 --> 00:10:50.443
Also das geht halt alles um. Das macht halt das Signal von alleine.

00:10:50.443 --> 00:10:54.443
Beim Signal sagst du einfach, da ist der Wert und jedes Mal, wenn es eine Aktualisierung gibt,

00:10:54.443 --> 00:10:55.887
genau diese Stelle aktualisiert.

00:10:57.696 --> 00:11:01.546
Falls ich das richtig verstanden habe. So stellt sich das für mich dar.

00:11:01.546 --> 00:11:03.546
Wie gesagt, ich habe das eingebaut, aber...

00:11:03.546 --> 00:11:07.546
Ja, und ein spannender Unterschied allerdings ist, und vielleicht greife ich da

00:11:07.546 --> 00:11:13.423
jetzt schon vor, aber und helfe mir vielleicht, falls ich falsch liege, ist, dass

00:11:13.594 --> 00:11:15.206
die Erstellung dieses Signals,

00:11:16.043 --> 00:11:19.546
nicht unbedingt dem Komponentencode passieren muss. Das ist ja für mich ein ganz

00:11:19.546 --> 00:11:23.443
großer Unterschied zu den Hooks. Die Hooks sind ja doch immer sehr komponentenbezogen.

00:11:23.546 --> 00:11:29.146
Die müssen zu Beginn einer Komponenten stattfinden oder es muss auf jeden Fall direkte Verbindung geben zwischen der Komponente und dem State

00:11:29.146 --> 00:11:34.466
oder dem Hook, den du machst und du kannst Signals irgendwo erzeugen. Das kann auch in

00:11:34.466 --> 00:11:37.546
einem Redux dort zum Beispiel sein, wo das erzeugt wird und du konsumierst es nachher

00:11:37.546 --> 00:11:41.586
irgendwo anders oder in einem Kontextobjekt oder einfach draußen in einem Modul. Du sagst,

00:11:41.586 --> 00:11:45.866
hey, du machst den Modul auf, da sind die paar Signals drinnen und du erstellst die dort und

00:11:45.866 --> 00:11:50.586
du kannst so viele Consumer davon machen, wie du irgendwie lustig bist, was natürlich solche

00:11:50.586 --> 00:11:55.509
Architekturen recht interessant machst, wo du dein State in einem File ausloggerst, generierst und

00:11:55.726 --> 00:12:01.206
genauso Dinge wie Sachen wie IsLockedIn oder sonst irgendwas halt an unterschiedlichen Stellen

00:12:01.206 --> 00:12:06.886
einfach von diesem einen Modul raussaugst, anstatt dass du diese Update-Trees und so weiter

00:12:06.886 --> 00:12:13.326
maintainen musst. Also das ist ja, glaube ich, einer dieser spannenden Selling Points, die Signals so

00:12:13.326 --> 00:12:19.326
interessant machen. Ich würde sagen, also ist nicht verkehrt, aber ich glaube, also es ist nicht

00:12:19.326 --> 00:12:22.245
Ich glaube nicht verkehrt, dass das bemerkenswert ist, aber ich.

00:12:23.965 --> 00:12:24.766
Glaube, bemerkenswert wird das aus der React-Perspektive.

00:12:25.018 --> 00:12:27.766
Ja, okay, gut. Wenn du ein anderes JavaScript-Programm schreibst,

00:12:27.766 --> 00:12:30.978
kannst du überall irgendein Objekt erstellen und keinem interessiert irgendwie was.

00:12:31.266 --> 00:12:35.766
Aber diese spezielle Rolle, dass diese Funktionen, in denen JSX sind, im Prinzip überhaupt nicht funktionieren,

00:12:35.766 --> 00:12:40.266
die Funktionen, sondern spezielle magische Factory-Funktionen für seltsame Objekte sind, die sich automatisch updaten,

00:12:40.266 --> 00:12:42.978
ist ja schon eine Spezialität von diesen Single-Page-Applikationen.

00:12:43.275 --> 00:12:46.011
Und da kommt halt eben genau das raus, was ich vorhin meinte mit,

00:12:46.507 --> 00:12:50.666
ja, okay, gleiche Benutzeroberfläche, aber komplett unterschiedliche Implementierung einerseits,

00:12:50.666 --> 00:12:55.266
aber auch Benefits, die sich materialisieren, andererseits, weil damit das, was du gerade beschrieben hast, ein Benefit ist,

00:12:55.266 --> 00:12:57.102
musst du in einer Welt leben, wo das nicht der Normalfall ist.

00:12:59.560 --> 00:13:04.466
Da hast du was ganz, ganz Richtiges gesagt. Das erinnert mich wieder daran, dass eigentlich das, wie wir React schreiben und machen,

00:13:04.466 --> 00:13:11.902
ja sehr, sehr stark oberflächlich getrieben ist. Und das, was darunter passiert, eigentlich ganz was anderes macht.

00:13:13.576 --> 00:13:22.926
Eben gerade auch Hookshooks ist in Wirklichkeit nur eine Bookkeeping-Tabelle mit Statusänderungen,

00:13:23.560 --> 00:13:33.906
die Subparmetrikern, grob gesagt. Ja, so ist es, ne? Ja, okay. Gut, okay. Dann habe ich das doch

00:13:33.906 --> 00:13:38.146
halbwegs gut kapiert. Also, und du hast natürlich recht, also dass man Werte aus einem Modul lädt

00:13:38.513 --> 00:13:42.546
und schreibt, das wird eigentlich in JavaScript generell gehen, genau. Das ist natürlich,

00:13:42.546 --> 00:13:45.417
wenn du sowas machst wie React, ist natürlich alles wieder ein bisschen anders.

00:13:45.778 --> 00:13:52.826
Das ist richtig. Weißt du, das kann doch ein bisschen weh.

00:13:54.339 --> 00:13:58.206
Es ist sehr interessant, was du da gerade gesagt hast, weil für mich hat das am Anfang,

00:13:58.206 --> 00:14:02.288
also ich habe auch gelesen, ich glaube von Ryan Carniato, der Solid erstellt hat, dass

00:14:02.566 --> 00:14:07.833
das dieser Benefit ist, dass man State und Komponenten nicht co-alignen muss.

00:14:08.112 --> 00:14:14.477
Und ich komme zumindest in der Webentwicklung aus sehr frühen AngularJS und Angular-Zeiten

00:14:14.783 --> 00:14:18.438
und jetzt sind die Argumente gerade für mich auch ein bisschen nachvollziehbarer geworden,

00:14:18.526 --> 00:14:24.006
bis ihr zwei darüber geredet habt, weil natürlich sollte man Sachen auch außerhalb von Komponenten

00:14:24.271 --> 00:14:34.186
Tree irgendwie verwalten können. Und dass das halt closely oder sehr sehr tightly gekoupled ist, stellt sich für mich als Developer Experience halt die Frage.

00:14:34.186 --> 00:14:38.406
Das sind wieder diese Polarisierung von zwei Seiten, wo man sagt, hey, so muss

00:14:38.406 --> 00:14:42.646
State gelöst werden oder so muss State gelöst werden. Und mir ist gerade aufgefallen, ich weiß gar nicht

00:14:42.646 --> 00:14:46.546
100 Prozent, wo ich hin möchte mit dem. Aber es ist die Realisierung, die du auch gerade

00:14:46.546 --> 00:14:51.006
angesprochen hast, dass das nicht normal ist, dass man wirklich in State komplett

00:14:51.006 --> 00:14:54.766
den Komponenten denkt, das aber irgendwie normal geworden ist, das was jetzt wieder

00:14:54.766 --> 00:15:01.166
aufbrochen wird. Ja, und das ist halt so ein bisschen, warum ich da so ein bisschen

00:15:01.166 --> 00:15:05.246
ratlos davor stehe, weil mir genau der gleiche Gedanke gekommen ist, Nanu, das

00:15:05.246 --> 00:15:09.486
hört sich doch an wie etwas, das wir früher schon mal hatten und es gibt ja

00:15:09.486 --> 00:15:12.326
auch irgendwie, sagen wir mal, theoretisch gute Gründe, warum man das halt nicht

00:15:12.326 --> 00:15:15.246
mehr macht. Ich erinnere mich noch sehr gut, wie mir zum ersten Mal jemand React

00:15:15.246 --> 00:15:23.166
verkauft hat. Da saß ich auf irgendeinem sehr unbequemen Stuhl in in Berlin und irgendwer hatte da irgendeinen Talk und erzählte das und dann dachte ich so, ah ja, das ergibt Sinn.

00:15:24.082 --> 00:15:27.166
Und jetzt kommt halt eben einfach das, was man dann halt eben früher in AngularJS

00:15:27.166 --> 00:15:31.166
oder so mit rumgespielt vor ganz, ganz langer Zeit mal halt eben so ein bisschen wieder

00:15:31.266 --> 00:15:34.201
und natürlich macht das halt eben auch Sinn, weil das ja offensichtlich früher auch funktioniert hat.

00:15:35.587 --> 00:15:39.166
Und wie immer oszilliert halt so die JavaScript-Welt hin und her zwischen, man macht das jetzt so,

00:15:39.166 --> 00:15:41.486
man macht es jetzt so, jetzt macht man es wieder anders, jetzt macht man es wieder so.

00:15:43.698 --> 00:15:48.316
Was halt so der Grund ist, warum ich das so ein bisschen davorstehe und mir so denke, ja, okay, kann man machen.

00:15:49.388 --> 00:15:52.028
Aber warum denn so viele Artikel darüber schreiben?

00:15:52.088 --> 00:15:57.589
Also, kann man nicht beschreiben, hab ich jetzt gemacht, das funktioniert auch sehr gut aus dem und dem Grund,

00:15:57.808 --> 00:16:03.488
und ich hab diese und jene Trade-offs, und guck mal, könnt ihr auch so machen. Halt dich für eine gute Idee.

00:16:03.953 --> 00:16:09.728
Gut, also, da ist halt einfach so, dass jetzt ... Ich glaub, das, was der Bernhard gerade gesagt hat mit Solid Chess,

00:16:09.788 --> 00:16:13.188
ist gar nicht so unwichtig, weil Solid Chess hat einfach gesagt,

00:16:13.188 --> 00:16:18.668
früher auch nicht immer so, und kombiniert das mit diesem Reactive Approach von Observables

00:16:18.668 --> 00:16:22.268
oder Signals oder wie auch immer du das nennen willst. Und auf einmal hast du ein neues Framework,

00:16:22.268 --> 00:16:27.708
das wirkt irgendwie ein bisschen leichter, räumt mit ein paar nervige Sachen auf, von denen alle

00:16:27.708 --> 00:16:32.588
schon genug haben, und ja, probiert es einmal, macht es einmal, und dann finden das Leute cool,

00:16:32.588 --> 00:16:37.308
dann gibt es recht viel Buzz, dann wird recht viel darüber gesprochen, und dann müssen natürlich

00:16:37.308 --> 00:16:45.348
irgendwie andere Systeme nachziehen oder auch nicht. Und vielleicht war das einfach so naheliegend,

00:16:45.348 --> 00:16:52.828
dass man das nachher in lauter andere Frameworks und Tools mit implementiert. Und deswegen ist das

00:16:52.828 --> 00:17:00.308
jetzt gerade der neueste, heißeste Trend, falls das ein Trend ist. Also ich sehe das eher locker.

00:17:00.308 --> 00:17:05.428
Also das Einzige, was ich mir gedacht habe, ist, auf ein paar Implementierungen hinbezogen,

00:17:05.428 --> 00:17:10.788
was z.B. Angular implementiert, jetzt Signals komplett from scratch, Framework inkludiert.

00:17:10.867 --> 00:17:16.268
Und ein Kollege von uns, der Michael Latki, hat ja das gleiche Konzept auf RxJS Observables

00:17:16.268 --> 00:17:22.678
basiert schon gemacht. Also es gibt schon eine Angular Implementierung davon als Plugin oder.

00:17:22.908 --> 00:17:30.068
Als Zusatzbibliothek, die auf RxJS baut, das ja quasi mitkommt mit Angular, weil das war sowieso

00:17:30.068 --> 00:17:33.742
immer noch die spannendste Entscheidung, wo es so gesagt hat, du machst dieses klassenbasierte,

00:17:33.828 --> 00:17:38.348
komponentenbasierte Framework und hast aber reaktive Datenströme irgendwo in deinen Klassen

00:17:38.348 --> 00:17:41.788
drinnen, damit du irgendwie Daten hin- und herschicken kannst. Er hat das halt jetzt

00:17:41.788 --> 00:17:50.028
hochgezogen von den Klassenmethoden rauf ins Template, hat mit ein paar Bild in Framework

00:17:50.028 --> 00:17:53.748
internes aufgeräumt, hat das Ganze performanter und schneller gemacht, hat bewiesen, dass das

00:17:53.748 --> 00:17:59.428
eigentlich dort ein besseres Konzept ist für das, was Angular machen möchte. Und Angular sagt jetzt,

00:17:59.428 --> 00:18:03.988
passt, coole Idee, schmeißen wir alles weg, machen wir neu. Dabei wäre es ja eigentlich schon da

00:18:03.988 --> 00:18:09.548
gewesen. Also das ist eine Frage, die man nicht beantworten kann. Und vielleicht eine größere

00:18:09.548 --> 00:18:17.748
Frage zu dem, was du jetzt gesagt hast, ist das, was so neu ist, ist ja das Ganze jetzt gar nicht.

00:18:17.748 --> 00:18:24.028
Also das Erste, an das mich das Ding erinnert hat, wie ich es zum ersten Mal ausprobiert habe oder zum

00:18:24.028 --> 00:18:26.711
zum ersten Mal angeschaut habe, war Knockout-Chess.

00:18:27.864 --> 00:18:34.913
Das war mein erster Gedanke. Das war halt nur ein bisschen rudimentärer, sag ich mal.

00:18:34.913 --> 00:18:39.738
Da hast du halt noch Markup und JavaScript voneinander getrennt.

00:18:40.035 --> 00:18:51.713
Wow, wer hätte das gedacht, dass das geht? Und hast halt aber genauso einfach Daten auf Knockout Observables rausgeschickt

00:18:51.918 --> 00:18:54.699
und irgendwie in deinen Markup reingebracht.

00:18:55.843 --> 00:19:01.993
Aber das war ja immer noch dann ein manuelles Subscriben, wenn ich mich recht erinnere, oder?

00:19:01.993 --> 00:19:05.873
War das ein manuelles Subscriben?

00:19:06.969 --> 00:19:12.193
Weil ich meine, der große Unterschied ist ja dieses automatische Subscriben von den Signals,

00:19:12.193 --> 00:19:16.633
auch in Abgrenzung zu den Observables, die du ja vorhin daraus gebraucht hast,

00:19:16.633 --> 00:19:22.473
dass du halt eben die benutzung in der Funktion ist ein implizites Subscriben mit passiert.

00:19:22.473 --> 00:19:30.024
Ja, das stimmt, da hast recht, weil tatsächlich musst du, also die Knockout-Observables waren ja, glaube ich, sogar Pate für diese RxJS-Observables.

00:19:30.173 --> 00:19:36.101
Oder kommen aus der gleichen Ecken oder aus dem gleichen Sumpf, sagen wir mal so.

00:19:36.473 --> 00:19:42.843
Naja, oder man kann das ja auch so sagen, die verfolgen das gleiche Ziel, wenn wir es mal mehr wertfrei formulieren wollen.

00:19:43.159 --> 00:19:45.850
Ja, die verfolgen das gleiche Ziel, das ist sehr schön.

00:19:45.994 --> 00:19:52.557
Das Knockout.js war ja sehr populär zu der Zeit damals. Und es gibt ja immer noch ziemlich viele Anwendungen da draußen, die das immer noch benutzen.

00:19:52.665 --> 00:19:56.373
Und ich würde halt wirklich sagen, so nach jQuery ist halt so Knockout.js,

00:19:56.373 --> 00:20:01.173
dass der Kandidat Nummer 1, wenn nach irgendeinem Vortrag irgendwer zu mir kommt und so kleinlaut zugibt,

00:20:01.173 --> 00:20:05.160
in Airquotes, wir benutzen noch, dann ist es entweder jQuery oder Knockout.

00:20:05.214 --> 00:20:08.773
Als ob damit irgendwas verkehrt wäre, zumal ja wirklich Knockout,

00:20:08.773 --> 00:20:10.773
wo du ja gerade die Verwandtschaftsbeziehung hergestellt hast,

00:20:10.967 --> 00:20:15.342
ja im Prinzip einfach nichts weiter ist als eine Implementierung des neuen heißen Scheiß.

00:20:15.981 --> 00:20:22.373
Ja, und ich finde es cool. Ich schaue mir dort wieder ein paar Beispiele an und denke mir, das ist super, ich würde es wieder nutzen.

00:20:22.373 --> 00:20:26.225
Das kannst du wahrscheinlich, Peter, da sind wir auch glaube ich jedes Mal, wenn wir miteinander reden,

00:20:26.373 --> 00:20:33.373
wahrscheinlich kannst du das heute mit ECMAScript Next oder Sex oder was auch immer, welchen Sprachkonstrukten

00:20:33.463 --> 00:20:40.017
und ein bisschen Wissen zu dem, wie vorher die Welt war und wie sie heute ist, kannst du wahrscheinlich ein recht fesches,

00:20:40.467 --> 00:20:45.373
elegantes und gleichgewichtiges Framework daraus machen und in Sachen,

00:20:45.373 --> 00:20:48.373
hey, du willst geschwind ein paar interaktive Elemente auf deiner Seite haben,

00:20:48.533 --> 00:20:51.373
was ja jetzt auch wieder der Trend ist, wo jetzt auch wieder alles hingeht,

00:20:51.373 --> 00:20:53.835
so auf die Art, hey, lass du es statisch und du hast ein paar so vereinzelte Punkte,

00:20:54.373 --> 00:20:56.122
wo du dich ein bisschen herumhacken kannst.

00:20:56.373 --> 00:20:59.373
Ist das ja perfekt. Das ist ja genau das, was du willst.

00:20:59.921 --> 00:21:02.009
Also ich glaube, ich werde mir das wieder anschauen.

00:21:03.612 --> 00:21:08.095
66 Kilobyte minified, also da kann man sicher was machen. Mhm, ja.

00:21:08.185 --> 00:21:11.582
Na ja, man braucht ja nicht mal irgendwie fancy Next und so Zeug.

00:21:11.622 --> 00:21:14.842
Weil ich meine, jetzt, wo wir irgendwie rausgearbeitet haben,

00:21:14.882 --> 00:21:18.342
so ein bisschen, was diese Signals am Ende für einen, ja, Effekt,

00:21:18.382 --> 00:21:20.725
so grob haben auf die gelebte Entwicklung.

00:21:21.247 --> 00:21:25.190
Wir können ja mal so ein bisschen auch den Schwenk in die Implementierung machen.

00:21:25.334 --> 00:21:28.542
Weil die ist ja eigentlich auch nicht wirklich magisch.

00:21:28.647 --> 00:21:31.542
Also, der schwierige Part ist die, ähm ...

00:21:31.816 --> 00:21:37.001
Ist ja das Einhängen in diese, wenn Update dann Folge-Updates auslösen.

00:21:37.919 --> 00:21:41.088
Redest du jetzt von der Implementierung, die du als Entwickler machen musst,

00:21:41.178 --> 00:21:43.654
oder redest du jetzt von der Implementierung des Signals an sich?

00:21:44.104 --> 00:21:48.142
Die der Signals an sich, weil die der Entwickler ist ja tatsächlich einfach nur,

00:21:48.142 --> 00:21:54.542
da gibt es ein Objekt, da subscribe ich drauf, auf die eine oder andere Weise, die sieht ja im Moment auch im Prinzip überall gleich aus,

00:21:54.542 --> 00:21:57.742
und dann fallen da Daten raus und Punkt.

00:21:57.742 --> 00:21:59.342
Das ist ja eigentlich, was ein Signal ist.

00:21:59.543 --> 00:22:03.022
Und der wirklich spannende Part ist ja dieser automatischen Anbindung.

00:22:03.022 --> 00:22:09.542
Indem ich dieses Signal anzapfe, weiß ich, dass dann meine Komponenten oder sonstigen Programmteile automatisch sich updaten,

00:22:09.542 --> 00:22:11.262
wenn das Signal einen neuen Wert liefert.

00:22:11.354 --> 00:22:13.415
Das ist ja der magische Teil, das ist ja auch der schwierige Teil,

00:22:13.658 --> 00:22:19.542
eigentlich würde ich mal behaupten, der komplizierte Teil, der Framework-spezifische Teil, weil eigentlich ist es ja bloß ein Container,

00:22:19.542 --> 00:22:20.905
wo irgendwie ein Objekt drin wohnt.

00:22:21.707 --> 00:22:23.822
Und wenn das Objekt ausgetauscht wird, dann ist halt Update.

00:22:24.389 --> 00:22:31.022
Und was dann halt eben aus dann ist halt Update folgt, Das ist dann halt eben der framework-spezifische,

00:22:31.082 --> 00:22:33.082
fallspezifische Mechanismus.

00:22:33.652 --> 00:22:34.048
Mhm.

00:22:34.940 --> 00:22:37.722
So, das heißt, die sind ja nicht mal irgendwie besonders speziell.

00:22:37.782 --> 00:22:43.242
Ist ein Containerobjekt mit irgendwie einer Methode, wo man sagen kann, hier, hast du ein neues Objekt.

00:22:43.302 --> 00:22:46.202
Kann eine Methode sein, kann irgendwie ein Setter sein.

00:22:47.264 --> 00:22:52.242
Und that's it. Der spannende Part ist halt nur, okay, wie krieg ich jetzt irgendwie meine restliche Logik,

00:22:53.007 --> 00:22:54.898
da direkt drangekoppelt? Auf eine implizite Weise meistens.

00:22:56.590 --> 00:22:59.940
Ja, und das wäre jetzt interessant, ich habe keine Ahnung, wie das funktionieren könnte.

00:22:59.940 --> 00:23:02.560
Also da kenne ich mir einfach mit Framework-Internes zu wenig aus.

00:23:02.560 --> 00:23:08.560
Es gibt einen spannenden Artikel von den Preact-Leuten, die versuchen, das zu erklären.

00:23:08.914 --> 00:23:10.800
Aber ich habe es eigentlich gar nicht verstanden.

00:23:11.201 --> 00:23:18.480
Naja, das kolliegt halt eben auch daran, dass du ja in React wirklich eine sehr seltsame

00:23:18.480 --> 00:23:25.920
Konstruktion, weil du hast deine Funktion und da ist dein JSX drin und die Erklärung

00:23:25.920 --> 00:23:31.920
ist ja, wenn die Funktion neue Parameter bekommt, dann updatet sich dieses Template. Aber ganz so ist es ja nicht so.

00:23:31.920 --> 00:23:34.760
Es ist ja mehr so eine Factory-Funktion mäßiges Ding.

00:23:34.920 --> 00:23:39.920
Und was ja passiert ist, dann der Subscribing-Mechanismus sorgt dafür, dass irgendwelche Ereignisse imitiert werden,

00:23:39.920 --> 00:23:43.456
und die sind dann natürlich angebunden an das resultierte Objekt.

00:23:44.050 --> 00:23:46.920
Und sozusagen, wenn das Ding weiß, ich bin eine Factory-Funktion für irgendwas,

00:23:46.920 --> 00:23:51.920
ist das ja gleich einer althergebrachten Klassen-Constructor-Funktion in JavaScript,

00:23:51.920 --> 00:23:54.920
die dann halt eben auch weiß, aha, ich hab hier was produziert,

00:23:54.980 --> 00:23:59.460
zudem hab ich eine Referenz, also wenn ich gecallt werde, kann ich irgendwie Kram machen.

00:23:59.520 --> 00:24:04.300
Das ist sicherlich jetzt nicht trivial oder so, aber es ist halt am Ende auch irgendwie nur so,

00:24:04.360 --> 00:24:08.500
man muss halt gucken, wie wird das Ding gebaut, und dann bindet man sich da dran.

00:24:08.560 --> 00:24:13.580
Das ist halt im Falle von ... Okay, das heißt, du haust die wahrscheinlich in den Renderhook rein,

00:24:13.640 --> 00:24:18.260
oder was war's, ShootComponentUpdate, glaub ich, war so eine Funktion, die evaluiert hat,

00:24:18.320 --> 00:24:19.393
ob es dort eine Update geben soll.

00:24:20.743 --> 00:24:27.100
Und ich glaube, mit der hat man das nachher bewerkstelligt. Ja, also die Preact-Signals, wenn man da Direct-Implementierung für rausholt,

00:24:27.100 --> 00:24:34.100
dann monkeypatchen die da eine ganze Menge an React herum, ersetzen die Create-Element-Funktion, hauen da irgendwo was in Prototypen,

00:24:34.100 --> 00:24:35.516
habe ich meine nicht auch gesehen zu haben,

00:24:36.155 --> 00:24:41.100
wo man jetzt normalerweise sagen würde, es ist ja irgendwie voll spooky, aber wenn ich jetzt irgendwie so denke,

00:24:41.100 --> 00:24:46.778
da ist es irgendwie so ein relativ stabiles Ding wie React, und da sind die Leute da am Werk, die Preact machen,

00:24:47.669 --> 00:24:51.700
die sind ja keine Vollhühner, die wissen ja extrem genau, was sie tun und wenn,

00:24:52.152 --> 00:24:57.520
extrem kompetente Leute mit einem extrem stabilen Produkt, sagen wir mal, kreativ

00:24:57.520 --> 00:25:01.260
umgehen, kriege ich jetzt nicht unbedingt da Angstzustände.

00:25:01.902 --> 00:25:09.460
Ja, es ist ja gerade so, die Projektmenschen, die verstehen ja beide Codepasen wirklich gut, also die verstehen ja React ziemlich gut und

00:25:09.460 --> 00:25:14.980
Preact ziemlich gut. Das ist ja wirklich, ja vielleicht Dinge drinnen, wo man sich halt

00:25:14.980 --> 00:25:24.300
denkt. Wow, da habe ich eigentlich Bauchweh, weil das wirkt jetzt nach einem bösen, dunklen Zauber,

00:25:24.300 --> 00:25:30.840
den ich nicht verstehe. Aber die Realität ist halt, naja, wenn du die Nebeneffekte abschätzen

00:25:30.840 --> 00:25:34.193
kannst, dann machst du es halt. Und so tun sie es dann auch dort.

00:25:34.913 --> 00:25:37.700
Ja, und vor allen Dingen, böser, dunkler Zauber ist ja letztlich auch nichts weiter,

00:25:37.700 --> 00:25:40.638
als irgendwie ein Mittel, das du anwendest.

00:25:41.818 --> 00:25:46.928
Und nur weil's böser, dunkler Zauber ist, heißt das nicht, dass es nicht böse, dunkle Mächte gibt,

00:25:46.988 --> 00:25:50.415
auf die dieses Mittel anzuwenden genau die richtige Maßnahme ist.

00:25:50.658 --> 00:25:51.891
Ja, ja, ja, das stimmt.

00:25:52.162 --> 00:25:56.728
Also irgendwie so ein Anti-Pattern ist immer ein Anti-Pattern in einem bestimmten Kontext.

00:25:56.788 --> 00:26:01.288
Es sei denn, es löst unter den spezifischen Constraints irgendwie genau dein Problem.

00:26:01.348 --> 00:26:04.868
Du hast auch schon mal Eval benutzt oder New Function geschrieben.

00:26:04.928 --> 00:26:08.168
Ständig. Ja, nicht stetig, aber hast du mal gemacht.

00:26:08.564 --> 00:26:15.608
Ja, na doch, ich mach das wirklich ständig. Aber ich habe halt auch andere Use Cases, ne?

00:26:15.608 --> 00:26:18.608
Das ist halt das Ding.

00:26:18.700 --> 00:26:26.608
So, wir müssen halt irgendwie hier, weiß ich nicht, unser Kunde kann da halt irgendwie so Javascript eintippen,

00:26:26.608 --> 00:26:30.608
und das muss halt eben evaluiert werden, weil Gründe für Datenanalyse und Zeug.

00:26:30.736 --> 00:26:34.608
Ah, okay. Gibt es da irgendwie ein Risiko? Ja, der kann höchstens seine eigene Datenbank frittieren.

00:26:34.608 --> 00:26:36.608
Ja, wunderbar. Schreibt halt eine Warnung drüber und go.

00:26:36.608 --> 00:26:43.168
Ja, das ist richtig. Du baust ein Profi-Tool und dann kann man sich halt damit auch ins Knie schießen, ist okay.

00:26:43.168 --> 00:26:54.448
Ja, das ist richtig. Also ich denke mir auch, in Wirklichkeit passiert ja dort nur das.

00:26:57.032 --> 00:27:02.748
Über dieses Monkeypatching, was ja dann zum Beispiel Frameworks oder Bibliotheken wie MobX,

00:27:03.288 --> 00:27:09.682
das ja auch in so eine Richtung geht, irgendwie über Decorators oder ähnliches lösen.

00:27:09.770 --> 00:27:14.402
Also da musst du halt, hast halt wieder diesen manuellen Step da drinnen und die Entscheidung wird da halt abgenommen,

00:27:14.402 --> 00:27:17.989
indem ja diese zwei, drei Funktionen gemonkeypatched werden.

00:27:19.700 --> 00:27:22.562
Das habe ich tatsächlich nie benutzt als MobX, muss ich ja sagen.

00:27:22.562 --> 00:27:33.062
Also, ich versuche jetzt gerade MobX wieder herauszukriegen, also ich habe es tatsächlich in einem Artikel von Bernhard, den er geteilt hat, ist mir das auch aufgefallen.

00:27:33.062 --> 00:27:37.929
Der Bernhard hat gerade aber ein Technikproblem, sonst würde er da sicher sofort rein springen.

00:27:38.487 --> 00:27:41.521
Aber wenn ich mir das jetzt anschaue, ich muss es jetzt wieder richtig herausfinden.

00:27:42.115 --> 00:27:45.896
Das ist nämlich auch schon eine Zeit lang her.

00:27:47.652 --> 00:27:51.862
Gibt es dort die Observer-Funktion und die Observer-Funktion ist nichts anderes als

00:27:51.862 --> 00:27:55.822
wie ein Decorator-Function, wo du nachher deine JavaScript- oder JSX-Komponente

00:27:55.822 --> 00:27:59.302
drinnen hast. Und was die macht, ist genau das Gleiche, dass sie sagt, hey, bevor dort

00:27:59.302 --> 00:28:03.382
dieses Render passiert, weiß ich, da drinnen sind irgendwelche

00:28:03.382 --> 00:28:17.822
Referenzen zu meinen Updates und ich kann diese Komponente speziell triggern oder speziell re-rendern, wenn in dieser reaktiven Datenklasse, die ich dort

00:28:17.822 --> 00:28:22.822
noch bei den Klassen verwendet, irgendein Update passiert. Es ist halt nur explizit. Das heißt,

00:28:22.822 --> 00:28:26.163
ich schreibe Observer und mache dann meine Komponente oder wenn ich eine Klassenkomponente

00:28:26.462 --> 00:28:29.502
habe, habe ich halt schon einen Decorator oben drauf, den ich über die Klasse schmeißen würde,

00:28:30.385 --> 00:28:34.942
weil falls man TypeScripts verwendet. Aber in Wirklichkeit macht es genau das. Es wrappt

00:28:34.942 --> 00:28:42.022
die eigene Komponente in dieses Update-Konstrukt, das dann reagiert auf diese Dinge, wenn irgendwo

00:28:42.022 --> 00:28:52.182
ein reaktiver Datenstrom neue Events liefert. Und diese Entscheidung wird dir halt abgenommen

00:28:52.182 --> 00:28:54.457
durch diese Monkey-Patch-Funktion in React und Project.

00:28:55.520 --> 00:29:00.170
Genau. Und Hooks, gleiche Geschichte. Normalerweise müsste man ja auch Funktionen hookable machen,

00:29:00.170 --> 00:29:05.998
aber das macht halt eben React in dem Fall eingebaut, Projekt auch, halt eben automatisch.

00:29:06.079 --> 00:29:13.128
Ja, genau. Aber also, soweit ich jetzt gelesen habe, die letzten Tage über Signals und Co.

00:29:13.236 --> 00:29:20.270
Und auch von Michael Westgate, glaube ich, hat er auch sehr viel Zeit verbracht,

00:29:20.270 --> 00:29:22.698
damit diese Auto-Detection in MobX einzubauen.

00:29:23.553 --> 00:29:30.907
Aber es kann auch sein, dass ich mich da jetzt täusche, weil du hast, glaube ich, einen Einwanderer gegenstellt.

00:29:31.538 --> 00:29:36.290
Nein, also ich habe mir nur versucht zu erklären, warum eben jetzt Signals anders ist, als

00:29:36.290 --> 00:29:37.290
es für MobX damals war.

00:29:37.290 --> 00:29:41.490
Weil ein Ding, das halt bei MobX auch schon immer war, mit dem MobX groß, ich will nicht

00:29:41.490 --> 00:29:46.950
sagen, hausieren gegangen ist, aber dass diese USP von MobX war, war, dass du halt wirklich

00:29:47.157 --> 00:29:50.970
sehr fein granulare Updates auf deinen Komponenten gehabt hast.

00:29:50.970 --> 00:29:56.510
Eine wunderschöne Visualisierung geben über diese DevTools, die gesagt haben, nur dieses eine kleine Teil wird jetzt aktualisiert,

00:29:56.573 --> 00:30:04.207
nicht der ganze Rest. Was halt dagegen gesprochen hat, war immer diese, also ich glaube, das hat ja mehrere Megabyte gehabt, diese Bibliothek.

00:30:04.927 --> 00:30:10.730
Und wenn ich mir jetzt den Code anschaue, der ist halt auch noch teilweise ein bisschen älter, weil Mobex halt einfach

00:30:10.968 --> 00:30:17.370
out of fashion gegangen ist, witzigerweise, um halt anderen Dingen den Vorzug zu geben,

00:30:17.370 --> 00:30:28.650
machen die das halt wirklich so, dass sie so observable oder Observer-Decorator-Funktionen

00:30:28.650 --> 00:30:33.610
haben. Das heißt, du holst dir so eine Decorator-Funktion raus, die kann in deiner Klasse

00:30:33.610 --> 00:30:41.610
auch tatsächlich ein TypeScript Decorator sein und schreibst da drin deine Functional Component

00:30:41.610 --> 00:30:45.010
oder deine React Komponente. Das heißt, du sagst, hey, du hast jetzt deinen Timer.

00:30:46.185 --> 00:30:53.690
Ist gleich Observer, Closure da drinnen und du gibst dir Komponente zurück und genau über

00:30:53.690 --> 00:30:57.970
diese Observer Methode werden diese reaktiven Updates getriggert. Das heißt, über diese

00:30:57.970 --> 00:31:03.928
Observer-Methode weiß Mobex sehr, sehr gut, wo diese Updates stattfinden.

00:31:04.693 --> 00:31:08.618
Das sind aber rund um die Komponente und ich glaube, dass genau dieser Teil von,

00:31:09.250 --> 00:31:15.010
diesen Auto-Detections übernommen wird. Also wenn jetzt das Projekt sagt, ich verwende dort ein Signal,

00:31:15.748 --> 00:31:18.930
dann überschreiben sie halt diese zigtausend Funktionen oder monkey-patchen

00:31:18.930 --> 00:31:24.741
irgendwelche internen Funktionen, um genau diese Entscheidung abzunehmen, ob,

00:31:25.610 --> 00:31:28.450
ob jetzt dort ein reaktiver Datenstrom drinnen liegt oder nicht.

00:31:29.765 --> 00:31:35.615
Das ist mein Verständnis dieser Dinge. Okay, das ist interessant, weil ich tatsächlich da habe ich keinen Unterschied gesehen,

00:31:35.805 --> 00:31:37.615
weil ich es auch im Lied gelesen habe.

00:31:37.615 --> 00:31:43.615
Ich habe mich eher dort gesehen an der direkten Integration in das ganze DOM-Updating.

00:31:43.615 --> 00:31:53.531
Das ist quasi das, was dann Solid, Projekt und Co. optimieren,

00:31:53.864 --> 00:32:04.615
Weil sie dann über diesen Compile-Step quasi eingreifen können, dass sie möglichst optimiert die Updates auf den DOM durchführen,

00:32:04.615 --> 00:32:06.674
auf Basis, wann sich bei den Observables was ändert.

00:32:07.115 --> 00:32:09.717
Sie greifen den Compile-Step ein?

00:32:10.275 --> 00:32:15.115
Also quasi durch, denn das hat, soweit ich gestern noch gelesen habe, hat das VELD angefangen,

00:32:15.115 --> 00:32:21.104
dass die halt das so kompilieren, dass sie halt direkt das DOM-Updating machen,

00:32:21.420 --> 00:32:23.115
oder die ganze Lüge an.

00:32:23.115 --> 00:32:28.775
Ja, weil du das Weltverstehs, das Welt ist im Grunde dieser eine Compiler, der halt auch sagt, hey, du, ist das ein toller Zeichen, das ist so irgendwie

00:32:29.080 --> 00:32:32.475
weil jedes JavaScript-Syntax, aber wir geben jetzt da mal eine Bedeutung drauf, ne?

00:32:32.475 --> 00:32:39.298
Und macht dort was. Und das würde natürlich Sinn geben, wenn ich während dem JSX-Kompilat selbst,

00:32:39.847 --> 00:32:45.595
sage, hey, Moment, ich hänge mich dort noch ein bisschen rein. Finde ich spannend.

00:32:45.595 --> 00:32:54.395
Naja, und du kannst das ja sowieso machen, weil ja qua Konvention die Hooks, mit denen du ja dann Signals und ähnliche State Manager auf die zugreißt, die haben ja auch eine Namenskonvention.

00:32:54.395 --> 00:32:56.780
Die fangen ja alle mit Use-Handy-Pass an. Ja, ja. Puh.

00:32:58.518 --> 00:33:03.631
Das hört sich so sehr stabil an. Das ist unglaublich. Ja, ja. Ich denke mir das gleiche.

00:33:04.459 --> 00:33:10.716
Hey, das ist immer noch besser als diese regulären Ausdrücke auf Function Prototype to String von AngularJS für die Dependency Injection.

00:33:11.395 --> 00:33:16.395
Wie funktioniert das eigentlich alles?

00:33:16.395 --> 00:33:24.515
Ich bin wieder an dem Punkt, das ist immer, wenn ich mit irgendeinem von euch zurecht

00:33:24.515 --> 00:33:27.795
komme, wo ich mir denke, warum bin ich eigentlich jetzt seit 20 Jahren in der Softwareentwicklung

00:33:27.795 --> 00:33:33.355
und bin jetzt, keine Ahnung, Kartoffelgärtner oder was weiß ich, Kartoffelbauer im Wald

00:33:33.355 --> 00:33:34.355
oder sonst irgendwas.

00:33:34.355 --> 00:33:42.915
Okay, aber vielleicht eine gute Überleitung, weil Bernhard, du hast eingangs im Vorgespräch

00:33:42.915 --> 00:33:47.835
gesagt, dass du findest, die Angular-Implementierung sei die elegantere und ich habe natürlich

00:33:47.835 --> 00:33:51.235
absolut null Ahnung, wie die Angular-Implementierung ausschaut, ich wäre aber sehr interessiert.

00:33:53.207 --> 00:34:05.018
Ja, vielleicht hole ich da noch ein bisschen aus. Ich habe auf Hackernews, mein Partner, wenn es nicht du bist, zu meiner Karriereentscheidung jetzt über die Frage.

00:34:05.333 --> 00:34:13.831
Die Verlinkung zu diesem Tweet sind, ich werde dir den nochmal schicken,

00:34:14.956 --> 00:34:20.657
Was dann gegangen ist, dass je nachdem, wie man in welchen Reihenfolgen oder wie man die

00:34:20.657 --> 00:34:27.217
Sequence verwendet, das war in Solid, dass dann quasi im Compiler also was anderes gemacht

00:34:27.217 --> 00:34:31.133
wird damit und dann entweder da die UI reactive ist oder nicht.

00:34:32.123 --> 00:34:35.337
Und das ist wirklich ein bisschen so eine Subtle Difference, die mir jetzt auch nicht

00:34:35.337 --> 00:34:41.288
unbedingt gefällt, das ist aber jetzt kein Problem per se von Signals, sondern von bestimmten Implementierungen.

00:34:42.080 --> 00:34:46.577
Und wenn man die unterschiedlichen Signale mit den Implementierungen vergleicht, da machen

00:34:46.577 --> 00:34:50.417
sie ja die einen machen es über Get-Done-Set-Date, die anderen machen es über ein Function-Call,

00:34:50.821 --> 00:34:54.620
also wie man quasi auf das Signal zugreift, oder wie man neuen Werten in das Signal setzt.

00:34:55.205 --> 00:35:01.417
Und da bin ich auf diesen, das war tatsächlich ein Artikel auf ITnext, da bin ich drauf gekommen

00:35:01.417 --> 00:35:11.457
auf Angular V 16 Next 7 Version, wo er drüber geschrieben hat, wie jetzt die Signals ausschauen

00:35:11.457 --> 00:35:15.965
in Angular 16 oder im aktuellen RFC, glaube ich.

00:35:17.045 --> 00:35:21.235
Und da hat mir unglaublich gut gefallen, dass es eine Trennung gibt zwischen

00:35:21.235 --> 00:35:26.146
Writable Signals und Read-only Signals, will ich mir ein, dass sie heißen.

00:35:26.488 --> 00:35:32.438
Und was mir aber am besten gefallen hat, waren diese drei Methoden bei Writable Signals,

00:35:32.502 --> 00:35:34.869
wo es gibt Set, Update und Mutate.

00:35:35.716 --> 00:35:40.748
Weil ich, der nicht jetzt direkt, der nicht begonnen hat im Web,

00:35:40.802 --> 00:35:43.665
oder ich würde mich nicht als Web-Native bezeichnen,

00:35:44.214 --> 00:35:53.594
Für mich sind Spreading und einzelne Properties zu ändern, so schön oder elegant das auch ist.

00:35:53.945 --> 00:35:59.815
So verwirrend habe ich selber erlebt, dass das für Menschen ist, die – ich weiß nicht,

00:35:59.815 --> 00:36:04.694
wie gern du das Wort Fullstack magst, Stefan, aber – die mit anderen Sprachen auch arbeiten müssen.

00:36:05.027 --> 00:36:09.312
Und jetzt gibt es in dieser Angular-Implementierung dieses Set, das quasi einfach den Wert überschreibt.

00:36:09.834 --> 00:36:15.560
Dann gibt es ein Update, wo man einen neuen Wert auf Basis vom alten derived.

00:36:15.623 --> 00:36:22.824
Das hat eine neue Signatur, eine T als Rückgabewert. Das heißt, da leitet man wirklich den neuen Wert ab vom alten.

00:36:23.176 --> 00:36:30.962
Und dann gibt es ein Mutate, wo der Rückgabewert void ist. Das heißt, da ändert man etwas, z.B. wenn man eine Liste oder ein Array hat.

00:36:31.332 --> 00:36:37.381
Und dann wird aber im Hintergrund genau diese Reactive Chain getriggert.

00:36:38.191 --> 00:36:43.155
Und das hat mir unglaublich gut gefallen, weil das für mich als ein Mensch, der sehr

00:36:43.155 --> 00:36:46.410
in Developer Experience interessiert ist, aufgrund meiner Studienkombination, einfach,

00:36:46.875 --> 00:36:53.835
eine saubere Trennung ist zwischen den drei unterschiedlichen Arten, wie man interagieren

00:36:53.835 --> 00:37:00.535
kann mit einem Signal oder wie man auf ein Signal schreiben kann, abgebildet in der Typesignatur der Methoden.

00:37:03.127 --> 00:37:03.730
Okay. Okay.

00:37:06.350 --> 00:37:13.000
Ich tu mir noch ein bisschen schwer, dass ich mir das vorstelle, aber ich weiß zumindest, wo du herkommst, weil...

00:37:14.272 --> 00:37:19.800
Also ich gehe ja auch gerade diesen einen Hacker-News-Thread durch, den wir auch verlinken werden,

00:37:20.205 --> 00:37:22.996
wo eben auch viele Leute sagen, hey, Moment mal, was da jetzt passiert,

00:37:23.626 --> 00:37:33.168
ist, dass wir in einem unidirektionalen Datenfluss uns Punkte erlauben, wo wir den State ändern können,

00:37:33.249 --> 00:37:38.760
der in Wirklichkeit unabhängig ist von dem, was eigentlich das Framework so macht.

00:37:38.760 --> 00:37:40.640
Also ich glaube, das ist ja die ganze Hexerei bei Signals.

00:37:42.360 --> 00:37:45.843
Das ist ja auch das, was wir jetzt, glaube ich, versucht haben, in der letzten halben Stunde herzuleiten.

00:37:46.311 --> 00:37:49.800
Und da ist es natürlich gut, wenn du das hast, wenn du wirklich explizit sagst,

00:37:49.800 --> 00:37:55.680
hey, Moment mal, du bist jetzt in einer anderen Welt, und das ist jetzt unabhängig von dem ganzen Rest,

00:37:55.680 --> 00:37:58.329
dass du halt auch die Dinge explizit machst und sagst, was da passiert.

00:37:58.456 --> 00:38:07.320
Und das verstehe ich gut. Ich schätze aber dann trotzdem, dass im Hintergrund was passiert, also ich meine, die Templates

00:38:07.320 --> 00:38:13.600
werden ja ahead of time kompiliert, nehme ich an, also ich glaube, dass man Just-in-Time-Template-Compilation

00:38:13.600 --> 00:38:16.838
macht in Angular ist eh nicht mehr der Fall, ich weiß nicht, ob das überhaupt noch geht.

00:38:17.495 --> 00:38:20.403
Du wirst wahrscheinlich auch genau das Framework sagen, hey, und da passiert das Update, und,

00:38:21.440 --> 00:38:22.140
da hängen wir sich rein.

00:38:25.822 --> 00:38:32.400
Ja, genau, ich glaube wir haben ein bisschen aneinander vorbeigeredet, weil mir ist es

00:38:32.400 --> 00:38:37.440
eher um das Ab, also um das einem Signal einen neuen Wert geben.

00:38:38.471 --> 00:38:45.240
Okay. Und da gibt es ja diese Implementierungen, zum Beispiel, dass es bei Projekt arbeitet

00:38:45.240 --> 00:38:54.560
man mit dem Punkt Value, soweit ich weiß. Und dann ist das jetzt bei Solid über die

00:38:54.560 --> 00:39:00.080
Funktion. Und das sind diese unterschiedlichen Implementierungsdetails. Und das hat mir gefallen

00:39:00.080 --> 00:39:05.520
bei Angular, dass das aufgeteilt ist auf die drei Arten, wie man interagieren kann mit

00:39:05.520 --> 00:39:15.040
Wobei ich da glaube ich gleich hinzufügen kann, dass, ich glaube, dass wir uns da einig

00:39:15.040 --> 00:39:20.840
sein könnten, dass genau dieses direkte Interagieren mit diesem einzelnen Verb ja genau das Argument

00:39:20.840 --> 00:39:25.200
war, warum wir diesen Unidirectional Dataflow haben möchten, oder wie der Dataflow gesagt

00:39:25.200 --> 00:39:31.360
hat, wie ein React verkauft worden ist, und da habe ich irgendwie total das Gefühl, es

00:39:31.360 --> 00:39:35.640
Es fehlt eine ganz wichtige Komponente, weil wenn wir jetzt wieder anfangen den All-Apps-Signals

00:39:35.640 --> 00:39:41.240
zu schreiben, direkt, natürlich haben wir dann eine super Reactive-Chain, aber zu wissen

00:39:41.240 --> 00:39:46.560
wo das herkommt und vor allem bei meinem Team arbeite ich mit mehreren Personen, die entwickeln.

00:39:48.022 --> 00:39:55.458
Das stelle ich mir sehr spannend vor. Ja, absolut. Also ich glaube, dass das genau der Knackpunkt ist, Peter, was du eingangs gesagt hast.

00:39:56.484 --> 00:40:02.579
Es ist nicht neu, wir haben jetzt lange Zeit etwas anderes gemacht. Warum ist das jetzt da und ist das überhaupt okay, was dort worden ist?

00:40:02.872 --> 00:40:11.872
Also ich glaube, das kann man jetzt echt in Frage stellen. Also ich habe da jetzt genau zu dem Punkt auch einen Artikel gefunden von Elm, also von dieser funktionalen Programmiersprache,

00:40:11.872 --> 00:40:17.752
die noch Javascript kompiliert, also quasi das Frontend-Heskel, die halt gesagt haben,

00:40:17.752 --> 00:40:24.152
hey Moment, das haben wir ausprobiert und wir machen das jetzt nicht in Favor von so einem

00:40:24.152 --> 00:40:28.912
unidirektionalen Datenfluss. Also ich will nur kurz klarstellen, ich wollte jetzt nicht sagen,

00:40:28.912 --> 00:40:36.432
dass irgendwie ich jetzt eine Frage stellen möchte, ob man das so machen kann, weil es gibt

00:40:36.432 --> 00:40:39.072
da draußen genug funktionierende Software, die das verwendet, so schlimm wird es schon nicht sein,

00:40:39.072 --> 00:40:47.059
sondern mehr so die Frage ist, warum wird das jetzt in einem Maße als, ja, als Neuheit beworben?

00:40:48.013 --> 00:40:53.072
Das ist eigentlich so das. Ich denke halt, soll halt jeder nach seiner Fasson glücklich werden,

00:40:53.072 --> 00:40:58.072
macht er ja State Management, wie er wollt. Und grundsätzlich ist es so, keine Regel ohne Ausnahme.

00:40:58.072 --> 00:41:02.072
Das heißt, nicht jedes Problem ist mit unidirektionalem Datenfluss irgendwie optimal zu erschlagen.

00:41:02.072 --> 00:41:06.675
Einen Ausweg zu haben, um es anders zu machen, um Dinge global zu managen, ist hilfreich.

00:41:07.278 --> 00:41:12.392
Aber warum das jetzt irgendwie so beworben wird, warum das jetzt grad so das Hype-Thema ist,

00:41:12.432 --> 00:41:17.405
dass es uns irgendwie auf die Podcast-Agenda gerutscht ist, das ist das, wo ich mich ein bisschen wundere.

00:41:18.135 --> 00:41:23.312
Also, ich glaub einfach, dass ... Also, jetzt nach dem Gespräch, glaub ich, versteh ich's.

00:41:23.554 --> 00:41:25.904
Ähm, nämlich, dass einfach ...

00:41:27.182 --> 00:41:31.952
Immutable ist super. Und unidirektionaler Datenfluss ist auch super.

00:41:32.736 --> 00:41:36.472
Aber hier und da gehen die Dinge halt einfach in den Weg.

00:41:36.715 --> 00:41:43.557
Und meinem Gespür nach ist Signals halt dann deswegen cool, weil du für small scoped Aufgaben

00:41:43.620 --> 00:41:47.352
relativ gut sagen kannst, da sind die Daten und da wirst du es anzeigen und fertig.

00:41:48.571 --> 00:41:56.072
Also ich glaube, dass es genau für das einen Ausbruch gibt. Aber ich meine, wenn ich jetzt meine React-Brille aufsetze, könnte ich sagen, nimmst halt

00:41:56.072 --> 00:41:56.592
You State.

00:41:57.555 --> 00:42:02.992
Ja. Und da gibt es eine richtige, also da gibt es auf jeden Fall eine Sache, die mir richtig

00:42:02.992 --> 00:42:07.912
gut gefällt bei den Signals, das ist das Automatic Dependency Tracking. Statt dem Dependency Array

00:42:07.912 --> 00:42:17.752
wissen die selber, wo die Änderungen herkommen. Und das finde ich auch einen schönen Selling Point von Signals.

00:42:21.061 --> 00:42:21.772
Ja.

00:42:24.157 --> 00:42:29.750
Ja. Ja, das versteh ich. Ja, ist natürlich mit dem Dependency Array auch so eine Sache.

00:42:30.090 --> 00:42:34.390
Ähm, also, ich bin ja weiterhin noch immer nicht 100 Prozent davon überzeugt,

00:42:34.430 --> 00:42:38.950
dass das so in der React-Welt die beste Idee war, die Klassen links liegen zu lassen.

00:42:38.990 --> 00:42:44.485
Wenn ich da so an UseEffect denke und das Dependency Array von dem, wo halt ...

00:42:44.890 --> 00:42:48.923
Also, ich glaub, ich hab nirgendwo so oft hinterstehen, irgendwie ES-Lint-Ignore.

00:42:49.310 --> 00:42:53.910
Äh, an genau der Stelle, weil es halt eben im Allgemeinen richtig ist,

00:42:53.970 --> 00:42:58.670
das Dependency Array korrekt auszufüllen, soweit, dass ich auch eine Linter-Regel haben will.

00:42:58.843 --> 00:43:04.150
Aber es gibt Umstände, wo das nicht der Fall sein sollte. Dann muss da eine ESLint-Direktive drinstehen

00:43:04.210 --> 00:43:08.089
plus ein L-langer Kommentar, der erklärt, warum diese Direktive da steht.

00:43:09.079 --> 00:43:14.170
Ich sag's euch, React-Klasten in CoffeeScript, das wird the next big thing.

00:43:14.246 --> 00:43:18.730
Also, da fang ich jetzt schon drauf an. Ganz ehrlich, das ist echt nicht schlecht.

00:43:18.730 --> 00:43:27.210
Pass auf, nicht mit CoffeeScript, mit Decorators, die es jetzt in standardkonformer Version für ECMAScript als Ganzes gibt.

00:43:27.551 --> 00:43:30.342
Die ein Game Changer sein könnten für solche Geschichten.

00:43:30.738 --> 00:43:35.090
Weil du Dinge wie Observability an Klassenmethoden annotieren könntest,

00:43:35.170 --> 00:43:39.173
wenn du nicht vor Kurzem gesagt hättest, dass Klassen doof sind und nach Lulu riechen.

00:43:39.813 --> 00:43:43.044
Ja, wie gut, dass ich meine Meinung ändern kann.

00:43:44.647 --> 00:43:48.788
Aber ja, ähm, ähm, Ember hat das so gemacht, das Klimaframework.

00:43:49.769 --> 00:43:53.050
Hat einfach das Tracked-Attribut vor Properties geschrieben,

00:43:53.090 --> 00:43:54.570
die getrackt werden sollen.

00:43:54.610 --> 00:43:56.179
Und dann hast du die ganze Reaktivität gehabt.

00:43:57.448 --> 00:44:02.450
Supercoole Sache. Ja, und was sehen wir da wieder? Man kann das so oder so machen.

00:44:02.490 --> 00:44:07.765
Und ob's dann gut funktioniert oder nicht, liegt halt echt nicht daran, ob du dich jetzt entscheidest

00:44:07.927 --> 00:44:11.170
für Redux oder UseState oder Context oder Signals.

00:44:11.210 --> 00:44:14.530
Ich glaub, das hat einfach damit, mit dem Erfolg des Projekts,

00:44:14.804 --> 00:44:16.254
exakt überhaupt nichts zu tun.

00:44:16.560 --> 00:44:20.854
Und jetzt kann ich ja mal hier meine Grand Unified Theory of Library Churn raushauen,

00:44:20.980 --> 00:44:23.023
warum ich glaube, dass das jetzt gerade so gehypt wird.

00:44:23.492 --> 00:44:29.541
Das ist nämlich, was ich an mir selbst beobachtet habe, als ich diese Signals implementiert habe in meiner mittelgroßen React-Applikation.

00:44:30.207 --> 00:44:36.030
Jetzt kommt. Mein Redux war doof und war halt oll. Das habe ich auch so nach altem Muster noch geschrieben, ohne das Redux-Toolkit.

00:44:36.320 --> 00:44:39.830
Das war also definitiv doof. Überall musste ich dran schreiben, ja, als Legacy und bla und Keks,

00:44:39.830 --> 00:44:43.030
war alles ganz unumständlich. Und Signals sind der neue heiße Scheiß.

00:44:43.030 --> 00:44:48.350
Gehe ich halt eben hin und schmeiße das alte raus und baue das neue ein. Stellt sich raus, ist danach besser.

00:44:49.706 --> 00:44:53.415
Aber warum? Ja, das war jetzt schwammend. Warum ist das jetzt besser?

00:44:53.640 --> 00:44:58.528
Hast du irgendeinen Eindruck, dass es jetzt besser ist? Ja, ist es definitiv. 100 Prozent.

00:44:58.915 --> 00:45:01.418
Und weißt du, warum? Weil ich es zum zweiten Mal geschrieben habe.

00:45:01.996 --> 00:45:07.996
Hahaha. Ich bin mir 100 Prozent sicher, wenn ich jetzt einfach gesagt hätte,

00:45:07.996 --> 00:45:12.284
ich schmeiß jetzt altes Redux raus und nehm jetzt Redux Toolkit und verwende das damit, schreib das damit neu.

00:45:12.518 --> 00:45:15.111
Oder mach das alles jetzt mit UseState, mal das alles in einen Kontext.

00:45:15.363 --> 00:45:17.388
Oder nehm irgendeine andere State-Management-Lösung.

00:45:17.883 --> 00:45:22.096
Schaffe ich es halt trotzdem nicht, das Alte 1 zu 1 ins Neue zu portieren.

00:45:22.231 --> 00:45:25.166
Notwendigerweise mache ich dabei ein paar Sachen besser.

00:45:25.463 --> 00:45:28.636
Kann gar nicht anders, weil ich ja weiß, dass das irgendwie schlecht ist.

00:45:28.636 --> 00:45:34.195
Und das würde halt übermenschliche Disziplinen erfordern, die alten, schlechten Sachen auch 1 zu 1 zu übernehmen.

00:45:34.744 --> 00:45:37.916
Wir haben ja da quasi wirklich, es ist ja im Prinzip wie in der Psychologie,

00:45:37.916 --> 00:45:42.796
dass das ja mit den kontrollierten Experimenten und so der Nachweisbarkeit von irgendwelchen Sachen

00:45:42.796 --> 00:45:44.756
halt echt eine schwierige Angelegenheit ist.

00:45:44.872 --> 00:45:47.177
Weil du halt eben nicht aus deinem eigenen Schädel rauskommst.

00:45:47.321 --> 00:45:50.904
Und deswegen glaube ich halt eben, die Signals haben meinen Code besser gemacht, aber das lag nicht an den Signals.

00:45:51.939 --> 00:46:01.121
Jetzt wäre natürlich spannend, ob das Kollektiv der Web-Entwicklerinnen und Web-Entwickler da draußen

00:46:01.196 --> 00:46:06.156
die gleiche Erfahrung hat wie du, wo sie sagen, hey Moment mal, jetzt wo Signals einsetzen, wird alles besser.

00:46:06.156 --> 00:46:17.109
Eben genau, genau weil sie es zum zweiten Mal schreiben. Und vielleicht ist das auch genau der Grund, warum wir ständig neue Dinge besser finden in den letzten Jahren als wie die davor.

00:46:17.253 --> 00:46:18.576
Das ist meine Theorie.

00:46:18.937 --> 00:46:20.017
Das ist deine Theorie.

00:46:21.475 --> 00:46:23.436
Also, ich will jetzt nicht sagen, es gibt gar keinen Fortschritt,

00:46:23.501 --> 00:46:29.036
aber ich würde sagen, ein großer Faktor im Fortschritt, im Gesamtfortschritt,

00:46:29.036 --> 00:46:33.616
findet auf individueller Ebene statt, dadurch, dass man eben Dinge neu betrachtet,

00:46:33.934 --> 00:46:38.516
nochmal neu schreibt, einen Grund hat, Dinge zu refactoren, wo man sonst eben nicht zukommen würde,

00:46:38.516 --> 00:46:41.244
weil, na, passt schon, ist gut genug, habe ich jetzt keine Zeit zu.

00:46:42.433 --> 00:46:46.656
Das kannst du halt nicht auseinanderziehen. Und deswegen bin ich da halt relativ von überzeugt,

00:46:46.716 --> 00:46:48.266
dass das halt damit zusammenhängt.

00:46:48.581 --> 00:46:53.376
Also, viel von der Verbesserung ist halt auch einfach, dass ich im Rahmen dieses ganzen Umbaus

00:46:53.436 --> 00:46:56.616
gezwungen war, ein paar Komponenten einfach umzustrukturieren.

00:46:56.676 --> 00:47:01.416
Und konsequent so Sachen zu machen wie Container-Components und die Non-Container-Components,

00:47:01.476 --> 00:47:03.876
die halt wirklich nur so ihre Props als Input haben und dann Zeug machen.

00:47:05.276 --> 00:47:09.907
Also, ich war halt dazu gezwungen, es so zu machen, wie ich es sowieso hätte machen sollen.

00:47:10.105 --> 00:47:13.456
Aber vorher erlaubte mir das Paradigma, wie ich's eingesetzt habe,

00:47:13.456 --> 00:47:17.056
nehmen und dann, naja, geht schon, passt schon, schreibe ich später um, habe ich nie getan.

00:47:18.108 --> 00:47:22.536
Und man kommt halt nicht umhin, wenn du was Neues einsetzt, kommst du, kriegst du halt

00:47:22.536 --> 00:47:26.490
deinen Kopf nicht leer und du kriegst die ganzen Erfahrungen, die du vorher gesammelt hast, nicht raus.

00:47:26.656 --> 00:47:30.656
Du hast vorher was gelernt im ersten Anlauf und dann wird es im zweiten Anlauf automatisch

00:47:30.656 --> 00:47:34.862
besser. Die Software, die das dann wirklich zu einem schlechteren Ergebnis führt, muss halt wirklich

00:47:34.925 --> 00:47:36.320
fundamental tief ins Klo greifen.

00:47:36.365 --> 00:47:38.814
Die muss ja so viel schlechter sein, wie du besser geworden bist.

00:47:42.324 --> 00:47:59.978
Also ich kann deine Aussage da zu 100% nachvollziehen und unterstützen und kann da wieder mal mein aktuelles Lieblingsartikel, was Softwareentwicklung angeht, ins Boot holen und zwar Peter Nau, Programming as Theory Building.

00:48:00.158 --> 00:48:06.144
Ich hab in Stefan schon sehr zugetextet davon, mit der Theorie, das zu programmieren,

00:48:06.378 --> 00:48:12.185
jetzt das Endziel des Programmierens ist nicht, oder Endziel schon, aber der Aktivität,

00:48:12.509 --> 00:48:18.126
ist nicht Programmtext zu erzeugen, sondern eine Theorie darüber zu erlauern, was man programmiert.

00:48:18.675 --> 00:48:22.853
Und natürlich, wenn man das nur einmal machen muss, dann wird man diese Theorie verfeinern.

00:48:23.357 --> 00:48:28.128
Und was das Werkzeug dazu ist, ist wahrscheinlich gar nicht so relevant,

00:48:28.335 --> 00:48:37.445
Sondern einfach mehr, dass man das Problem durchgedacht hat, also man hat die Fehler schon einmal gemacht und zum zweiten Mal wird es natürlich dann besser.

00:48:37.655 --> 00:48:46.420
Aber Bernhard, wenn jetzt Programmieren das Werkzeug fürs Theoriebuilding ist, wenn sozusagen ich durch diesen Akt des Selbstcodeschreibens erst lerne, was ich überhaupt brauche,

00:48:46.535 --> 00:48:49.769
wie schaffst du es denn dann, dass die KI uns alle ersetzt?

00:48:51.948 --> 00:49:01.655
Das ist eine Frage, die mir sehr gut gefällt, weil eigentlich habe ich gesagt, ich mag mich

00:49:01.655 --> 00:49:06.261
nicht sehr viel mit AI und KI beschäftigen, aber das ist genau die richtige Frage, die

00:49:06.615 --> 00:49:12.095
mir beantwortet, warum ich das nicht mag, weil die Antwort darauf ist, ja warum, also oder wie.

00:49:12.383 --> 00:49:16.965
Also das ist ein falscher Versprecher. Meine Frage ist, warum.

00:49:17.109 --> 00:49:18.874
Die richtige Frage ist, wie ...

00:49:19.882 --> 00:49:22.925
Also, ich möcht da gar nicht, weil mir macht's ja Spaß.

00:49:24.212 --> 00:49:27.815
Naja, zum einen macht's Spaß, zum anderen ist es teilweise notwendig.

00:49:28.092 --> 00:49:32.695
Klar, gibt halt Aufgaben, die wegautomatisiert gehören, wie Boilerplate hier, Komponenten da.

00:49:32.735 --> 00:49:39.237
Man kann drüber streiten, ob Boilerplate nicht auf anderer Ebene repariert werden kann, indem man ein ordentliches Framework verwendet.

00:49:39.795 --> 00:49:46.855
Ich hab letztens mir so gedacht, wie soll das mit dem mich-Ersetzen durch irgendwie so ein Prompt-Ding funktionieren,

00:49:46.855 --> 00:49:51.455
wenn ich das selber dreimal neu schreiben muss, um überhaupt zu verstehen, wie ein Weg in die richtige Richtung

00:49:51.455 --> 00:49:52.506
überhaupt aussehen könnte.

00:49:52.830 --> 00:49:57.815
Und jetzt kann man sagen, okay, das ist ein kleiner Teil vom ganzen Programmieren, die meisten Leute rümpeln einfach React-Komponenten raus.

00:49:58.079 --> 00:50:00.295
Ja, wunderbar. Die kann man aber auch auf andere Weise ersetzen,

00:50:00.295 --> 00:50:02.615
indem man sich eine UI-Library klickt oder sonst irgendwie was.

00:50:02.615 --> 00:50:09.646
Das wird halt wieder alles, ist mein Gefühl, sehr viel heißer gegessen, als es gekocht wird.

00:50:11.024 --> 00:50:19.935
Würde ich zu 100 Prozent unterschreiben. Also ich glaube, da ist nicht viel hinzuzufügen, weil gerade wenn man sich die momentanen Ansätze

00:50:19.935 --> 00:50:26.495
anschaut bei KI auf Probleme, weil Intelligenz und Knowledge oder Intelligenz und Wissen ist

00:50:26.495 --> 00:50:30.295
ein großer Unterschied und momentan sind das eher so LLMs, das sind Wissenssysteme,

00:50:30.766 --> 00:50:36.895
Und dann fällt genau dieser Schritt der Intelligenz, eine Theorie zu bauen, die man weiterentwickeln kann.

00:50:39.894 --> 00:50:45.904
Ja, also, korrigiere mich, wenn ich falsch liege, aber ich denke eben sehr viel Statistik,

00:50:45.964 --> 00:50:48.852
und das ist irgendwie nützlich, aber Wissen und Theorie,

00:50:49.167 --> 00:50:53.624
also, was ich jetzt tendenziell eher so in den Bereich von Intelligenz reinräumen würde,

00:50:53.684 --> 00:50:56.026
ist da halt eben nicht so richtig drin. Also ...

00:50:57.710 --> 00:51:02.104
Ich glaub, du habt hier nichts korrigiert. Es kann halt eben standardisierte Aufgaben,

00:51:02.164 --> 00:51:07.004
wirklich so Dinge, die ohnehin automatisierbar gut sind, ersetzen.

00:51:07.004 --> 00:51:10.871
Das ist wie so ein Industrieroboter, wie so ein 3D-Drucker, nur halt eben für ...

00:51:12.086 --> 00:51:15.354
Die Atome, aus denen wir Wissen zusammensetzen, also so Text und Code und Zeug.

00:51:16.678 --> 00:51:21.359
Aber halt auch nicht irgendwie mehr so SkyNet, bin ich immer noch nicht ganz überzeugt von.

00:51:23.735 --> 00:51:30.010
Mhm. Ja, ich seh das auch so. Äh ... kurze Dank.

00:51:32.270 --> 00:51:37.864
Kurze Dank ist das so. Auch da sehe ich halt wieder bei Leuten, die halt so sagen,

00:51:37.944 --> 00:51:43.184
also ich bin jetzt kein Psychologe, ich bin mit einer Psychologin zusammen.

00:51:43.264 --> 00:51:48.267
Bernhard, korrigiere mich, wenn ich Blödsinn rede, bevor ich mich hier zu Hause korrigieren lassen muss.

00:51:48.504 --> 00:51:52.544
Aber auch das ist doch so eine Sache, wo man relativ schwer aus seinem Kopf rauskommt.

00:51:52.624 --> 00:51:56.504
Ich lasse mir da jetzt irgendwelchen Code generieren und habe dann so den Eindruck,

00:51:56.584 --> 00:51:58.944
das ist genau das, was ich auch geschrieben hätte.

00:51:59.024 --> 00:52:03.264
Aber das weiß ich doch gar nicht, wenn ich es gesehen habe, bevor ich es geschrieben habe.

00:52:03.264 --> 00:52:07.824
Ja ohnehin mit so Mechanismen wie Confirmation Bias und ähnlichem Zeug hingeht und das Gesehene

00:52:07.824 --> 00:52:08.827
erst mal interpretiert.

00:52:11.267 --> 00:52:17.477
Ja, wiederum 100-prozentige Unterschrift, also es ist sehr viel einfacher zu sagen,

00:52:17.477 --> 00:52:20.117
ja natürlich hätte ich auch so geschrieben, wie es so zu schreiben.

00:52:20.585 --> 00:52:31.997
Exakt, genau, das war, was ich eigentlich sagen wollte. Und ich finde den Aspekt, den du gerade anspruchst, total wichtig, von davor, dass es auch andere

00:52:31.997 --> 00:52:39.597
Möglichkeiten gibt, diesen Boilerplate-Code zu reduzieren, weil wenn wir uns den jetzt

00:52:39.597 --> 00:52:43.883
generieren lassen, dann müssen wir trotzdem wahrscheinlich warten.

00:52:44.000 --> 00:52:45.757
Er existiert auf jeden Fall.

00:52:46.493 --> 00:52:53.119
Und wenn man aber richtige Abstraktionsebenen findet, dann sind nämlich die auch nicht

00:52:53.533 --> 00:52:54.865
ab Wahrscheinlichkeit basierend.

00:52:55.333 --> 00:53:02.877
Ob das jetzt andere UI Komponenten oder Frameworks oder Libraries und so sind, spielt dann nicht so viel Rolle.

00:53:02.877 --> 00:53:06.917
Es ist nicht ein Komponent oder ein Aspekt unserer Software,

00:53:06.997 --> 00:53:13.397
die auch auf Probabilistik erstellt wurde.

00:53:13.797 --> 00:53:16.291
Was mir sehr viel Ruhe gibt. Mhm.

00:53:17.812 --> 00:53:22.357
Boah. Gut, es kommt drauf an, wer das erstellt hat. Da gibt's ja ...

00:53:22.437 --> 00:53:27.237
Okay, ja. Danke fürs Nehmen der Ruhe. Hahaha! Hahaha!

00:53:27.778 --> 00:53:33.629
Naja, nee, aber da sind wir wieder bei der schwarzen Magie und den regulären Ausdrücken auf den Angular JS Funktionssignaturen.

00:53:34.133 --> 00:53:40.381
Es führt halt keinen Weg dran vorbei, zu wissen, was das richtige Werkzeug für den jeweiligen Job ist.

00:53:40.768 --> 00:53:45.629
Das ist sicherlich hilfreich, aber auch das wird am Ende sicherlich nicht maßgeblich sein

00:53:45.755 --> 00:53:48.717
für die Frage, wird das Projekt jetzt irgendwie ein großer Erfolg oder nicht,

00:53:48.717 --> 00:53:54.424
und ob es dann jetzt Signals sind oder nicht, und ob das jetzt irgendwie GitHub Copilot ist oder nicht,

00:53:54.910 --> 00:53:56.918
ob man jetzt eine UI Library verwendet oder nicht.

00:53:58.259 --> 00:54:01.717
Das wird es am Ende wahrscheinlich als einzelne Faktoren echt nicht rausreißen.

00:54:03.832 --> 00:54:13.681
Das ist der Grund, warum ich manchmal so ein bisschen so, ich mache Hacker-News auf oder das jeweilige Twitter-Äquivalent

00:54:13.681 --> 00:54:16.681
du jour und dann gucke ich da so rein und alle irgendwie so,

00:54:16.681 --> 00:54:22.241
boah, hier das neue heiße Ding und ich so, also erstens habe ich das schon mal gesehen und das ist gar nicht so neu und zum Zweiten,

00:54:22.681 --> 00:54:30.681
am Ende ist es genau nicht so relevant, wie ihr das jetzt mir alle verkaufen wollt, aus Gründen. Also entweder, weil ihr es selber

00:54:30.681 --> 00:54:33.681
weil ihr es selber glaubt, oder weil ihr was verkaufen wollt,

00:54:33.761 --> 00:54:37.161
oder ihr einen dollen, aufregenden Thumbnail für euer YouTube braucht,

00:54:37.241 --> 00:54:38.761
oder, oder, was ja alles.

00:54:38.841 --> 00:54:40.841
Valide Anlässe sind, das zu machen.

00:54:43.937 --> 00:54:48.041
Ja. Also, ich bin mittlerweile, glaube ich, zu dem Punkt gekommen,

00:54:48.121 --> 00:54:49.437
wo ich sage, ich sitze das jetzt aus.

00:54:50.112 --> 00:54:55.037
Ich habe jetzt vor, dass ich wieder Refactoring von meiner Webseite mache.

00:54:55.433 --> 00:54:58.521
Ich glaube, ich werde aber einfach wirklich Eleventy weiter nutzen,

00:54:58.521 --> 00:55:02.401
weil es ein faderstatischer Seitengenerator ist und ich werde mein Frontend,

00:55:02.644 --> 00:55:06.082
falls ich irgendwas dynamisch mache, genau so machen, wie ich es jetzt gemacht habe,

00:55:06.201 --> 00:55:10.773
indem ich ganz kleine JavaScript-Komponenten schreibe, die zehn Zeilen kurz sind ohne Framework.

00:55:12.042 --> 00:55:17.227
Und ob ich dort jetzt ein reaktives Update mache oder nicht, das weiß ich noch nicht.

00:55:18.920 --> 00:55:27.281
Ja, also, ich meine, der große Vorteil von diesen gesamtintegrierten Single-Page-Applikationen,

00:55:27.281 --> 00:55:28.921
wenn du so ein Angular hast oder ein React.

00:55:29.281 --> 00:55:34.781
Da gibt es halt echt eine Sache drin, wo ich jetzt nicht so sehe, wie man die herstellen kann

00:55:34.781 --> 00:55:39.281
mit HTML, statischem Seitengenerator und isolierten JavaScript-Komponenten.

00:55:39.281 --> 00:55:42.280
Und das ist halt eben tatsächlich der Faktor statisches Type-Checking.

00:55:44.918 --> 00:55:48.281
Das ist halt alles so ein bisschen schwierig. Wenn du wirklich so alles in JavaScript

00:55:48.591 --> 00:55:52.281
beziehungsweise Type-Script hast und das ist alles wirklich ein großes Projekt,

00:55:52.281 --> 00:55:53.947
wo alles im Prinzip Function-Called sind,

00:55:54.281 --> 00:56:02.601
dann kann das halt eben tatsächlich maschinell gecheckt werden irgendwie easy. Ja, und was ich z.B. jetzt zuletzt gebaut habe, im so Rahmen von rum experimentieren

00:56:02.601 --> 00:56:07.321
mit Web Components, mit den Klassendecorators von ECMAScript oder so, da habe ich sowas gebaut,

00:56:07.321 --> 00:56:12.961
was so ähnlich funktioniert wie ein Provider in React, sprich es gibt irgendwo ein Eltern-Element

00:56:12.961 --> 00:56:17.281
und das weiß Bescheid, was so der Zustand ist und Kind-Elemente können darauf auf eine automatische

00:56:17.281 --> 00:56:21.361
Art und Weise subscribe, was ja nicht weiter schwierig ist, wenn du dich im DOM befindest,

00:56:21.361 --> 00:56:26.121
weil du ja einfach so gucken kannst, wer imitiert hier ein Event mit Event-Delegation und irgendwie

00:56:26.121 --> 00:56:32.121
dem Closest-Selektor-Ding, kannst du ja rausfinden, für ein gegebenes Kind-Element, das ein Event registriert,

00:56:32.121 --> 00:56:35.754
welcher Provider ist mein nächstes Eltern-Element, und da beziehe ich dann die Daten her.

00:56:37.005 --> 00:56:44.121
So. Das ist alles total auch implizit und automatischer Datenfluss und alles total toll, top-down, super, nur, weil das halt eben implizit ist

00:56:44.121 --> 00:56:48.121
und am Ende auf die DOM-Struktur ankommt, kriegt man da keine Type-Sicherheit her,

00:56:48.121 --> 00:56:51.121
wenn man nicht in den Selektor irgendwie reinschreibt, jawohl,

00:56:51.121 --> 00:56:54.121
ich suche jetzt einen Provider von genau dem Typ mit diesen Attributen zum Beispiel.

00:56:54.121 --> 00:56:54.452
Beispiel.

00:56:56.666 --> 00:56:58.821
Und das ist halt eben schon, wenn es ein bisschen komplizierter wird,

00:56:58.821 --> 00:57:05.141
echt so ein bisschen ein Minus in der Developer Experience. Du kannst halt entweder dann sagen, ich verzichte auf statisches Type-Checking

00:57:05.141 --> 00:57:07.381
und dann ist es halt eben einfach JavaScript, YOLO passt schon.

00:57:07.478 --> 00:57:12.581
Oder man hat halt eben dann Type-Script, aber halt eben mit immer dann, wenn man so eine Komponente verlässt,

00:57:12.581 --> 00:57:16.101
der Schwarzen-Loch-Effekt, dass man halt mit irgendwelchen Datenquellen arbeiten muss,

00:57:16.101 --> 00:57:20.661
wo man halt nicht wirklich weiß, was rauskommt, und das entweder glauben muss, was man meint, was da rauskommt,

00:57:20.661 --> 00:57:23.061
oder Type-Checken muss, und das ist beides halt nicht so ganz optimal.

00:57:23.277 --> 00:57:26.563
Im Vergleich zu React, wo jedes Ding jederzeit einen Typ hat.

00:57:27.076 --> 00:57:33.181
Keine Ahnung, wie wir aus der Nummer wieder rauskommen sollen.

00:57:33.359 --> 00:57:41.661
Da habe ich so, glaube ich, mit dem Stefan auf der Angular-Konferenz ein bisschen drüber geredet.

00:57:41.661 --> 00:57:44.603
Noch nicht, wir haben über ein TypeScript-Workshop geredet.

00:57:44.999 --> 00:57:51.021
Also, ich war, ich habe jetzt gerade vorher automatisch gesagt, ich war ein riesiger Fan von statischem Typing,

00:57:51.021 --> 00:57:54.901
bin es nach wie vor. Aber gerade auch wieder dieser Artikel von Peter Now hat mir ein bisschen

00:57:54.901 --> 00:57:59.610
aufgezeigt, statisches Typing ist ein Tool, das uns irgendwie eine Kommunikation ermöglicht.

00:58:00.168 --> 00:58:10.101
In dem Fall eine Kommunikation mit dem Compiler und im Idealfall auch eine Kommunikation mit

00:58:10.101 --> 00:58:16.061
anderen Personen im Team. Das erste ist sehr nett, das zweite ist notwendig und da gibt

00:58:16.061 --> 00:58:22.287
es Möglichkeiten natürlich mit Types oder mit anderen, es ist aber auch ein Tool zur Kommunikation und...

00:58:24.555 --> 00:58:27.598
Jetzt weiß ich auch selber nicht mehr, wie ich da rauskomme.

00:58:28.534 --> 00:58:32.333
Naja, aber das würde ja sozusagen, wenn wir deiner Theorie folgen, würde das ja implizieren,

00:58:32.333 --> 00:58:36.333
dass es alternative Möglichkeiten gibt, diese Kommunikation herzustellen und damit den Effekt zu erzielen,

00:58:36.600 --> 00:58:38.482
den man auch über YouTube-Annotationen herstellt.

00:58:39.436 --> 00:58:46.917
Stand-Ups. Ja, genau. Ja. Pair-Programming. Stand-Ups. PRs.

00:58:47.333 --> 00:58:51.333
Aber das ist ein wichtiger Punkt. Also es geht ja wirklich um die Vermittlung von Wissen

00:58:51.472 --> 00:58:54.693
von Wissen oder um die Konservierung von Wissen. Und da gibt es andere Möglichkeiten.

00:58:55.604 --> 00:59:02.613
Typechecking ist halt tatsächlich ein sehr eleganter und direkter Weg. Das heißt,

00:59:02.613 --> 00:59:08.093
da kommst du halt dann oft nicht vorbei. Und vor allem ein definierter Weg. Ich glaube,

00:59:08.093 --> 00:59:12.573
das ist auch nicht so unwichtig bei dem Ding. Und ein überprüfbarer Weg. Du kannst ja sozusagen

00:59:12.573 --> 00:59:17.093
dir dein Typuniversum aufbauen und auf den Knopf drücken und dann kannst du zumindest mal gucken,

00:59:17.093 --> 00:59:20.549
ob so die Gesamtheit deiner Annahmen, die explizit aufgeschrieben sind.

00:59:21.603 --> 00:59:22.827
Zutreffen oder nicht.

00:59:23.093 --> 00:59:25.852
Und das ist ja so für mich auch, als ich hier Solo-Entwickler.

00:59:26.212 --> 00:59:29.093
Also ich kann mit niemandem außer meinem Kaktus im Büro ein Stand-up machen.

00:59:29.326 --> 00:59:34.359
Und das ist damit der Distributor ein bisschen schwieriger, wenn da nicht so viel zurückkommt.

00:59:35.142 --> 00:59:38.093
Also für mich ist das mehr als das, so ein Kommunikationsmittel.

00:59:38.093 --> 00:59:41.093
Für mich ist das wirklich so das Ding, das mir halt wirklich relativ deutlich erlaubt,

00:59:41.093 --> 00:59:44.093
wenn ich irgendwie einen definierten Zustand habe, relativ brutales Refactoring zu machen,

00:59:44.093 --> 00:59:48.093
wo die ganze Codebase über Tage einfach in einem komplett defekten Zustand ist,

00:59:48.093 --> 00:59:55.093
aber wo ich halt eben sagen kann, es gibt halt hier so ein lasagna-artiges Projektstruktur

00:59:55.093 --> 00:59:58.093
und da nehme ich jetzt so eine Schicht außer Mitte raus und die wird jetzt einfach mal neu gemacht

00:59:58.093 --> 01:00:01.093
und sobald halt eben an der Schicht drüber und an der Schicht drunter niemand mehr motzt,

01:00:01.093 --> 01:00:05.093
weiß ich, dass, wenn dann die Schicht in sich einigermaßen funktioniert,

01:00:05.093 --> 01:00:09.093
das dann zumindest sozusagen das Gesamtkunstwerk wird und ich halt wirklich nur die Schicht austausche

01:00:09.093 --> 01:00:12.853
und die dazugehörigen Unit-Tests, aber das Ganze ist weiterhin in sich konsistent.

01:00:13.186 --> 01:00:16.048
Das ist eine schöne Beschreibung für eine Lasagne-Architektur.

01:00:16.687 --> 01:00:20.927
Voll gut, also ich glaube jetzt wird es jeder verstanden haben.

01:00:22.098 --> 01:00:26.887
Jaja, das ist ja tatsächlich auch irgendwie so ein Ding, was ja irgendwie nicht en vogue ist, ne?

01:00:27.013 --> 01:00:29.228
Model-View-Controller von früher.

01:00:29.390 --> 01:00:32.828
Das ist heute alles Komponenten und ein hierarchischer Komponententree. Ja, super.

01:00:32.909 --> 01:00:35.628
Aber man kann halt nicht einfach mal sagen, ich mach jetzt hier mal einen größeren Umbau

01:00:35.628 --> 01:00:37.600
und reiße jetzt mal eine ganze Etage raus und baue das neu.

01:00:37.897 --> 01:00:40.828
Also wie das aus Frontend zu übertragen ist, habe ich keine Ahnung.

01:00:40.828 --> 01:00:43.868
Aber wenn ich halt einfach so eine Library schreibe, dann baue ich die definitiv lasagne-mäßig auf,

01:00:43.868 --> 01:00:49.548
damit ich halt sagen kann, brutale Refactorings innerhalb eben einer Etage sind halt eben möglich.

01:00:49.548 --> 01:00:50.950
Und dazu brauche ich dann schon den TypeScript-Support.

01:00:52.012 --> 01:00:52.589
Ja, das stimmt.

01:00:54.002 --> 01:00:57.450
Macht auf jeden Fall einiges einfacher. Ja.

01:00:58.242 --> 01:01:04.548
Apropos Kommunikation. Ich denke, das ist jetzt ein sehr guter Punkt, nachdem wir schon ganz woanders sind,

01:01:04.548 --> 01:01:08.548
als wie ursprünglich, wo wir ursprünglich gestartet haben.

01:01:08.548 --> 01:01:11.548
Verlagern wir die Kommunikation in unsere neuen Web-Menschen.

01:01:11.548 --> 01:01:14.464
Also, wir haben jetzt eine neue Webseite, sehr kurzen.

01:01:14.548 --> 01:01:18.548
Und ihr könnt uns quasi, wenn ihr die URL habt, könnt ihr uns auf Mastodon erwähnen

01:01:18.548 --> 01:01:27.400
oder auf Twitter oder jedem anderen webmenschenfähigen Social Network und eure Kommentare, eure Tweets etc.

01:01:28.094 --> 01:01:33.548
Scheinen dann direkt bei uns in den Episoden auf, beziehungsweise engagiert euch in Gesprächen mit uns.

01:01:33.548 --> 01:01:38.548
Also wenn ihr denkt, hey, die drei haben jetzt sehr stark philosophiert über unterschiedliche Frameworks,

01:01:38.548 --> 01:01:42.548
haben ein bisschen technischen Background gegeben, ihr wisst es alles besser und ihr habt tatsächlich Use Cases,

01:01:42.548 --> 01:01:50.028
die sehr, sehr stark für Signal sprechen, außer dem Rewrite, dann bitte meldet euch bei

01:01:50.028 --> 01:01:58.708
atworkingcraft.podcast.social oder auf Twitter oder in unserem Community-Draft. Wir haben überall

01:01:58.708 --> 01:02:02.828
Wege und Möglichkeiten, dass ihr mit uns in Kontakt tretet und wir würden uns freuen,

01:02:02.828 --> 01:02:04.391
wenn wir dort vielleicht ein Follow-Up drauf machen.

01:02:05.714 --> 01:02:13.484
Ist das jetzt gut genug gesegwayed? Ich mach das zum ersten Mal, aber der Peter muss halt zwei Minuten weg.

01:02:13.484 --> 01:02:17.894
Das ist die beste Abmoderation, die ich je aus einem Mund gehört habe, der nicht zu Hans gehört.

01:02:18.389 --> 01:02:26.484
Okay, dann hätte ich aber gesagt, hey, danke Bernhard für das spontane Vorbeischauen,

01:02:26.484 --> 01:02:31.884
danke Peter für wieder eine ordentliche Sitzung der Diskussion der alten Männer und Softwareentwicklung.

01:02:31.884 --> 01:02:38.884
Das werden wir auch verlinken, es gibt, der Bernhard hat uns ein Paper zur Verfügung gestellt,

01:02:38.884 --> 01:02:43.884
wie Signals damals unter einem ganz anderen Namen in Smalltalk implementiert worden sind.

01:02:43.884 --> 01:02:46.683
Und das werde ich mir jetzt zur Gemüte führen bei meinem zweiten Kaffee.

01:02:46.884 --> 01:02:50.752
Und genau, ich glaube, das war eine ganz falsche Sendung insofern.

01:02:50.968 --> 01:02:52.814
Das war's. Ja, vielen Dank.

01:02:53.345 --> 01:02:57.648
Okidoki. Viel Spaß dabei. Sagt man jetzt noch Tschüss zum Schluss?

01:02:57.884 --> 01:03:01.105
Natürlich, Tschüssi. Ok, Tschüss. Tschüdi Nöst!

01:03:01.680 --> 01:03:24.560
Music.