Revision 567: Design Patterns in der Webentwicklung

Transcript

[0:00] Ich recherchiere gerade sehr stark im Bereich Rust, wie sich diese klassischen Erich Gammer et al. Design Patterns aus 1994 mit einer Programmiersprache wie Rust umsetzen lassen, die so Konzepte wie Vererbung mitkennen.
Das ist halt der krasse Punkt, also wie promotet man Vereinfachung oder idiomatisches Javascript, das im gleichen Tenor mitschwingt wie die Design Patterns. Leute, jetzt, ich mach mir die Nägel, alles läuft.

[0:28] Music.

[0:56] Kennst du das auch? Du willst mit einer neuen Technologie starten, aber das Internet ist zu voll mit wirrem Content in verschiedenster Qualität?
Du suchst kompaktes Wissen, was dich direkt produktiv macht, mit echter Erfahrung von Experten und Expertinnen, die für deine akuten Fragestellungen da sind?
Dann solltest du mal im TrainerInnen-Netzwerk von workshops.de vorbeischauen.
Hier findest du eine Community aus über 80 TrainerInnen, welche gemeinsam Material erstellen, sich gegenseitig unterstützen und weiterbilden, um möglichst nachhaltige und hochqualitative Weiterbildungsangebote zu schaffen.
Es gibt sowohl Intensivschulungen über mehrere Tage als auch Masterclasses, welche dich über einige Monate unterstützen.
Bist du auf der Suche nach einer qualitativen Weiterbildung im Bereich Webentwicklung?
Oder möchtest du dich selbst als TrainerIn einbringen?
Dann bist du bei workshops.de genau richtig.
Schau einfach mal vorbei für alle Informationen. workshops.de Wir freuen uns auf dich!

Revision 567: Design Patterns in der Webentwicklung

https://workingdraft.de/567/

[2:12] Hallo und herzlich willkommen zu Working Draft Revision 567.
Heute haben wir am Start den Stefan.
Guten Morgen oder guten Abend oder guten Nachmittag. In unserem Fall ist es eindeutig der gute Morgen.
Man hört es ein bisschen an der beschlagenen Stimme vielleicht.
Mehr Kaffee. Und meine Wenigkeit, der Peter. Und keine Sorge, es geht nicht um TypeScript.
Es geht nicht um TypeScript. Ihr könnt in der Leitung bleiben.
Überraschung. Überraschung. Aber es ist trotzdem ein Softwareentwicklungsthema, das, ich sag mal so, dir, Stefan, ja entweder auf dem Herzen oder wie ein Stein im Magen liegt.
Also ich habe mir eigentlich nichts dabei gedacht, ich klicke mich so durchs Internet und dann komme ich auf diese wunderbare Webseite refactoring.guru also erstmal definitiv Punkte für diese Domain, die finde ich ganz gut, und dann habe ich da gesehen, ja hier so Design Patterns für TypeScript dass man da irgendwie mal erklärt bekommt, wie man sowas wie eine Factory und einen Single in TypeScript machen kann, Und du hast darauf ja relativ stark reagiert auf den cooleren Social Media Network.

[3:16] Ja, da war ich gleich. Das war ein klassischer Fall von Website öffnen, drüber lesen, wir denken, was zur Hölle, und Webseite wieder schließen.
Und tatsächlich, gerade dieser Eindruck, den ich mir dort angeschaut habe, der diese Emotion getriggert hat.

[3:34] Bei dem bleibe ich bei diesem ersten Eindruck. Ich habe mir natürlich auch jetzt die ganze restliche Seite auch angesehen.
Ich kenne die Seite auch schon von früher, also es ist nicht das erste Mal, dass ich sie sehe.
Und sie ist ja eigentlich vom Prinzip her gar nicht einmal so schlecht.
Es ist eine nahe am Plagiat vorbeischrammende Version des Reflectoring-Buchs von Martin Fowler und das Design-Patterns-Buch von Erich Gammer und seinen Kollegen.
Also das Design Patterns Buch ist eh, ich glaube das ist jetzt schon fast 30 Jahre alt.
Ich glaube 1994 das erste Mal erschienen und das ist halt so einer dieser Meilensteine in der objektorientierten Programmierung und ich weiß gar nicht, wann das Reflektorienbuch von Martin Fauler erschienen ist, aber das war auch so rund Ende 90, Anfang 2000, wenn ich mich nicht irre, 2001 vielleicht, der halt auch gesagt hat, hey, wie kann man Methoden extrahieren, Funktionen extrahieren, auf welche Muster soll man schauen, dass man eben Code leichter und verständlicher macht. Und es ist auch so ein richtig pragmatischer Guide, der teilweise Grundlagen vermittelt. Also da, wo gerade Anfängerinnen und Anfänger oft drüber stolpern und sagen.

[4:46] Ich habe jetzt dort das Gleiche geschrieben, es unterscheidet sich aber in einem Nuance, wie kann ich dort irgendwie weitermachen.
Und von dem her die grundlegenden, oder sagen wir mal so, die Ausgangssituation von dieser Webseite ist ja gut.
Also das sind Dinge, die sind wichtig meiner Meinung nach, das schadet echt nicht, wenn man die lernt und sie gehen sehr, sehr weit, um möglichst viele Programmiersprachen entsprechend zu unterstützen.
Das Ganze ist offen auf GitHub, jede Programmiersprache hat ein eigenes Repository, dort werden die Dinge verwaltet, getestet. Also das ist wirklich sehr, sehr viel. Das machen zwei Entwickler aus der Ukraine, die daran arbeiten. Es ist ein wirklich fantastisches Projekt und ich möchte dem Projekt gar nicht zu viel absprechen. Wie gesagt, außer es schreit halt ein bisschen vorbei am Plagiat. Wäre jetzt gar nicht so das Problem, wenn es nur eine Website wäre, aber sie haben halt den Premium-Content, wo sie das Ganze dann noch mal als E-Book verkaufen. Da denke ich, Okay, das Refactoring e-bookt vom Refactoring Guru um den gleichen Preis wie das Martin-Fauler-Buch, also da muss man sich nach halt entscheiden.
Aber das ist eine andere Diskussion.

[5:58] So viel zum Intro.
Okay. Möchtest du da was sagen oder soll ich weitermachen? Erzähl du mal weiter, weil ich würde sonst ansonsten so mitgehen, also das ist ja alles nicht falsch und irgendwie extrem schön aufbereitet oder so.
Ich habe mir gar nicht den Premium-Content angeguckt, aber wenn ihr da welchen habt, meine Güte, man muss ja auch von irgendwas leben.

[6:19] Genau. Passt schon. Lass dich bloß nicht von mir aufhalten. Go King!
Okay. Und dann kam dieser eine Punkt. Und zwar das Ding ist das, also ich kenne das, ich recherchiere gerade sehr stark im Bereich Rust, Rust, wie sich diese klassischen Erich Gammer et al. Design Patterns aus 1994 mit einer Programmiersprache wie Rust umsetzen lassen, die so Konzepte wie Vererbung mitkennen.
Und in der Konzepte wie Polymorphismus bedeutet, dass du drei verschiedene Orten von Polymorphismus hast, die du je nach Situation entscheiden musst.
Und das ist natürlich teilweise sehr, sehr spannend, weil Rust dir das nicht so einfach macht.
Teilweise ist es aber auch so, dass Rust eine sehr gute Sprache dafür ist, weil die Gang of Four, also die Gruppe, die das Design Patterns Buch geschrieben hat, auch gesagt hat, sie bevorzugen Komposition über Vererbung. Super, wenn du gar keine Vererbung hast, dann kannst du nur komposen. Spitze, schon mal 50 Prozent gewonnen. Dann sind die Dinge halt auch teilweise sehr grundlegend beschrieben, dass man die relativ einfach entwickeln kann.
Aber wie gesagt, der ursprüngliche Stoff 1994, da waren die objektorientierten Programmiersprachen C++ und Smalltalk, das sind auch die Beispiele im Buch.
Es hat nie eine zweite Edition gegeben von diesem Buch, es ist immer nur die erste, die die mittlerweile 40 Reprints gekriegt hat, also 40 Auflagen, aber keine Überarbeitung.

[7:42] Das heißt, die Beispiele sind immer noch Smalltalk und C++ und es gibt noch einige C++ Entwicklerinnen und Entwickler, ja, Smalltalk, hm, also ist wahrscheinlich eher ein bisschen exotisch mittlerweile und natürlich fangen dann Menschen an, dass sie diese Konzepte, die ja gut sind, die sind ja nicht so, dass das die vier Leute erfunden hätten, sondern sie haben sehr bewusst gesagt, wir haben die nur gesammelt aus über zehn Jahren Programmiererfahrung, das ist jetzt was herausgekommen ist.

[8:06] Das sind wahrscheinlich eher so Konzepte, die sie gefunden und nicht erfunden haben.
Genau. Und das passiert ja heute intrinsisch. Du machst eine Gitter-Prepo auf Awesome Typescript oder Advanced Typescript und dann kontributieren alle und tragen ihre Ideen bei, die sie aus Stack Overflow gefunden haben, von Twitter gefunden haben, aus eigenen Programmerfahrungen gefunden haben. Und was diese Gitter-Prepos heute sind, war halt früher eben die Gänger vor, die auf einer Konferenz gesagt hat, hey, ich habe eine Idee, wir reden so viel über diese Dinge, lasst uns zusammen und lasst uns ein Buch veröffentlichen. Das war halt einmal 30 Jahre früher. Aber da es nie eine zweite Auflage gegeben hat oder eine zweite Edition gegeben hat und sehr, sehr viele Programmiersprachen objektorientierte Eigenschaften haben, haben natürlich Menschen angefangen, das selbst zu adaptieren. Und gerade im Java-Bereich ist das durch die Decke gegangen, gerade mit dem Spring-Projekt, das ja, glaube ich, die höchste Dichte an Design-Patterns hat, die man sich vorstellen kann, ist das ganz, ganz stark geworden und das macht ja für so ein Projekt wie Spring hat es ja auch total Sinn gemacht und auch für eine Sprache wie Java hat es total Sinn gemacht. In dem Buch von Gamma sind das sehr stark, wie sage ich das, also alles ist ein Objekt, alles hat diese Nounismus, wie man sagt, also du musst um Funktionalität zu kapseln, musst du einen Substantiv haben oder einen Das war's.

[9:32] Ah, mir fällt der deutsche Name nicht ein, leider Gottes. Wann wird's englisch?
Ja, noun. Also du hast halt...
Es gibt... Es gibt nicht das Refactoring-Modul, sondern es gibt einen Refactorer oder so.
Also es muss überall ja...

[9:50] ...Entität dahinterstehen. Eine Entität muss zuständig sein.
Genau, genau, genau. Und von dem her eignet sich das ja auch sehr, sehr gut.
Und das ist eben genau der Punkt, wo ich jetzt hingreifen möchte.
Ich hätte gesagt, das ist sehr, und das ist auch mittlerweile ein sehr überholter Begriff, aber ich hätte gesagt, das ist sehr idiomatisch zur Programmiersprache Java. Das heißt, was Java an Syntax und an Eigenschaften hervorbringt und wie Java gedacht ist, entwickelt zu werden, weil es ist natürlich, es gibt überall Intention dahinter, wie Leute denken, dass Dinge geschrieben werden sollen, eignet sich das für Programmiersprache wie Java sehr, sehr gut und ironischerweise auch für eine Programmiersprache wie Go, die ja im Grund im gesamten Design und in der gesamten Entwicklung das Anti-Java war, aber eben genauso idiomatische Grundlagen mitbringt, mit denen man die Dinge umsetzen kann.
Also von dem her, das funktioniert, also Objektorientierung in Go schaut komplett anders aus wie in Java, aber es ist vorhanden, es ist syntaktisch anders, es hat ein paar Eigenschaften, die man berücksichtigen muss, aber dann funktioniert es. Das gleiche in Rust. Und dann haben wir eben das Problem mit dem Typescript-Bereich dieser Webseite, weil dieser Typescript-Bereich.

[11:04] Der macht absolut keine Anwendung von Typescript oder JavaScript-idiomatischen Eigenschaften.
Zum einen sind die Dinge, also wo in diesen anderen Programmierbeispielen konkrete Beispiele drinnen sind in den anderen Sprachen, sind im TypeScript tatsächlich, und das ist bitter, die schematischen Darstellungen aus dem Gammabuch vorhanden, also nicht einmal irgendwas Konkretes, und dann eben sehr, sehr stark auf Klassen und Objekte aus, wo doch die Sprache selbst viel, viel mehr Eigenschaften bietet. Bestes Beispiel, das war das erste, was ich aufgemacht habe, the Decorator.

[11:49] Ich mach bei solchen Sachen immer zuerst das Singleton auf, weil wenn das irgendwie Web- und JavaScript-related ist, dann weiß ich, wie ein Singleton geht, Hauptschreibklammer zu. Ja, genau.
Du musst mir sagen, wann ich unterbrechen soll. Ich bin gerade so in diesem Initialrand drinnen und dann rede ich wahrscheinlich für 20 Minuten und dann sagst du okay und die Episode ist aus.
Du erzählst, ich mach mir die Nägel, alles läuft.
Okay, aber das Thema ist zum Beispiel der Decorator.
Beim Decorator geht es darum, dass du ein Objekt, wie auch immer das ausschaut, mit einer anderen Klasse umhüllst oder mit einem anderen Objekt umhüllst, sagen wir mal so, um Eigenschaften draufzulegen, aber die Schnittstelle gleich zu lassen.
Das ist einmal das Grundprinzip. Das Beispiel im Reflektor Enguru ist halt wirklich, du hast Component und Decorator, du hast die Grundbestandteile und siehst, wie die miteinander funktionieren und sie funktionieren eh.

[12:43] Okay. Sehr stark auf Klassen, auf Interfaces getrillt und das Thema ist ja das, Decorators sind ja gerade ein Konzept, das in der Programmierung sehr weitläufig ist. Das ist ja teilweise Sprachfeature. Das ist auch Sprachfeature mittlerweile von JavaScript. Es gibt Klassendekoratoren, die genau das machen. Du umhüllst sie mit mehr Eigenschaften und kriegst nachher das gleiche Interface raus. Das ist ja ein gutes Konzept, das ist ein fantastisches Konzept, aber du bietet dir die Sprache viel, viel mehr. Du bietet dir die Sprache eben, dass du entweder Klassendekorator schreibst, die Syntax sind, die wirklich ein Sprachfeature sind, oder auf der anderen Seite kannst du einfach eine Dekorator Function machen. Die Dekorator Function nimmt irgendein Objekt oder irgendeine andere Funktion und umhüllt sie mit zusätzlichen Wissen. Und, das braucht meistens zwei Zeilen Code, das ist, oder drei Zeilen, oder viel, viel weniger. Und, Und das ist eben genau das, wo ich diesen Bruch hier merke, oder wo ich mir denke.

[13:41] Natürlich, das ist jetzt Decorators by the book. Und gerade in dem Beispiel ist halt wirklich dieses Grund-Klassen-Diagramm aus dem Buch einfach runtergetippt mit TypeScript-Code, der halt Access-Modifier hat, die nur in TypeScript existieren, nicht in JavaScript, der mit Interfaces arbeitet, etc. Interfaces ist wurscht, ist ein Basis-Typ, ist eh okay.
Aber du weißt schon, es ist halt einfach wirklich, oh, ich sehe ein Klassen-Diagramm und baue meine Klassen daraus, ohne zu hinterfragen, ob nicht dieses Konzept eines Decorators nicht in der Sprache und mit den idiomatischen Eigenschaften einer Sprache viel, viel besser umzusetzen wäre.
Das Gleiche für Factory Pattern. Factory Pattern kann man mit 5 Klassen lösen und dann funktioniert es auch irgendwie oder du machst einfach eine Funktion, die dein Objekt zurückgibt.
Und Funktionen sind ja auch Objekte in JavaScript und in Typescript.

[14:33] Das heißt, du bleibst in der Objektorientierung. Du verlässt ja nicht das Prinzip der Objektorientierung, aber die Sprache bietet dir halt einfach viel, viel mehr und ganz andere Gestaltungsmittel, um diese Muster umzusetzen.
Und das ist eben genau der Punkt, wo wir noch in unserer Mastodon-Diskussion waren, beziehungsweise es war halt, was ich jetzt in der letzten Viertelstunde versucht habe zu erklären, war halt einfach die nächsten 100 Zeichen auf Mastodon in meiner Antwort, wo ich gesagt habe, also ich würde es eigentlich schöner finden, wenn wir uns einmal hinsetzen würden und schauen, wie diese klassischen Pattern, die ja wirklich Sinn haben und die ja durchaus nützlich sind, mit den Mitteln der Sprache selbst umgesetzt werden können und welche.

[15:16] Varietäten man hat, beziehungsweise welche Ausprägungen das annehmen kann.
Genau. Und das ist im Grunde mein Rant gewesen. Du, alles gut, bloß kein Ende. Ich meine, ich gehe ja mit der Diagnose ziemlich genau mit.

[15:40] Was mich jetzt noch interessieren würde, wäre sozusagen...
Wie kommt es dazu, dass sich diese Diskrepanz so ausbildet? Also sprich, du hast ja vorhin mal erwähnt, es gibt diese Sprachen und jene Sprachen.
Diese, auf die die Design-Patterns gut passen. Das sind ja sowohl diese, mit denen das ursprünglich mal entwickelt wurde, die C++ und die Javas dieser Welt.
Und es gibt diese Javascripts und Rusts, auf die die nicht so gut anzuwenden sind.
Jetzt würde ich aber halt mal schon behaupten, dass irgendwie C++ und Java, Wenn man die jetzt einfach so global betrachtet recht unterschiedlich sind und Rust und JavaScript sind jetzt auch nicht besonders nahe verwandt.
Aber was würde jetzt sozusagen diese Teams auf den jeweiligen Seiten der Anwendbarkeit von Design-Patterns miteinander vereinen?
Was macht das Ganze auf die einen anwendbar und auf die anderen nicht?
Also ich bin mir nicht einmal so sicher, dass diese Muster nicht anwendbar sind.
Ich glaube nur, dass es bessere Mittel gibt, um sie anzuwenden.

[16:39] Das ist ja eigentlich meine Kernaussage. Du musst halt hinterfragen, warum dieses Muster so existiert und was die Schlussfolgerungen sind daraus. Also ein Ding natürlich, warum in C++ das Ganze entstanden ist und warum das in Java nachher funktioniert, ist, weil Java halt einfach gesagt hat, hey, wie wäre es, wenn wir C++ machen, ohne alle Dinge, mit denen man sich in den Fuß schießen kann. Und das ist dann Java geworden. Java hat sehr, sehr viele Einflüsse von C++, klarerweise. Und hat ja im Grunde, das ist ja auch das Ironische, wenn du hörst, wie Programmiersprachen entstanden sind, das gleiche Ziel gehabt wie Go 20 Jahre später, wo sie gesagt haben, hey, wir wollen einfach das, was jetzt jeder nutzt und jede nutzt, irgendwie einfacher machen und besser machen oder anders machen zumindest. Und von dem her funktioniert die Transition von C++ auf Java sehr, sehr gut.

[17:36] Deswegen funktioniert witzigerweise auch die Design Patterns in Go sehr gut, aber nicht, weil Go so ähnlich ist zu C++ oder Java, das wäre, wie gesagt, gerade die amtliche Sprache für die Entwicklung dort.
Aber Go hat sehr viel Einflüsse genommen von Smalltalk in der Entwicklung der objektorientierten Konzepte. Und das sind die Grundsprachen aus dem Buch.
Also mit denen hast du eigentlich schon mal sehr, sehr viel Grundlegendes erledigt.
Ich meine, C++ und Java braucht man nicht reden, die sind vom Objektorientierungsprinzip ja identisch, sie sind halt nur in der Ausprägung ganz, ganz anders. Und wenn du dann auf Ruby oder PHP schaust und da in die Beispiele reinschaust, die sind im Grunde auch alle von diesen Programmiersprachen inspiriert. Also PHP-Klassen sind syntaktisch und von den Eigenschaften her sehr, sehr nahe an dem, was vorher in den anderen Programmiersprachen war, also in Java, C++ und C.
Ja, aber ich meine, JavaScript ist doch auch super nah an Java dran. Also alles ist irgendwie Objekt und du hast mittlerweile auch eine Klassensyntax, da ist doch alles, der Einfluss ist ja nicht nur im Namen.
Du hast mittlerweile eine Klassensyntax, das stimmt, du hast aber bei Javascript nicht nur die Einflüsse von Java, die existieren, sondern du hast halt den ganzen Kram auch aus der funktionalen Programmierung drinnen.
Self, Lisp, Org, ich habe mir alle einmal aufgeschrieben, Scheme, ist auch ein Lisp-Dialekt, glaube ich, wo halt auch die Funktion oder die eigenständige Funktion und die Möglichkeit, dass du eine Funktion als Parameter mitgibst oder als Objekt oder als Wert behandeln kannst.

[19:03] Das ist ja im Grunde der Knackpunkt, der JavaScript so, so unterschiedlich macht.
Da hast du auf einmal eine ganz, ganz breite Palette an Möglichkeiten, dich auszudrücken.
Und das ist vielleicht auch der Punkt, wo es sich für Programmiersprache wie JavaScript oder TypeScript so viel schwieriger macht.

[19:23] Die Sprache dir nicht konsequent vorgibt, wie du zu schreiben hast, sondern man kann es in Wirklichkeit beschreiben.
Genau, ich würde das, ich hatte nämlich ungefähr den gleichen Gedanken, hatte den so generalisiert zu, dass es halt die einen Sprachen gibt, die sozusagen, die einen Werkzeugkasten hinschmeißen und sagen, mach damit was. Und die anderen, die schmeißen die auch in Werkzeugkasten hin, aber da gibt es schon, sagen wir mal, die Richtung und die Sprachmittel, zu denen es strebt. Weil du hast ja mittlerweile Funktionale Sprachmittel hast du ja in den aktuellen Java-Versionen auch drin.
Trotzdem, das ganze Ding ist halt einfach darauf ausgerichtet, dass du halt eben in Klassenarbeites denkst und produzierst.
Das ist halt immer noch tief in der DNA drin, wo du halt eben irgendwie sowas hast wie JavaScript und Rust, die einfach sagen, hier, du hast dies, dies, dies, dies, dies.
Und da gibt es irgendwie Schnittstellen, wie die Dinge miteinander arbeiten können.
Aber es gibt kein großes vereinigendes Prinzip.
Da gibt es nicht irgendwie so den Gesamtentwurf, So sieht richtiges JavaScript aus, so sieht richtiges Rust aus.
Naja, in Rust würde ich das nicht so unterschreiben. Das gibt es durchaus.

[20:30] Richtungen, die du immer wieder erkennst. Also Muster, die immer wieder kommen, Herangehensweisen, die immer wieder kommen.
Und es gibt auch Bemühungen, dass du sagst, so wird idiomatisch ein Rust-Code geschrieben.
Das ist ein ganz, ganz großes Thema in der Community.
Und das kriegst du auch implizit mit, weil du halt viel mit Dingen aus der Standardbibliothek arbeiten musst, die halt natürlich diesen ganzen Regeln folgen.
Die Werkzeuge, mit denen du das machst, sind Schraubenschlüssel und Messer und du hast nicht ein Schweizer Taschenmesser wie die Klasse.
Ja, das stimmt. Ich weiß, worauf du draus willst. Das stimmt.
Also, ich meine, das ist total easy. Wenn das einzige Ausdrucksmittel in deiner Programmiersprache eine Klasse ist, dann bleibt dir nichts anders über.
Und die ist ja auch, sagen wir mal, fähig genug, um in unterschiedlichsten Kontexten unterschiedliche Jobs zu machen.
Das heißt, du hast sowohl den Bedarf, diese Patterns zu erzeugen, als auch die Mittel, diese Patterns zu erzeugen.
Und in JavaScript und in TypeScript hast du halt die Mittel, aber du hast den Bedarf nicht.
Ja. Und das macht aber für eine sehr interessante Ausgangssituation, weil was ich nämlich noch merke, also ich arbeite sehr, sehr viel mit sehr vielen Teams, die aus unterschiedlichen Ecken der Programmierung kommen, die unterschiedlichen Hintergrund haben, wie sie es gelernt haben.
Die jetzt aber witzigerweise in dem gleichen System arbeiten müssen.

[21:58] Und das ist JavaScript schrägstrich TypeScript basiert. Und das Ausdrucksgefälle könnte nicht größer sein.
Also es gibt halt wirklich Leute, die arbeiten sehr, sehr minimalistisch, ein paar Funktionen hier und da, sehr stark modulorientiert, wo sie sagen, hey, das Modul ist für mich eine Grenze, mit der ich auch Sichtbarkeit regeln kann, mit der ich Singletons implementieren kann, wo ein Modul-Scope entsteht, den ich mit Daten befüllen kann, falls ich für dieses Modul State verwalten möchte. Und dann gibt es die andere Schule, die halt sagen, wir haben das so in Java gemacht und in Typescript schaut eh ähnlich aus. Wenn man ein bisschen schielt und den Kopf neigt, dann wird aus dem Häschen ein Ente und dann habt ihr schon hin. Und, Und das ist zum einen interessant, dass diese Ausdrucksmöglichkeit existiert und dass das auch von der Sprache unterstützt wird.
Zum anderen, was ich dann merke, ist, und da ist der Punkt, glaube ich, wo die Sprache dir dann doch stark vorgibt oder das Ökosystem dir stark vorgibt, wie du zu schreiben hast, so wie du noch ein Tooling brauchst, und das brauchst du leider Gottes, dann zerbröselt eine Seite ganz, ganz stark oder macht Probleme.
Und die andere Seite hat weniger Probleme.

[23:18] Tatsächlich hauptsächlich an der Klasse festzuhalten, die zum Beispiel in einem Build-Tool wie ESBuild oder Rollup nicht gut getreeshaked werden kann.
Das heißt, die kann nicht gut optimiert werden, dass du nur die Dinge nutzt, die du auch tatsächlich nutzen musst, ne?
Und wir haben zwar Teams gehabt, die haben ungefähr das gleiche geschrieben.
Die einen haben halt einfach ein bisschen Funktionen, Module gemacht und so weiter und natürlich auch Clustern, um State zu verwalten.
Die anderen sind komplett in die objektorientierte Schiene abgetrifftet und wir haben einen Bundle-Unterschied gehabt von 11 KB auf der einen Seite und 780 Kilowatt auf der anderen Seite.

[23:51] Fast die gleiche Sache. Okay. Das ist beachtlich.
Die eine redet mit einem Slack-SDK, die andere redet mit einem Shira-SDK.
Aber ich meine gut, immerhin hat es am Ende funktioniert. Ja, es hat am Ende funktioniert.
Das habe ich, glaube ich, auch schon mal im Podcast erzählt, die Geschichte, wo Menschen eine Vue-Applikation gebaut haben.
Ich kenne mich jetzt mit Vue nicht aus, aber da gibt es ja auch irgendwie die Möglichkeit, in Komponenten oder ähnliches Daten reinzufüttern und das Team da, die kamen halt auch alle aus objektorientierten Programmierung und hatten halt eben so die Idee, aha, Daten wurden zusammen mit ihren Manipulationsmethoden in Klassen und haben dann Klassen in diese View-Komponenten reingeschoben und die haben dann da funky Sachen mit Proxys und ähnlichem gemacht und das ging dann am Ende tatsächlich nicht mehr gut. Also hat zu fiesen heißen Bugs geführt, fällt ja so in die gleiche Kategorie von Problemen. Ich überlege gerade, warum man dort mit selbstgeschriebenen Proxys in einer Vue-Applikation?

[24:54] Nee, nee, die Klassen kommen in die Vue-Applikation und in Vue passiert da irgendwas mit Proxys.
Ja, genau, genau. Also Vue an sich baut ja auf Proxys auf, also dass du innerhalb von deinen computed methods und so weiter auf dies zugreifen kannst und die Werte rauslesen kannst, wie du über einen Proxy gelöst. Genau.
Genau, dann passiert halt irgendwelche seltsamen Heisenbugs zum einen und zum Zum anderen natürlich macht das Ganze, wenn du mit Typescript arbeitest, ja auch irgendwelche Typ-Transformationen mit den Klassen, die du da rein schmeißt.
Und dann ging das alles irgendwann darunter. Und eigentlich hat das ziemlich lange gedauert, bis ich das diagnostiziert habe, weil ich habe keine Ahnung von View und ich denke halt eben auch, okay, Klassen sind objektisch oder Klasseninstanzen sind Objekte, schiebst du halt als Daten irgendwo rein und dann wird das schon funktionieren.
War halt nicht der Fall und da war ich dann halt eben genauso überrascht wie die Herrschaften, die es geschrieben haben.
Und, okay, wenn du das dann feststellst, was machst du dann?
Weil du machst ja tatsächlich nichts irgendwie Illegales, nirgendwo steht explizit geschrieben, dass man das nicht tun soll.
Das nicht tun soll. Jedenfalls hatte ich da zu dem Zeitpunkt nichts gefunden.

[25:59] Aber irgendwie sagt das Alcatraz-Tooling halt eben auch eine gewisse Idee davon, was so Daten sind.
Und das wären wahrscheinlich tendenziell eher plain objects als irgendwelche komplizierten Klasseninstanzen mit public, private, protected und was nicht alles.
Was ja sowieso Ihnen eigentlich wurscht ist, ne? Sehr für die Katz.
Ja, halt eben nicht für, nicht auf der Typ-Ebene. Nicht auf der Typ-Ebene, aber für Vue.
Genau, für Vue ist das egal. Aber da gab's dann andere Probleme.
Speziell der Grund, warum Sie mich angehört haben, war, guck mal, ich hab hier eine simple Hallo-Welt-Klasse, Und dann checkt die View-Komponente und unten kommt ein TypeScript-Fehler raus, der so 7000 Zeilen lang ist. Erklär mal.
Hahaha.
So, Leute, ist ja ehrlich, ist mir egal, ob es da jetzt ein TypeScript-Problem ist, oder ein View-Problem, oder an der Schnittstelle, was nicht interagiert, aber irgendwie so, wenn man schon sagt, wir machen hier quasi OOP, alles ist ein Objekt inklusive Klasseninstanzen, dann würde ich halt eben auch erwarten, dass so Dinge wie, ich nehme Klasseninstanzen, schiebe es in so eine Komponente rein, dass das eben einfach so funktioniert.
Die bei JavaScript anscheinend so auf dem Antiklassentrip, zumindest teilweise, drauf sind, dass so was gar nicht berücksichtigt wird, wenn man so was tun könnte.

[27:06] Fand ich jedenfalls bemerkenswert. Ja, na ja. Es ist spannend.
Ich mein, gut, der Antiklassentrip kommt ja nicht von irgendwo, ne?
Klassen existieren jetzt seit ...
... 2017? Oh Gott. ... in JavaScript. Gute Frage. Irgendwie so was.
Also ich muss ja ganz ehrlich sagen, also seit Klassen existieren, schreibe ich sie auch gern, weil die Syntax wirklich angenehm ist.
Also wir haben versucht, in der Agentur, wo ich gearbeitet habe, haben wir versucht, eine Applikation stark objektorientiert zu machen, mit dem Revealing Module Pattern, falls du das noch kennst, wo du halt einen Function Scope erzeugst.
In dem Function Scope kannst du quasi deine Felder und Methoden definieren und das ist eine selbstausführende Funktion, die du nachher entweder mehrfach instanzieren kannst oder gleich Singleton behandeln kannst.
Also ich könnte es, glaube ich, nicht aus dem Stehgreif noch einmal herunterschreiben, aber ich finde sicher noch die Literatur hat Adios Mani damals recht populär gemacht und das ist schon irgendwie gegangen und dann kommst du drauf, ja warum geht das so, ja wegen dem Functions Code, dann kommst du drauf. Aber eigentlich konntest du natürlich auch die klassische Konstruktorfunktion Prototype machen, so wie halt Objektorientierung in Javascript damals funktioniert hat und egal egal was du gemacht hast, egal welchen Flavor du angewendet hast, alles war irgendwie mies.
Sorry, das war alles nicht das Richtige.
Und ja, mit der Klasse jetzt.

[28:31] Doch um einiges schön und um einiges angenehm, aber da ist halt auch schon viel ins Land gelaufen.
Und da haben sich in der Zwischenzeit schon viele Frameworks etabliert und da ist viel Code geschrieben worden, der halt einfach nur hauptsächlich plain JavaScript Objects gemacht hat und ein paar, Funktionen rundherum und viel mit Callbacks gearbeitet hat. Also wenn du Express anschaust zum Beispiel nicht. Ja, es ist Callback Bonanza. Und es ist halt auch ein sehr gut unterstütztes Pattern in JavaScript. Und wenn das Ökosystem so anfängt, dann kannst du nur mit der besten Syntax daherkommen. Das ist halt jetzt einmal so. Das ist jetzt in den Köpfen der Entwicklerinnen und Entwickler drin, die sich mit der Sprache auseinandergesetzt haben.
Komm, wenn ich jetzt hier so eine Software raushaue wie Vue oder TypeScript und dann irgendwie so eingängiges, sagen wir mal, Sprachfeature wie halt Klasse. Das kann man jetzt ja wirklich finden, wie man will. Oder man kann ja die Begründung, die du da herbringst, ist ja komplett korrekt für. Das war halt lange Zeit nicht da und da gibt es halt jetzt irgendwie Prior Art und die macht das halt eben nicht so.
Aber wenn ich noch irgendwie ein quasi Produkt der Gestalt raushaue, finde ich das schon, sagen wir mal, nicht überraschend davon, überrascht zu sein.

[29:49] Okay, ich bin mir jetzt nicht ganz sicher, ob ich das verstehe.
Pass auf, das Ding ist halt eben, du denkst du hier, ich bin hier kompetente Entwicklerin, ich habe hier dekadenlang hier meinen OOP-Krimpel gemacht, ich habe mir das Vue Bootcamp reingezogen, und wie ich Daten organisiere, um halt hier meine Business-Logik abzufrühstücken, das, kann ich ja offensichtlich übernehmen aus meiner OOP-Vergangenheit, weil ich ja die exakt gleichen Sprachmittel in TypeScript so wiederfinde und da geht das nicht, da kommst Das ist ja erst mal die Frage, die du dir stellst, bin ich hier das Problem? Bin ich jetzt hier bescheuert?
Mache ich hier was, was irgendwie komplett unvernünftig ist?
Und da wäre meine Antwort halt eben, nee, liegt es nicht an dir.

[30:29] Naja, also ich würde gerne mit Leuten zusammenarbeiten, die den Fehler zuerst bei sich suchen, weil ich arbeite im Moment mit Leuten zusammen, die den Fehler immer bei der Vogelmehrsprache suchen.
Ja gut, das ist auch ein ungünstiges Extrem. Ja, also die Wahrheit ist irgendwo in der Mitte.
Und das ist eigentlich genau der Punkt, auf den ich raus will.
Auch wenn die Programmiersprachen oberflächlich ähnlich sind oder du gewisse Konstrukte hast, die du in anderen Programmiersprachen auch findest. JavaScript ist halt eine neue Programmiersprache, TypeScript ist eine neue Programmiersprache und da muss man sich auch damit beschäftigen und man muss sich auch auf diese Dinge einlassen. Es ist gut, also ich spreche hier für JavaScript, dass es so viele Ausdrucksmöglichkeiten gibt, was bedeutet, du kommst schnell rein, Du kannst schnell Code fabrizieren und das ist gut, das stimmt, aber ich finde es...

[31:16] Fast einen schlimmen Umstand war, dass ich nachher gesagt habe, das reicht mir und ich schaue mir jetzt nicht an, was die Sprache sonst zu bieten hat oder ich hinterfrage nicht meine Entscheidungen. Und das finde ich sollte schon sein.
Wie gesagt, das ist jetzt 13 Jahre her, diese eine Applikation, in der wir versucht haben, Klassen mit den bestehenden Stilmitteln wiederherzustellen.
Warum haben wir das gemacht? Weil wir alle von der Uni gekommen sind und alle objektorientierte Programmierung gemacht haben.
Das war ein Territorium, wo wir uns gut ausdrücken haben können, aber das dabei ist nicht geblieben.
Also wir haben tatsächlich so, es kommen Bugs, Code wird schwer zu maintainen, du versuchst Dinge irgendwie anders zu lösen und dann kommst du darauf her, ein paar Sachen wären anders, vielleicht viel einfacher und zielführender gewesen.
Du beschäftigst dich damit und lernst, dass die Sprache andere Prinzipien auch noch hat.
Und für mich war halt die krasse Eröffnung dort, wie ich zum ersten Mal ein Ot geschrieben habe.

[32:20] Ich glaube, Node hat sehr, sehr viel dazu beigetragen, wie ich heute Javascript schreibe.
Weil die Frameworks und die APIs dort halt eben ganz, ganz anders waren.
Ganz anders waren wie der DOM zum Beispiel. Der DOM hat ja auch noch diese objektorientierten Konzepte drinnen, bis heute.
Du musst den Web-Component von HTML-Element ableiten, geht nicht anders.
Und ja, da lernst du halt eine andere Seite der Programmiersprache auch kennen, die genauso Gültigkeit hat und die teilweise zu besseren Ergebnissen führt.
Und das ist eigentlich das, auf das ich raus will. Ich will ja einfach nur, dass Leute nachdenken, was bringt mich zum besten Ergebnis, anstatt dogmatisch irgendeinem Prinzip zu folgen.
Ich würde trotzdem noch mal kurz zur Verteidigung meiner View-TypeScript-Menschen noch mal kurz den Unterschied zwischen funktioniert nicht im Sinne von gibt einen Fehler und ist suboptimal, aber bringt uns zum Ziel noch mal herausstellen wollen.
Weil ich bin mir ziemlich sicher, dass ich ziemlich viel Suboptimales mache, jedes Mal, wenn ich irgendwas Neues mache.
Aber ich habe halt nur die beschränkten Ressourcen, die da oben in meinem Hohlschädel rumschwirren, zur Verfügung.
Mit denen muss ich halt machen, was geht.
Und ich habe auch nur begrenzt viel Zeit auf dieser verfluchten Erde.

[33:28] Wenn es am Ende des Tages eben funktioniert unter Anwendung von Dingen, die, sagen wir mal, vielleicht nicht optimal oder gut sind, aber vertretbar sind, dann ist das ja oft ausreichend.
Aber wenn ich halt eben vertretbare Dinge miteinander kombiniere, die nicht optimal sein müssen, aber die vertretbar sind, dann würde ich ja schon erwarten, dass Vertretbar 1 mit Vertretbar 2 zusammenspielt.
Ja, das stimmt. Das ist natürlich im Fall deiner Vue-Menschen halt wirklich, wirklich fies.
Weil das funktioniert so lange gut, bis das nachher der eine Bruch da ist und dann bricht ja das ganze Ökosystem zusammen.
Da merkst du auf einmal, hey, Moment, das sind TypeScript, das ist ja sowieso noch irgendwie dahingeschummelt.
Und Vue hat so viele Eigenheiten, die unter der Haube stecken, die hinter einer schönen API versteckt sind.
Also das ist ja wirklich wie mit, Keine Ahnung, Eiffelturm mit Karten bauen und an der Spitze draufkommen, dass der Kleber fehlt.

[34:19] So ein bisschen. Ich meine, das ist, also das verstehe ich nicht. Da würde natürlich nachher auch der Sprache die Schuld geben, ist ganz klar.
Ja, oder zumindest halt eben sagen, so, also...
In dem Fall hatten sie halt eben ganz wenig Bugs. Das größte Problem waren halt eben die TypeScript-Fehler, die sich halt eben zu 99,9 Prozent da im Code nicht, in der Ausführung nicht manifestiert haben.
Und da habe ich halt eben auch gesagt, okay, solange bis ihr das repariert habt, wir haben das ja jetzt diagnostiziert, macht ihr halt über, da ist Any drin.
Ja. Und dann macht ihr halt eben erst mal weiter. Aber jetzt irgendwie zu sagen, oh Gott, wir haben jetzt hier einen groben Fehler begangen, Da seid ihr halt eben in eine Falle gelaufen, in dem ihr vertretbare Dinge miteinander kombiniert habt, auf eine Weise, die halt nicht vorhergesehen wurde, warum auch immer, von denen, mit denen ihr da zusammenarbeiten müsst. Ist jetzt so, das Kind ist in den Brunnen gefallen, schreibt an das Kind SNI dran und repariert es, sobald ihr es das nächste Mal seht.

[35:17] Das ist ja wieder das Schöne, dass es sowas wie SNI gibt. Also es wird ja sehr verpönt in der Community, dass man es ja nicht verenden soll und so weiter. Und ich verwende es ständig.
Also bevor ich mich da herumärgere, weil irgendwelche Typen nicht zusammenpassen und ich weiß, dass das Ding funktioniert, flapp, eine Serie drauf und es geht weiter.
Ja und vor allen Dingen, wenn es halt irgendwie, wenn die Alternative halt eben ist, extra Code zu schreiben und dem Compiler von etwas zu überzeugen, was theoretisch auch einfach in einer Zeile Kommentar drüber stehen könnte.
Ja.
Oder es gibt halt tatsächlich ja den Fall, dass etwas mal tatsächlich irgendwas ist.
Man stelle sich vor, es ist halt irgendwie irgendwas.
Es ist nicht unknown, aber es ist halt irgendwas.
Ja. Das ist ja ein subtiler und existenter Unterschied, aber wir wollten doch nicht über Typescript reden, Steffen.
Naja, es bleibt uns nicht aus. Also das ist ja eigentlich der Grundtrigger gewesen, Typescript, muss man sowieso drüber zu sprechen. Es ist ja gerade so, dass mir gerade auffällt, dass in TypeScript du schneller.

[36:23] Weil es dir lieb ist, eigentlich genau auf diese Löcher stößt, wo du merkst, hey, da haben wir uns ein bisschen verbiegen müssen, dass die Dinge wieder halbwegs funktionieren.
Und das Typescript-Team sagt auch ganz bewusst, wir machen sehr, sehr viele Trade-Offs, nur um Leute zum einen produktiv zu halten und zum anderen aber nicht in Situationen laufen zu lassen, wo wir eigentlich mehr Wissen hätten sollen.
Das klassische Thema, warum du nicht Object-Keys von einem Objekt aufrufen kannst und nachher mit genau diesen Keys das Objekt indizieren kannst, weil nix dir in deinem Programm sagt, dass tatsächlich diese Keys genau diese sind von deinem Objekt.
Ja, oder ich finde da eben ganz schön, du hast ein Array, machst irgendwie Ecke hier Klammer 0, kriegst ja den Typ von dem Array raus, machst du einen Aufruf der Add-Methode, auch an Index 0, kriegst du den Typ oder undefined Keys.
Ja, genau. Ja, genau.
Und ja, das kann ich auch verstehen. Also das ist halt, da hat TypeScript sowieso das irrsinnige Problem, dass es halt einfach eine Posthum-Sprache ist, die müssen halt einfach schauen, hey, da gibt's schon was und das müssen wir jetzt irgendwie grotbieren oder verständlich machen.
Und das ist schon ein Challenge, das ist ja, ich kenne keine andere Programmiersprache, die das so macht.

[37:35] Ich weiß nicht, also die Idee ist ja tatsächlich Ergonomie über alles mehr oder minder.
Also wir haben uns halt eben entschieden, definitiv und ganz ausdrücklich dafür, jetzt nicht alles in Airquotes richtig zu machen, sondern wir machen es halt lieber so, wie wir der Meinung sind, dass das für die Leute insgesamt am besten ist.
Keine Ahnung, ist ja vielleicht auch vergleichbar mit Go, wie sie da ja ewig lange gegen Generics gekämpft haben, weil sie halt der Meinung waren, der Trade-offs ist es nicht wert? Ich bin immer nur meiner es ist nicht wert, aber...

[38:06] Ich hab von Go keine Ahnung. Ich bin froh, wenn ich's richtig schreiben kann.
Ja, ich auch. Also, genau.
Aber das ist halt so die Idee, ne? Das ist halt so ein bisschen so, was ich vorhin schon so meinte, das sind halt mehr so die Vibes der Programmiersprache, wo halt so Faktoren wie irgendwie, ich bin funktional, ich bin objektorientiert, keine Ahnung.
Das hat halt für mich mehr so ein bisschen was ... Es ist eine sehr oberflächliche Sache.
Was mich ja mehr so interessieren würde, sind halt wirklich so Dinge wie, z.B. sagt, wir machen es korrekt oder ergonomisch. Das wären tatsächlich zwei Gegensätze, die ich aufmachen kann, wo ich jetzt irgendwie OOP und Funktionalitätsgegensatz betreiben würde. Oder so was wie, da wollte ich jetzt gerade ein Beispiel nennen, aber ich habe zu wenig Kaffee getrunken, um mich daran jetzt zu erinnern. Aber du hast sowieso gerade Luft geholt.
Ja, nein, ich verstehe, was du meinst. Also das ist ja gerade das große Problem, was ich damit habe. Also ich habe jetzt ein bisschen so die Aufgabe übernommen, dass ich mir viel Code anschaue bei uns und versuche, dort optimalere Ergebnisse zu erzielen.
Und das Thema ist natürlich, meine ersten Eindrücke sind immer, hey, da ist ein Pattern verwendet worden, das hätte ich jetzt nicht so verwendet.
Und du arbeitest auf etwas Einfacheres hin, auf etwas Griffigeres.
Du reduzierst den Code, du reduzierst den Aufwand, du drehst Konzepte um teilweise.

[39:19] Also gehst, klassisch heißt es nicht, nicht in Objekten denken, die miteinander Nachrichten schicken, sondern in Daten denken, die einen Kontrollfluss durchlaufen.
Das sind zwar so Grundprinzipien. Und ich kann ja jetzt nicht einmal sagen, dass jetzt mein Approach richtiger wäre als der andere.
Also ich würde da keine Richtigkeit oder Falschheit unterstellen, weil das ist einfach nicht so. Es ist eine andere Herangehensweise.
Das Problem ist halt, dass diese andere Herangehensweise über kurz oder lang irgendwann einmal zu Folgeproblemen führt.
Und die kannst du während dem Schreiben und Gestalten doch nicht erkennen.
Du hast halt nicht diesen Wunderwutzi-Compiler, der nachher sowieso alles auf Bytecode optimiert, sondern du hast halt, wenn du Typescript kompilierst oder JavaScript nachher durch einen Bildprozess lässt, hast immer noch den gleichen Mister, halt nur vielleicht kleiner.
Vielleicht kleiner, weil wenn du die falschen ECMAScript-Settings hast, dann bläst du das Ganze nochmal mit boilerplate-Code auf, damit du irgendwie moderne Sprachfeatures umsetzen kannst.
Haben wir auch schon oft gehabt. Und das ist jetzt gerade der Punkt in meiner Rolle und in meiner Aufgabe, wo man denkt, hey, wie geht das jetzt am besten an?
Also wie kann ich über eine große Menge an Entwicklern, Wir reden jetzt von 500 bis 700 Entwicklern, wie kann ich dort einen...

[40:32] Praktische Hilfestellungen geben, die zu einfacheren Lösungen führen, die idiomatischer zur Programmiersprache sind, ohne jetzt erstens der schulmeisternde alte Mann zu sein, der ich nicht sein möchte, zweitens zu dogmatisch zu werden, weil Dogma ist immer schlecht in einer Programmiersprache. Du verfolgst dein Ziel und du willst einfach schnellstmöglich auf das Ziel hinkommen. Das ist ein pragmatischer Approach. Und auf gewisse Dinge aufmerksam zu machen, die halt im langen Zeitraum einen irgendwie beißen könnten.
Eben wie gesagt, diese Klassen sind per Default eine Trischicke.
Ich habe dann ein fantastisches Team, denen war das bewusst, die haben Klassen geschrieben.

[41:17] Und haben nachher sämtliche Methoden mit AddPure annotiert, so ein JavaScript Kommentar, um dem Treeshaker nachher zu sagen, dass diese weggeschmissen werden kann, wenn es keine Referenzen drauf gibt. Ich habe nicht gewusst, dass das geht und ich habe mir das erklären lassen. Das heißt, sie haben große umfangreiche Klassen geschrieben, haben gemerkt, hey, irgendwie macht das sehr große Bundle Sizes und annotieren nachher alles mit AddPure, damit der Treeshaker erkennt, okay, passt, der kann optimieren. Und ich habe es nachher bezeichnet als, hey, das ist das CO2-Zertifikat des Programmierens. Du bläst die Luft voll mit CO2 und nachher kaufst du irgendwo einen Baum in Brasilien in der Hoffnung, dass alles wieder besser wird. Und genau das ist gerade der Punkt, an dem ich bin. Also gleich zu sagen, hey, warum machst du nicht ein Modul und haust dort noch ein paar Funktionen rein und du kommst auf genau den gleichen Effekt mit weniger Aufwand und mit einem besseren Endergebnis. Und wie transportiere ich das, Ohne eben der zu sein, der an jedem Song was höre, schreibt und schaut.
Grob gesagt.

[42:25] Also ich bin halt eben jetzt nicht so in der Situation so generell wie du, ich hab halt meistens irgendwie so ein kleines Team, dem irgendwo der Schuh drückt.
Also ich guck halt immer, wie gesagt, das Wort vertretbar finde ich halt immer das Interessante.

[42:41] Also ist es irgendwie jetzt tatsächlich schädlich, bringt uns das in akute Schwierigkeiten oder ist das irgendwie optimal und genau so müsst ihr das machen?
Oder ist das vertretbar? Aber wenn ihr es das nächste Mal anfasst, so wäre halt besser.
Und das ist natürlich relativ schwierig. Dein Beispiel mit diesen Klassen, wenn du halt eben da hingehst und du baust halt ein Programm damit, das infiziert ja in Anführungszeichen dein gesamtes Denken und deine gesamte Struktur.
Da kommst du ja nicht mal eben so wieder raus. Das ist ja nicht etwas, was du mit so Oh, sorry, hier mal ein bisschen refactoren, da mal ein bisschen refactoren, wenn ich zwischendurch mal fünf Minuten Zeit habe. Das gelingt ja oftmals nicht so gut.
Ja, das stimmt. Also wenn du einmal diesen Weg gehst, dann hast du lauter Entitäten, die miteinander Nachrichten austauschen. Und da wird es halt schnell kompliziert.

[43:31] Genau, man kommt halt aus der Nummer dann auch nicht so direkt da raus. Und da muss man halt vielleicht einfach sagen, ja okay, das ist jetzt irgendwie ein ungünstiges Konstrukt, aber, keine Ahnung, vielleicht kann man da den Schaden ja irgendwie anderweitig einhegen, indem man das als Modul in was anderes reinpackt, was das in Zukunft besser macht, dass man es irgendwann ersetzen kann oder irgendwie sowas. Aber das ist halt so das Ding.
Deswegen habe ich halt bei diesen Entwurfsmustern, ich habe ja diese Refactoring-Google-Webseite, die habe ich ursprünglich gefunden, habe da so drüber gescrollt, dachte so, hihi, Ken war. Und da sind sicherlich so Dinge drin bei einigen Patterns, wo ich auch wirklich sagen würde, Leute, das braucht es halt wirklich, wirklich nicht.
Wie gesagt, mein Singleton ist ja immer so der Träger bei mir.

[44:15] Aber im Rest denke ich halt eben, meine Güte, du machst ja halt mehr Arbeit, aber.

[44:21] Das ist ja nicht schädlich so aktiv, weißt du? Wenn du es halt nicht besser weißt, was willst du denn machen?
Also das mit Singleton ist wirklich ein sehr sehr gutes Beispiel, weil es ist ja, wie du es gesagt hast, Klammer auf, Klammer zu, da ist der Singleton.
Naja, ich weiß nicht, schädlich. Wie gesagt, bei uns treffen halt, diese Punkte, die schmerzen, erst viel, viel später.
Nämlich dann, wenn Bundles erzeugt werden, und dann wollen wir halt merken, dass es einen Unterschied vom Faktor 80 gibt in der Bundle-Kurse.
Und dann kann man sagen, ja, aber bitte, das sind eh nur 800 Kb oder sonst irgendwas.
Na ja, es sind 800 Kb Server-Siting-Quote, ja, aber der hat halt einmal ein Upload-Limit von 2 MB.
Das heißt, wir haben 40 % vom Upload-Budget verbraucht.
Durch einen Programmierstil. Und wir haben dieses Upload Limit sehr großzügig gewählt, weil wir ja ursprünglich eigentlich eher so diese 11-50 KB-Geschichten im Kopf gehabt haben.
Und ja, da denkt man halt schon, ja, also die Schädlichkeit trifft dich halt später, im Output. Nicht dort, wie du entwickelst oder wie das Team zusammenspielt oder ob deine Dinge miteinander funktionieren, Sondern erst damals merkst du, hey, du hast dort irgendwas, das möchtest du irgendwie rausschmeißen und...

[45:50] Nicht ganz das. Aber ich meine jetzt so bei der Treeshakebarkeit der Klassen.
Also das ist jetzt ein Problem, das hatte ich jetzt persönlich noch nicht wirklich so getroffen.
Aber was du damit meinst ist, ich habe ein Klassenkonstrukt und da wohnen diverse Methoden und vielleicht auch statische Methoden drauf.
Die werden verwendet wie Funktionen, aber weil sie in der Klasse sind, können sie, wenn sie mal nicht aufgerufen werden, nicht aus der Klasse rausgeschickt werden.
Ganz genau. Das ist das Problem.
Ja, aber ich meine, in dem Fall kannst du das ja eigentlich relativ simpel refactoren, oder?
Also du könntest ja dann so eine schattische Methode nehmen und aus der Klasse rauskriegen, weil sie hängt ja an nichts anderem, was in der Klasse drin ist.
Natürlich, natürlich könnte man das, wenn das nur eine einfache Klasse mit Methoden wäre.
Wenn du nachher aber dort irgendwelche Dinge dependency injecten musst.

[46:38] Die du eigentlich nicht dependency injecten musst, aber die halt so injected werden, dann hast du auf einmal einen Pointer zu einer anderen Klasse. Von dieser Klasse gibt es eine Instanz, die halt wieder einen Pointer zu einer anderen Klasse, von der gibt es auch wieder eine Instanz und so weiter und so fort. Das heißt, du hast dort genau das, was du beschrieben hast. Wenn du einmal in diesen Weg gehst, dann bist du schnell in diesem Netz an unterschiedlichen Entitäten, die halt irgendwie miteinander verbunden sind und das bläst das Ganze auf. Und ich glaube, das war, der Name fällt mir nicht ein, der Mensch, der Erlang entwickelt hat, der gesagt hat, objektorientiert und hat für mich bedeutet, du willst die Banane, aber was du kriegst, ist die Banane mit einem Gorilla, der sie hält und mit dem ganzen Dschungel, in dem er lebt.
Das ist es und das wäre halt tatsächlich auch meine Kritik an Klassen. Nämlich einfach nur, dass die Grenzen, die Klassen ziehen in dem Programm keine nützlichen Grenzen sind. Das sind zwar welche und die teilen das Programm ein, aber auf nicht besonders nützliche Weise. Da Da stelle ich halt eben, da gucke ich so auf die Landkarte, so von Deutschland und stelle mir so fest, aha, eine Klasse ist ungefähr so eine Arbeitseinheit wie irgendwie Schleswig-Holstein.
Wo man irgendwie so sagen kann, das ist halt so ein Bundesland, ja, und das ist irgendwie so eine Entität, das kannst du so raustrennen.

[47:56] Aber sagen wir mal so, man kann das halt auch anders organisieren, das ist nicht irgendwie offensichtlich, dass so Bundesländer wie irgendwie das Saarland, ich habe jetzt nichts gegen Schleswig-Holstein, das Saarland oder keine Ahnung, Vorarlberg, irgendwie sowas.
Aber die tun ja sozusagen für sich genommen nicht viel. Die haben halt irgendwelche Aufgaben übertragen bekommen und die führen die auch aus und das arbeitet irgendwie alles zusammen oder so.
Aber es ist nicht offensichtlich, dass das nötige, sagen wir mal, Arbeitseinheiten sind, finde ich. Und Klassen sehe ich genauso.
Ja, ich verstehe.

[48:25] Ich verstehe. Ja, ich bin da sogar ein bisschen zweigeteilt. Ich finde teilweise Klassen sehr, sehr nützlich und ich hätte mir das wahrscheinlich vor fünf Jahren noch nicht so sagen dürfen, aber tatsächlich gibt es Situationen, wo ich die sehr, sehr nützlich finde.
Zum Beispiel auch ein Pattern, das dort beschrieben wird, das Bilderpattern, wo du eben ein komplexes Objekt konstruieren möchtest, das verschiedene Parameter annehmen kann.

[48:53] Und das in einem einzigen Konstruktor oder mit einer einzigen Konstruktor-Funktion einfach nicht so easy zu machen ist. Und dort behältst du State innen, das heißt, du mutierst konstant State durch Methoden aufrufen und hast nachher diesen Build-Command, der dir nachher das Resultat ausspuckt. Und das ist ein wunderschönes Pattern, das funktioniert auch in JavaScript exzellent. Es gibt ein Tool, das nennt sich Commander.js. Commander.js erlaubt dir Command-Line-Applikationen zu bauen mit diesem Builder-Pattern. Super einfach zu verwenden, super gute Outputs, also genau das, was ich eigentlich möchte. Und dort bringt mir das auch in JavaScript was. Und dort finde ich auch die Idee von einer Klasse gut, weil du hast halt mutierbaren State, den musst du irgendwie verwalten und diese Methoden helfen dir, diesen State zu verwalten. Wenn das nicht simpel und einfach ist, dass in einem Plain JavaScript Object dargestellt werden kann, was normalerweise diese Datencontainer eigentlich alle sind.
Da macht es durchaus Sinn, dass ich sage, okay, bevor ich zu diesem Resultat komme oder das Resultat ist so komplex, dass ich das nicht anders ausdrücken kann, dann in Gott's Namen bitte macht mir doch eine Klasse, macht eine Instanz und hat da dann seine Getter, Setter oder Modifier, um diesen State zu verwalten.
Aber ich möchte das immer eigentlich auf den State zurückführen und auf die Eigenschaften vom State entscheiden, ob ich das jetzt nehme oder nicht.

[50:16] Aber ich meine, das Bilderpattern hat doch nichts mit Klassen zu tun.
Das ist doch, ich meine, jQuery hat das ja auch und das ist ja notwendigerweise qua Alter schon vor Klassen gewesen. Das ist ja im Prinzip ein, das Bilderpattern ist doch ein User-Interface zum Konstruieren eines Objekts und ob das jetzt so oder so umgesetzt ist, ist ein Implementierungsdetail.
Ja, da hast du recht. Da hast du recht. Da hätte ich aber jetzt gesagt, wenn ich jetzt ein Builder-Pattern umsetzen würde, dann wäre wahrscheinlich die Klasse meine erste Wahl.

[50:47] Das mag sein, weil es das sehr viel einfacher und effizienter macht. Du willst ja dann irgendwann die Methoden auf dem Prototyp räumen, der Effizienz wegen.
Genau und das ist eben genau der Punkt, wo ich eben gesagt habe, also ich finde ja die Klasse Syntax, wie sie jetzt ist und wie sie jetzt in JavaScript gelandet ist, finde ich nicht schlecht.
Es ist sehr komfortabel und du kannst sehr coole Sachen damit machen. In den Anwendungsfällen, wo ich jetzt denke, dass das passt. Und ich finde aber, dass es nicht in jedem Anwendungsfall passt.

[51:15] Ja, ja, also auch da würde ich sagen, Klasse ist wieder eine konkrete Implementierung von, es gibt eine vernünftige Syntax, den Prototypen zu managen.
Es war ja damals in der grauen Vorzeit tatsächlich auch in der Diskussion, dass man statt eines Klassen-Keywords oder ergänzend zum Klass-Keyword einen Prototype-Setting-Operator einführt.
Also eine sehr viel komfortablere Version von Object Create.
Die hätte ja sozusagen es dir auch ermöglichen können, dieses User Interface eines Builder-Patterns herzustellen.
Also ich würde tatsächlich sagen, in dieser ganzen Liste, der Liste der klassischen Design-Patterns, finde ich das Builder-Pattern ist dann am deplatziertesten, zusammen mit der Factory, weil das ist eine User Experience und keine...
Und okay, das kann man mit einer Implementierung umsetzen, aber eigentlich ist es ja egal.
Der Sinn von Abstraktion ist ja, okay, ich rufe einfach hier diese Kette von Quasimethoden auf und am Ende fällt das Objekt raus, das ich haben möchte, sei es jetzt eine Verkettung in Form eines Builders oder sei es ein einziger Call in Form einer Factory, aber es ist doch egal, wie es gebaut ist.

[52:20] Ich überlege gerade, ob ich dem was kontern kann, aber ich glaube, ich verstehe, was du meinst, ja.

[52:33] Weißt du, ein Singleton in der OOP-Sprache, das ist tatsächlich wirklich eine Umsetzung zur Lösung eines Problems.
Das ist keine User Experience, das ist eher das Gegenteil davon.
Ich kann immer sagen New, New, New und krieg immer die gleiche Instanz zurück.
Das ist ja wirklich ein Effekt, das ist ja wirklich Magie. Das ist wirklich was, wo, wenn man daran nicht eingeweiht ist, ich denk, wow, wie funktioniert das denn? Das ist ja spannend.
Aber das andere ist Oberfläche, das ist Fassade. Okay, das ist keine Fassade, das ist nicht das Schreibenpattern.
Aber das würde ich tatsächlich auch dann nochmal irgendwie anders sehen.

[53:14] Ich bin mir noch nicht ganz sicher, wo in deiner Argumentation bei mir gerade der Bruch herrscht.
Ich glaube, ich verstehe, was du meinst.
Ich hätte aber trotzdem gesagt, wir haben ja angefangen damit, dass wir sagen, haben wir nicht gesagt, dass die Klassen, die Wurzel, allen übel sind?
Oder fehlt mir da jetzt der Zusammenhang?
Nö, ich bin jetzt einfach nur so spaßeshalber auf den Zug aufgestiegen, weil, du weißt es doch, Stefan, wenn wir zwei zusammen podcasten, Dann höre ich in deine Stimme rein und sage so, wo auf der Klassenargumentationsskala muss ich mich platzieren, um den Stefan ins Nachdenken zu bringen.
Ah, war ich zu weich heute oder was?
Und heute denke ich halt eben, ja, okay, komm, machen wir mal ein bisschen so, machen wir uns mal auf der Antiklassenseite ein bisschen weich.
Ja, ich meine, gut, du sagst dieses User Experience oder halt Entwickler und Entwicklerinnen Experience, ja, das kann ich so akzeptieren, aber das ist halt auch einmal Teil der Rechnung, nicht?
Also, wenn ich ein Mittel habe, mit dem ich mich ausdrücken kann, dann soll ich das natürlich auch verwenden. Und ich finde, in Bereichen, wo es eben darum geht, dass man einen komplexen State mutieren muss, ist die Klasse ein total valides Instrument.

[54:23] Und da würde ich jetzt da nicht davon weggehen eigentlich. Ja, unter der Voraussetzung, dass man halt die Affenklasse aus dem Dschungel heraus hat.
Ja, genau, genau. Und Probleme, sehr guter Punkt, oder Dinge, die das problematisch macht, sind so Sachen wie Vererbung. Das ist sowieso ein Konzept, das gehört verbrannt und zum Teufel geschickt, Weil nur Blödsinn dabei rauskommt.
Und mit Web Components ist es sogar Pflicht, dass wir das so machen.
Es ist mir unbeschreiblich.
Das kann ich dir genau sagen, weil da deine Klasse mit etwas interagieren muss, was keine Klasse ist.

[55:06] Und da wird im Prinzip das Adapter-Pattern hier aus den Design-Patterns hergenommen, wo du etwas schreibst, was aussieht wie Klasse A, Extents B, weil B gar keine Klasse ist, kann unter der Haube irgendwelche Magie hergestellt werden, die dafür sorgt, dass du die User Experience einer Extension von HTML-Element hast.
Ja, okay, das stimmt. Ich hätte einen anderen Grund genannt, und zwar der Grund, dass in JavaScript prinzipiell keine Interfaces existieren und du irgendwie das Ding als etwas deklarieren musst. Ich weiß gar nicht, ob es möglich ist, dass du HTML-Element irgendwie nachstellst und dann funktioniert das mit einer registrierten Web-Komponente oder ob du wirklich einfach das extenden muss und ob die Prototypechain existieren muss, damit der Browser da alles solche akzeptiert. Ja Prototypechain und du hast halt auch so Dinge wie so die Lifecycle-Callbacks, so AttributeChanged und so und vor allen Dingen auch Connected und Disconnected, wo... Die gehen in den VFQ rein, gell? Nicht nur das, die werden halt sozusagen auf einer... Also du hast so ein Connected-Callback, den schreibst du als Methode in deine Cluster, aber der landet halt nicht in dem Sinne auf dem Prototype.
Und damit passiert irgendwelche andere Krempe.
Ja, das stimmt.

[56:18] So, aber das ist jetzt ein isoliertes Detailproblem. Es ist einfach nur so, da kann ich die Entscheidung verstehen, dass man sagt, Class HTML, Class MyHTMLElement exsents HTMLElement, weil das fühlt sich halt so, wenn man es oberflächlich betrachtet oder halt eben im Alltag nicht zu genau hinschaut, so an, als würde das ohne weiteres so funktionieren.
Es ist ja sehr sprechend, du weißt sofort, dass es ein Web-Component ist.
Und niemand muss diese ganzen Details wirklich wissen mit dem Connected Callback, außer wenn man halt eben was debuggt und dann kann man es halt eben nachlesen und dann weiß man halt eben auch Bescheid.
Ja, das stimmt.
Das passt schon. Also das ist halt eben das Problem. Wir arbeiten hier halt eben mit einem Turm von Legacy-Software im Web wie auch anderswo.
Und wir arbeiten halt letztlich auch mit der Legacy-Software in den Hirnen der diversen Entwicklerinnen und Entwickler, die halt irgendwie versuchen müssen unter im Idealfall noch extremen Zeitdruck Frameworks, die sich irgendwie alle zwei Tage updaten und irgendwelche kryptischen Fehlermeldungen irgendwie was zum Funktionieren zu bringen.

[57:16] Das ist halt notwendigerweise was, wo nichts Optimales bei rauskommt. Ja, das stimmt.
Und deswegen werde ich einfach zunehmend altersmilde, wo ich mir halt eben so die Codebase aufmache.
Und sofern mir da jetzt nicht irgendwie Satan persönlich erscheint, frage ich mich halt eben, ist das irgendwie vertretbar?
Wie muss man das irgendwie einsortieren, wenn man jetzt so eine To-Do-Liste des Refactorings machen muss?
Wo sortiere ich das ein?
Aber da sind wir wieder bei einem wunderschönen Punkt. Du hast gesagt, die To-Do-Liste des Refactorings.
Das ist ja eine herrliche Überleitung zu dem, wo wir eigentlich gestartet haben.
Wenn ich jetzt eine To-Do-Liste des Refactorings mache für eine JavaScript-Schrägstrich-TypeScript-Applikation, dann denke ich mir, schaut die anders aus, als wie die, die jetzt gerade auf Refactoring-Guru drauf ist.
Da sind Dinge drinnen, die sind vielleicht ein bisschen konkreter, da sind Dinge drinnen, die machen vielleicht Nutzen von JavaScript-eigenen Eigenschaften wie Funktion ist ein Objekt, Funktion ist ein Wert, dass du Closures schreiben kannst, etc.
Lauter Dinge, die halt nicht so im klassischen Refactoring vorhanden sind, die aber sehr, sehr gute Resultate liefern. Wo ich wieder an dem Punkt bin, es gibt einfach Sprachmittel, die in gewissen Dingen besser funktionieren oder in gewissen Dingen dir mehr Möglichkeiten bieten, die wir promoten sollen. Und das ist das Problem, was ich mit der Refactoring-Kuro-Seite habe, die ist halt einfach.

[58:35] Direkt vom Buch in TypeScript übertragen. Aber du kannst das Gegenteil von den Patterns nicht gut promoten, weil das Gegenteil von den Patterns ist halt, lass es halt sein und nimm dieses Ding, was ohnehin schon da ist. Ich will nicht das Gegenteil von Pattern promoten, ich will nur das Pattern auf eine andere Art promoten. Okay. Und das ist eben das Ding, also wieder der Decorator. Der Decorator muss nicht dieses Klassenkonstrukt sein.
Der Decorator kann eine Decorator, tatsächlich ein Decorator sein, bis für eine Klasse in JavaScript existiert oder eine decorator Funktion. Wo waren wir noch, die factory muss nicht dieses Klassenkonstrukt sein, das kann einfach eine Funktion sein, die a plain old JavaScript Object zurückgibt. Ist schon eine Factory. Ist das Pattern schon so angewendet. Und witzigerweise, der Adapter muss kein Adapter sein, der kann einfach eine abgeleitete Klasse sein, wie wir errührt haben. Da gibt es Sprachmittel, die funktionieren besser als dieses Konstrukt an Codes, das du schreibst. Nur um das Pattern zu wissen.
Ist aber echt eine, sagen wir mal so, wenn ich jetzt mal meinen Sales-Hood aufsetze, hast du halt echt einen schwierigeren Stand, das zu promoten, als zu sagen, hier hast du ein konkretes Stück Software, das ja auch den Anschein erweckt, ein ernsthaftes Stück Software zu sein, weil ja alle Keywords da sind und alle Patterns und, weiß ich nicht, Doc-Comments und was nicht alles dagegen sind und dann.

[59:54] Komme ich um die Ecke und sage, ja du kannst aber auch für ein Singleton einfach Schleifklammer auf, Schleifklammer zu machen oder du kannst einfach sagen, ja leite halt die Klasse habt, dann hast du auch einen Adapter. Das ist, sagen wir mal...
Du hast halt so im Wettbewerb der Ideen, du kannst ja keine Diagramme zumalen.
Ja, das ist genau mein Problem. Jetzt sind wir an dem Punkt, wo ich bin, weil wie verkaufe ich das meinen 500 bis 700 Entwicklerinnen und Entwicklern?

[1:00:18] Das, was Fowler und Gamma in den letzten 20 bis 30 Jahren geschrieben haben, in Bücher verfasst haben, Diagramme geschrieben haben, eigentlich alles nicht ganz so gut ist.
Und ja, also das ist halt der krasse Punkt. Wie promotet man Vereinfachung oder idiomatisches Javascript, das im gleichen Tenor mitschwingt, wie die Design-Patterns?
Ich glaube nicht, dass das geht. Also ich glaube, dass sozusagen, wenn du die Leute hast und du die auf einem Kompetenzniveau hast, wo sie das sozusagen schätzen können, weil wenn du irgendjemandem sagst, du kannst seine Singleton-Klasse in die Tonne treten, wenn du einfach zwei Tasten drückst.
Das ist ja erst mal sozusagen relativ, sagen wir mal, einfach die Leute davon zu überzeugen, dass das wahrscheinlich die bessere Wahl ist. Wenn du halt auch demonstrieren kannst und resonieren kannst, dass das irgendwie alles ohne weiteres geht. Aber du kämpfst halt eben an gegen die Prior Art. Wenn du jetzt irgendwie sieben Leute auf der Straße fragst, hey, was ist ein Singleton?
Okay, dann werden dir wahrscheinlich alle sieben fragen, ob du jetzt irgendwie für eine Dating-App Aber wenn du jetzt auf einer Entwicklerkonferenz bist und die fragst, dann fragst du nach Singletons.

[1:01:31] Da wird halt, auch wenn es die nerdigste JavaScript-Konferenz ist, nicht irgendwer sagen, keine Ahnung, das ist halt einfach ein Objekt, das da im globalen Scope rumhängt und alle greifen drauf zu oder irgendwie sowas.
Sondern der Begriff Singleton ist assoziiert mit einer konkreten Implementierung, nämlich so einem Klassengewürschtel, was halt auf diese Historie mit den ganzen Büchern, die du erwähnt hast, zurückzuführen ist.
Aber es hat halt leider diesen Begriff verbrannt.
Bedeutet halt eben auch, wenn jemand da weiß, aha, ich brauche eine Factory, weil das sozusagen der Use Case ist, dann fängt man sozusagen schon an, sich auf eine Bahn zu begeben, wo man hinterher bei einer Implementierung landet, wenngleich es was Allgemeineres gäbe.
Und da bin ich mir aber nicht einmal ganz so sicher, muss ich ganz ehrlich sagen.
Weil, frag jemanden auf einer Entwicklerkonferenz, was ist ein Decorator?

[1:02:20] Ja, okay, stimmt. Und da kriegst du vielleicht unterschiedliche Antworten.
Die einen verstehen den Klassendecorator, die anderen verstehen das Pattern.
Und so populär wie Decorator jetzt in den letzten 20 Jahren waren, wo ja dieses, und das ist ja das Schöne, dieses Pattern ist zum Sprachfeature geworden.
Aber Anno 99, über die Annotations und nachher auch in C Sharp und anderen Sprachen, ist NN aus.
Aus der Entwicklung entstanden, das Entwurfsmuster zum Sprachfeature geworden ist.
Finde ich eine wunderschöne Geschichte.
Existiert seit über 20 Jahren. Ist wahrscheinlich mehr in den Köpfen drinnen, als wir das von Gamma.
Da bin ich echt gespannt, was da für Antworten drinnen sind.
Egal auf welcher Konferenz. Das kann eine Javascript-Konferenz sein, die GOTO oder NDC sein.
Da bin ich echt interessiert, was da für Antworten kommen.

[1:03:10] Es heißt nicht zufällig beides Decorator. Das stimmt. Aber trotzdem glaube ich, ist es einfacher den Leuten mehr zu verkaufen als den Leuten weniger zu verkaufen?
Das ist es. Dann mache ich jetzt mein eigenes Refactoring Buch oder mein eigenes Design Patterns Buch und mache einfach zehn weitere dazu. Dann habe ich schon mehr verkauft, mache aber nur halb so viel Content, weil alles viel einfacher ist. Ja, du könntest das ja so New Age mäßig aufziehen.
Du machst nicht das Buch Design Pattern, sondern du machst das Buch Design Pattern Detox.
Ja, Detox ist immer gut. Dann könnte das funktionieren. Ne, aber ich meine, so ein bisschen so die, da sehe ich halt so das Problem.
Du kannst halt relativ einfach den Leuten ein Produkt verkaufen und sagen, nimm dieses Ding und das löst deine Probleme und nicht nimm dieses Ding weg und das löst deine Probleme.
Das ist halt einfach inhärent, glaube ich, schwieriger, wobei dann halt eben natürlich auch, glaube ich nicht umhinkommen, uns die Frage zu stellen, ob so ein Ding wie so ein Web Frontend Framework, Ob das ein Design-Pattern ist?
Ha, mhm.

[1:04:14] Das hat mich nämlich gefragt, als ich hier auf diese Seite rumgescrollt bin und darüber nachgedacht habe, was ich dich so fragen könnte.
Ist React ein Design-Pattern?
Nee, oder nutzt React zum Beispiel das Component-Design-Pattern?
Was ist das für ein Design-Pattern? Ich weiß jetzt nicht einmal, ob das überhaupt existiert.
Nein, es existiert eh nicht, aber das habe ich jetzt gerade erfunden.
Diese Art, Komponenten zu schreiben, wie es auch Fugue macht und jetzt auch Angular macht oder Solid oder Svelte oder was auch immer, eben diese Kombination von irgendeinem generierten Ton, egal wie der generiert wird, ob das über JSX generiert wird oder über Template-Sprache, dazu verbunden irgendwie State Management und dazu verbunden irgendwie ein Styling. Und das kann, wie das jetzt ausgedrückt wird, ist ins Weltall anders wie in Vue, wie in React, wie in Angular, aber dass du nachher mehrere, unter Anführungszeichen, Instanzen davon haben kannst und die miteinander verschakteln kannst übers Hintergrund.

[1:05:24] Ist das nicht auch ein Pattern? Ja, weiß ich nicht. Ich denke halt eben bei so was wie React, wo ich halt eben so JSX-Code schreibe, ist das nicht eine sehr, sehr umständliche Art und Weise, einen Builder-Pattern umzusetzen, so ein bisschen?
Ah, du hast wieder recht, ja. Die Alternative ist ja buchstäblich imperative Objektorientierung.
Document, create element, div, div, class, list, add usw.
Versus ich schreibe diese seltsame Syntax rein.
Das ist dann jetzt ja irgendwie, also zumindest riecht das für mich auch nach einer Umformatierung dieses User Interfaces, das ich halt als Entwicklerin dann wahrnehme.
Und dann ist halt die Frage, ist so was ein Design-Pattern?

[1:06:06] Und hat das auch so diesen infektiösen Charakter, dass das irgendwie so nicht einfach nur ein Werkzeug ist, um ein spezifisches Problem zu lösen, sondern ist das so etwas, Ich bin der eine Weg, das zu machen, TM, nutze mich und das führt dich zur Glückseligkeit.
Ja, du erinnerst mich gerade an eine fantastische andere Ressource, die wir vielleicht promoten sollten.
Und zwar die Seite heißt patterns.dev und die ist für UI-Entwicklerinnen und UI-Entwickler, in der Dinge beschrieben werden, wie zum Beispiel das Container-Presentational-Pattern, wo du eben sagst, hey, es gibt React-Komponenten, oder generell Komponenten, in einem Frontend-Framework, die dazu da sind, tatsächlich etwas anzuzeigen, und andere Komponenten, die nur dazu da sind, um irgendwie Verhalten draufzulegen.
Und das ist eines, das funktioniert unabhängig von der Art, wie wir Komponenten schreiben, sowohl in template-basiert Angular oder jxcx-basiert React.

[1:07:22] Genau, was ich dann da noch, das Hider Order Component Pattern, das Render Props Pattern, das Hooks Pattern, also da sind einige Dinge drinnen.
Also anscheinend, merke ich gerade, für UI-Entwicklung hat schon jemand probiert, dass es dort eine andere Ressource gibt, die andere Dinge versuchen herauszustreichen.
Ich bin jetzt gerade zum ersten Mal auf patterns.dev gegangen, aber weil ich natürlich komisch im Kopf bin, habe ich direkt mal Ctrl-F gemacht und nach Singleton gesucht.
Der ist eh drinnen, ne?
Ist drinnen, mit Klasse. Mit Klasse, wirklich? Jo. Ha, ha, ha, es geht einfacher.
Ja, das erklären sie auch, aber dazu musst du ganz ans Ende scrollen.
Ah, das erklären sie oder was? Ja, ja, wenn du im letzten Drittel des Textes bist.
Ja, wirklich, ah. Da steht jetzt.
The common use case for a singleton is to have some sort of global state throughout your application.

[1:08:15] Having multiple parts of your codebase rely on the same mutable object can lead to unexpected behavior. Genau, ja.
So, und jetzt haben wir hier dieses Pattern.dev. Da steht ja, wenn du drauf gehst, direkt, was das alles für Leute sind, die das gemacht haben.
Die würde ich jetzt ja mal nicht in den Formenkreis der Hohlbratze reinrollen.
Die wissen ja, was sie tun. Die sind super schlau. Und selbst die sehen sich anscheinend gezwungen, die Singleton-Klassen zu verkaufen.
Also, was ist diese Wirkmächtigkeit? Was ist das für ein komischer Gehirnvirus, der dieses Ding, das ja einfach im Web-Kontext offensichtlich überhaupt keinen Anwendungsfall hat, dass das einfach nicht mal tot zu kriegen ist, selbst wenn die schlauesten Leute auf diesem Planeten diese Webseite betreiben. Ich finde das extrem faszinierend. Wieso kriegt man diese Idee nicht wieder da in die Zahnpasta-Tube rein?
Ja, spannend. Das ist mir halt unbegreiflich. Und ich glaube, das liegt halt tatsächlich daran, dass du inhärent Schwierigkeiten hast, den Leuten ein weniger zu verkaufen.

[1:09:17] Es ist halt wirklich einfacher, Werbung dafür zu machen. Nimm dieses Produkt, kaufe es oder lad es runter bei Open Source, verwende das und dann wird alles besser.
Ich glaube, das ist einfach fundamental ein Pitch, der halt echt extrem schwer zu schlagen ist.
Ich hätte jetzt gehofft, wir können die Diskussion, mit einer optimistischen Stimmung beenden, aber gerade das Singen nach Patternstaff macht mich gerade persönlich fertig.
Sorry, aber ich will ja gar nicht pessimistisch sein, aber die Frage, die du ja gestellt hattest, die da hinkommt, ist so, wie kannst du jetzt in deiner Rolle, so als der Advokat in deiner Firma oder meine Wenigkeit, so als der Söldner, der da ungefähr das gleiche auf kleinerer Ebene macht, wie geht man da ran?
Und ich glaube halt, das Wichtige ist halt, wenn man solche Dinge wie halt diese extrem ausgefeilten OOP-Paradigmen, die halt irgendwelche Nachteile irgendwo drin haben.
Also wir haben halt einen Pluspunkt auf unserer Seite, nämlich, dass wir Recht haben.
Es geht halt offensichtlich einfacher. Das ist klar, das kannst du demonstrieren.
Aber was halt eben, glaube ich, hilft, ist sozusagen für unsere persönliche, unserer beider Herangehensweise an das Problem, ist, dass wir die Größe der Aufgabe, der wir da gegenüberstehen, erkennen und ernst nehmen.

[1:10:39] Und dass wir hier wirklich sagen, okay, ich habe hier den besseren Weg, aber ich befinde mich hier in der Position von Goliath und muss jetzt Singleton, nee, umgekehrt, ich bin in der Position von David und muss Singleton und Goliath irgendwie platt machen und halt eben dann auch sagen, Das ist jetzt ein Kampf, vielleicht nicht gerade gegen die Windmühlen, aber definitiv gegen einen Gegner mit einem Marketingvorteil.
Und dann kann man das ja sozusagen sich auch einfach vergegenwärtigen und das hilft dann ja, wie du die Dinge framest, wie du die Dinge herangehst und natürlich auch, wenn du irgendwie jetzt sagst, okay, Problem identifiziert, das muss besser werden, wie hart du die Leute dann rannimmst.
Also wie groß sind die Schritte, die du da jetzt dann sozusagen empfiehlst, die gegangen werden und mit welchen Mitteln demonstrierst du, dass es besser werden könnte und wie moderierst du das so?
Aber ich glaub einfach, der Umstand, dass du in dem Fall, der du da für die einfacheren Pattern wirbst, dass du recht hast, ist ein großer Vorteil.
Aber trotzdem heißt das nicht, dass du notwendigerweise automatisch gewinnst.
Weil der Gegner ist mächtig und stark, und der hat halt ganz viel Mindshare.
Ja.

[1:11:43] Ja, dann muss ich wahrscheinlich mein Marketingdepartment ein bisschen aufhübschen. Und ...
Versuchen einfach besser zu verkaufen. Also mir gefällt eigentlich die Idee, die ich vorhin so schwachsinnigerweise rausgehauen habe, irgendwie so mit dem Begriff Detox oder so.
Das ist Blödsinn, aber zumindest wissen die Leute, was damit gemeint ist.
Du besetzt damit so eine gewisse Erwartungshaltung. Die Erwartungshaltung von mein tolles neues Single-Page-Application-Framework.
Die Erwartungshaltung ist. Ich benutze das und dann bin ich hip und cool und alles wird viel besser.
Und du kannst, du musst dann halt eben, wenn du so in der Marketing-Denke drin bist, halt eben auch wirklich sagen, was kann ich mir so klauen, was kann ich mir da so aneignen? Ich meine, wenn Patterns.dev sich das Singleton aneignet, dann können wir das auch mit Framework-Detox machen, Ja, ja.
Reakt-Entziehungskur, irgendwie sowas. Okay, Entziehungskur.
Ja, das wäre gerade an den Wogen.

[1:12:44] Weiß ich nicht, ich mache Mastodon auf und irgendwie alle so, boo, React ist doof.
Ja, Mastodon ist sehr anti-React. Teilweise...
Teilweise ist mir das auch sogar schon zu viel, weil es ist schlussendlich doch noch auch wieder ein Tool wie jedes andere.
Ich denke auch, dass es definitiv Use Cases gibt. Also ich habe da was, was ich mit Projekt baue, das wäre ja auch nicht ohne bauen, weil das wäre Wahnsinn.
Aber das meiste, was ich bauen würde, würde ich ohne machen, weil es halt Käse. Aber das Problem ist halt Nuance.
Es ist auch halt so ein Ding, das halt echt schwer zu verkaufen ist.
Du kannst halt schlecht hingehen und sagen, so hier, ich bin jetzt der tolle Developer Influencer mit meinem YouTube TikTok oder irgendwie sowas.
Sowas und ich argumentiere pro manchmal ist react gut manchmal willst du html machen und außerdem ist angular eigentlich auch nicht gar nicht so schlecht ja genau wenn du irgendwie sagen kannst die fünf besten react hacks oder diese sieben gründe warum du niemals angular verwenden solltest, die haben es halt leichter. Es ist halt auch total langweilig wenn du auf jede hot take diskussion mit it depends antwortest, weil es ist zwar die ehrlichste antwort und die Das ist die richtigste Antwort.
Das ist der Punkt. Du hast halt recht, aber du darfst nicht davon ausgehen, dass nur weil du recht hast, automatisch die alle zuhören und alle das machen, was du sagst.
So läuft das. Das war zum Beispiel jetzt, vielleicht kurz zum Abschluss, dass wir ein bisschen Typescript reinbekommen, aber ich habe jetzt gemerkt, dass auf YouTube eine hitzige Diskussion entstanden ist über Return Types.

[1:14:12] Ob man die jetzt schreiben soll oder nicht.
What? Warum diskutieren wir das? Warum? Warum ist das gerade ein Thema, bei dem mehrere Leute sehr aufwendige Videos produzieren und eine Kette an Diskussionen entsteht, wo du von A nach B nach C hüpfst und du eine ganze Woche jeden Tag ein 10-Minuten-Video schauen kannst? Warum passiert es, weil es halt gut verkauft ist. Es ist in der Realität einfach total abhängig, ob es jetzt Sinn ergibt oder nicht. Es gibt Situationen, da macht es Sinn, es gibt Situationen, da macht es keinen Sinn.
Und ihr entscheidet immer je nachdem.

[1:14:56] Wo macht es denn Sinn, aber es verkauft sich halt nicht und das haben die, die haben 50.000 Views und ich, hey, pfff.
Das, was du gerade beschrieben hast, ist definitiv, also würde ich definitiv exakt so unterschreiben mit Brief und Siegel, wenn du jetzt aber sagen würdest, Peter, ich will darüber ein YouTube-Video machen, also mein Content-Berater würde dir da ein anderes, ein anderes Framing empfehlen.
Ich mache den It-Depends-Development-YouTube-Channel.
Meine Meinung ist, dass es keine extreme Meinung gibt.
Genau, it depends. Und dann machen wir das so, dann hast du noch so eine schöne Beleuchtung.
Du setzt dich in so einen Sessel, du hast ein Buch vor dir und dann wird das nicht so ein Yo YouTube, was geht ab? Hier ist wieder 7 Projekttipps für deine tägliche Arbeit.
Sondern du sitzt dann da und machst mehr so die Märchenerzähler.
Ja genau, also ich schlage ein Buch auf, dann während ich das Buch aufschlage, wird so ein Einspieler kommen von dem einen Video mit dem Hot-Tag und ich mache wieder zu und sage Pants und dann ist das Video vorbei. Brauche ich noch einmal machen, mein Tag ist einmal aufgenommen und den recycle ich dann für Video zu Video zu Video. Das ist das Ding. Das könnte aber sogar funktionieren. Das ist Content.

[1:16:08] Das ist halt genau auf der Schnittstelle zwischen irgendwie so TikTok-konformem Kurzvideokontent.
Es ist ja quasi ein Videomeme gleichsam.
Das ist ja so, als würde ich einfach irgendwie so, weiß ich nicht, Wojak irgendwo reinpasten oder irgendwie so ein bisschen PHP-Code oder irgendwie sowas.
Weißt du, Stefan, wenn das irgendwann mal mit dem Programmieren bei uns beiden nicht mehr läuft, dann machen wir Contentronic.
Du bist sehr gnädig, weil du hast gesagt, dass das bei uns je läuft mit dem Programmieren.
Da bin ich mir eigentlich nie so sicher.
Ja, ich mir eigentlich auch nicht so richtig. Ich würde sagen, es läuft ausreichend gut. Es ist vertretbar.

[1:16:52] Okay, alles klar. Dann haben wir doch wieder eine optimistische Note am Ende gefunden. Das finde ich gut.
Gar sowieso. Ich meine, wir müssen es halt nur durchsetzen. nur durchsetzen. Ich möchte jetzt noch eine klassische YouTube-Sache machen. Ich möchte sagen, hey, wenn Leute sich jetzt wirklich die letzte Stunde angehört haben, wie wir versuchen, einen Weg raus aus dieser Diskussion zu finden, mich würde sehr stark interessieren, ob ihr irgendwelche Ressourcen habt, irgendwelche Guides, Blogbeiträge, Dinge, die halt diesen pragmatischen Weg, JavaScript oder TypeScript zu entwickeln, promoten. Also einfach nur diesen, hey, hinterfrage mal, was du da machen möchtest, nutze das richtige Werkzeug. Es gibt viele Werkzeuge. Ich wäre sehr, sehr dankbar, wenn es das geben würde, weil ich halt wirklich irgendwie Stütze brauche, um das beizubringen. Oder wenn Sie andere Meinungen habt, wo Sie sagen, hey, das Singleton in zwei Ageschwungen kann man, das funktioniert halt einfach nicht so, weil erleuchtet uns. Ich bin sehr gespannt, diese Diskussion weiterzuführen.
Ja, das unterschreibe ich. Schreibt uns auf Social Media an, entweder auf dem ProReact oder oder auf dem Pro, dem Anti-React-Netzwerk.
Hüpft in unserem Community-Slack vorbei.
Genau.
Und lasst was von euch hören.

[1:18:08] Gut. Wunderbar, dann machen wir doch mal den Deckel drauf. Stefan, es war mir wie immer ein Vergnügen, dafür stehe ich gerne früh auf.
Ja, danke schön. Ja, es ist super, dass wir die Gelegenheit haben, auch zu anderen Seiten aufzuzeichnen, dann komme ich wahrscheinlich auch wieder öfter ins Boot und das macht mir doch weiterhin sehr viel Spaß.

[1:18:24] Das ist doch wunderbar. Dann danken wir fürs Zuhören und hören uns irgendwann nächste Woche wahrscheinlich wieder.
Weil wir aber hier in komischem Scheduling aufnehmen, haben wir exakt gar keine Ahnung, was nächste Woche auf dem Programm stehen wird.
Deswegen, lasst euch überraschen. Danke fürs Zuhören, bis zum nächsten Mal. Tschüssi!

[1:18:43] Music.