Transcript

[0:00] Hallo und herzlich willkommen bei Working Draft Revision 600.
Diese Revision ist eine ganz besondere, denn wir haben sie live und mit vielen, vielen, vielen Gästen, Teilnehmern und Teilnehmerinnen aufgenommen.
Zusammen haben wir drei Themenblöcke durchgenommen, die wir in einer Art Fishbowl Discussion nahtlos ineinander haben übergehen lassen.
Zuerst handelt es sich um das Thema der Web Components. Im Anschluss haben wir gesprochen über den Frontend-Dschungel 2024, aber auch generell und wie wir uns dort zurechtfinden, was unsere Hoffnungen, Befürchtungen und Freuden darüber sind.
Und abschließend besprechen wir das Thema der Designsysteme.
Wir wünschen euch ganz viel Spaß bei dieser besonderen, etwas längeren, mit vielen Gästen besprochenen Revision.

[0:50] Music.

Revision 600: Fishbowl-Diskussion

https://workingdraft.de/600/

[1:15] Generell ist es ja ganz sicher geplant als Fishbowl-Diskussion.
Eine Fishbowl-Diskussion bedeutet grundsätzlich, dass wir hier in einer Gruppe von 10, 20, 30, 40, 50, 100 Leuten zusammensitzen können, aber es gibt aktiv nur ein paar bestimmte Personen im inneren Kreis, die zusammensprechen können.
Also normalerweise wäre es so ein Stuhlkreis, wir sind remote, bei uns wird es kein Kreis, sondern wahrscheinlich vier Fenster mit einem grünen Rahmen drumherum.

[1:44] Der Sinn davon ist, dass Gruppendynamiken oft sonst getrieben werden von Leuten, die dominanter sprechen als andere.
Also ich kenne das von vielen Situationen, dass manche Leute sprechen immer sofort, haben schon sehr viele Gedanken dabei, haben vielleicht auch schon sehr viele Erfahrungen.
Und andere Personen kommen dann einfach nicht zum Reden, weil sie vielleicht erst noch kurz mal die Frage in ihrem Kopf artikulieren möchten und schon wieder ist jemand anders am Plappern.
Dieses Problem möchte die Fishbowl-Diskussion umgehen, dass es immer nur vier Personen gibt, die sprechen können.

[2:18] Und mit der Methode des freien Stuhls heißt es, dass man immer darauf achtet, dass quasi drei aktive Sprecher, Sprecherinnen gerade am Start sind und es immer so eine Art Springer-Sitz gibt und es dann immer durchgemischt wird.
Das heißt, sobald jetzt eine Person auch nichts mehr zu dem Thema gerade beizutragen hat, kann man auch einfach rausgehen, also hier jetzt mental rausgehen, rausgehen, nicht aus dem Raum rausgehen, nicht den Stuhl verlassen, sondern einfach sitzen bleiben und eine andere Person kann dann den Stuhl ergreifen, beziehungsweise hier das Mikro ergreifen.
Unser Host, unser Zoom-Host-Chef könnte und kann uns alle muten und kann uns auch alle entmuten.
Bei Zoom hier unten gibt es, glaube ich, hier diese Reaction mit Handheben.
Falls also jemand sagen möchte, ich möchte jetzt doch eigentlich mal so einen Stuhl ergreifen, könnte eine andere Person sich dann selbstständig muten, damit die andere Person sich entmuten kann.
Also, was ich gerade sagen wollte, nochmal...

[3:19] Wir könnten das steuern oder der Chef könnte das steuern oder wir sagen einfach, wir versuchen das mal ganz ohne manuell oder administrativ Leute entmuten und muten zu müssen, sondern wir finden ein Thema zusammen.
Dann melden sich schon mal die ersten vier Personen, die vielleicht drüber sprechen wollen.
Und sobald eine Person nicht mehr aktiv teilnehmen möchte, kann man sich muten und eine andere Person kann dann reinspringen und sich entmuten und sprechen.
Ich habe hier bei meinem Zoom zwei Fensterchen hier, wo ich glaube ich alle sehe. Wir testen das einfach mal.
Wir testen das einfach mal. Ich bin so ein Overthinker. Ich habe schon alles wieder 500 Mal überdenkt, ob das jetzt alles funktioniert oder nicht.

[4:04] Ja, genau. Ich wollte noch sagen, die Umfrage müssen wir gleich auch manuell machen, weil ich habe den Account hier vom Stefan.
Der sitzt aber gerade im Auto, scheint sich aber irgendwie parallel auch eingeloggt zu haben. Jetzt ist meine Umfrage weg.
Ich schiebe das jetzt auf den Stefan. Das heißt, wir machen das auch gleich einfach mit der Hand oder so.
Okay, cool. Dann würde ich sagen, voten wir mal, oder?
Die drei Themen, die wir wahrscheinlich in dieser Session gerade bekommen.
Ungefähr drei Stunden mit einer Pause und so.
Vielleicht kann ich noch einen Vorschlag machen zum Voting. Wir haben ja unten dieses Reaction-Feature.
Vielleicht können wir ja alle die Hand dort raisen. Weil es sind ja doch ein paar Leute, die vielleicht auch keinen Bock haben, die Kamera anzuschalten aus verschiedenen Gründen oder so.
Ja, der Alexander macht das hier schon kurz vor und andere vielleicht auch.
Kann ich auch einfach die Hand geben oder muss ich die Hand raisen?
Oh, gute Frage.

[5:05] Jetzt habe ich es gegettet. Ja, ich kann sie auch gerne einfach heben. Hi Jens.
Gerne einfach die Hand heben natürlich. Da hast du vollkommen recht.
Mein Englisch ist manchmal etwas tiefer drin. Ihr kennt das ja.
Das typische Hans-Denglisch. Aber ohne finde ich, wäre auch schade.
Der Hans hat heute noch gar nicht stabil gesagt.
Das ist mein absolutes neues Lieblingswort mit Hans zu Podcasten, ist wenn er das Wort stabil raushaut, als wäre man so 20-Jährige.
Entschuldigung, bitte. Ich versuche mich heute einmal an die deutschen Worte zu halten, aber es ist schwierig.

[5:46] Ja, dann sollen wir starten? Jo, ich versuche zu zählen. Ich habe hier meinen Stift und Papier. Okay, du zählst.
Gut, dann starten wir jetzt hier mit Genau, ich werde mich nicht melden.
Ich bin mit allem zufrieden.
Einsatz von KI beim Entwickeln und in Websites für NutzerInnen.
Da könnt ihr jetzt abstimmen, wenn ihr da Bock drauf habt.
Zwei, ne? Ja. Alright.
Dann haben wir Zugänglichkeit und Inklusivität im Web, also letztendlich Accessibility, Barrierenfreiheit.

[6:23] Oh, da geht's rund. Da geht's rund. Ich warte noch mal kurz, dann kann man sie noch. Es gibt mindestens acht. Acht, ja.
Genau. Hände wieder anraisen, bitte.
Dann Erwartungen an den Framework Jungle 2024. Vielleicht auch Bildtools und Co. Also dieses ganze Universum.
Ja. Da sind auch ein paar Leute dabei.
Mhm. Mhm.
Dann einmal Hände wieder runter, dann haben wir als nächstes Server-Site-Rendering versus Client-Site-Rendering versus vielleicht Hybrid.
Vier Stück? Fünf? Wer braucht schon Poi-Services?
Eben, das ist doch viel cooler so. Dann Design-Systems.
Ein sehr schönes Thema. Ah, da kommen noch, da passiert was noch. Darf man framen?
Oh, neun, oder? Neun? Ja.
Dann haben wir CSS-Neuerungen.

[7:45] Da haben wir... Winner, Winner. CSS-Dinner. Zehn.
Genau, dann eher Architektur, aber auch CSS-Component-Based CSS versus Utility-First-CSS.
Lieber nicht. Also, wer möchte über Table schimpfen? Hast du schimpfen? Quatsch, Quatsch.
Wer möchte es loben? Ich erspare es dir, Vanessa.

[8:16] Nehme ich das nicht persönlich. Ich mache nur mein Geld damit. Stimmt.
Du hast die Zahl, hast du? Acht oder neun, ich glaube, ich habe jetzt gerade neun auch verbessert.
Okay, aber nicht hier die Zahlen verfälschen.
Dann haben wir Web Components, die mussten rein, weil die sind ja irgendwie gerade sehr en vogue, was so Blogposts und Co. angeht.
Elf. oder Peter hat auch die Hand gehoben der hat hier seine falsche Mutthand geraced, genau und dann könnten wir noch diskutieren über die Zukunft der Browserlandschaft also wie geht es weiter mit Chrome, Safari und Firefox und den anderen Browsern, Ich glaube wir reden über alle Themen, oder?
Ja, die werden ja alle irgendwie einfließen Wir müssen nur gucken, dass bestimmte Themen nicht gekapert werden.
Das wäre nicht völlig abdriftend. Also nicht wie bei uns in den Podcasts eigentlich.
Okay. Wenn wir das mal so machen wie bei uns in den Podcasts, dann sind wir hier noch ganz schön lange.

[9:29] Das gibt's kein Problem. Muss ich morgen freinehmen.

[9:34] Ja, wir haben Zeit. Wobei, nee, um 18 Uhr muss ich tatsächlich, werde ich wieder eingesammelt hier von der Familie.
Gegen halb neun wollte ich Abendessen.
Halb neun? Ja, dann kriegst du dann den Host. Wenn ich dann weg bin.
Ob wir, wo wir sind, das vorne über der Länge schlagen können.
Ja, das ist schon hart. Das schafft man, glaube ich, nicht. Was machen die so im Schnitt?
Die hauen schon immer ganz schöne Brecher raus. Ja, Chef war damals fast zwei Stunden.
Fast drei Stunden, das kriegen wir ja hin. Und ich hoffe ja immer noch darauf, dass es das ganze Transkript als Buch veröffentlicht gibt, weil es zu anstrengend ist, das alle zwei Tage neu zu lesen, neu nachzuhören.
Vielleicht kann das ja hier Chat, vielleicht, wenn wir hier über das KI-Thema sprechen, dann könnten wir das doch nutzen, um das alles zusammenzufassen für uns.
So, fasse diese 3-Stunden-Folge in 2 Sätzen zusammen. Was muss ich tun?
Okay, ja, dann starten wir mit, womit starten wir denn? Dann mit was?

Web Components

[10:42] Web Components, oder? Wir starten mit Web Components.
Ja, dann. Stabil. Da ist es dazu.
Okay. Vielleicht können wir mit der Frage anfangen, wer arbeitet denn mit Web Components?
Ich kann sagen, dass ich sehr interessiert bin, aber nicht mit denen arbeite.

[11:01] Ich habe gesehen, Marco arbeitet damit. Genau. Paul klebt auf die Hand. Ja.
Genau. Dann wäre vielleicht die Eingangsfrage, wie lange macht ihr das schon?
Also seid ihr da schon auf der Schiene schon relativ lange unterwegs? Ja.
Wir arbeiten seit einem Jahr damit in einem neuen Projekt, also haben quasi auf der grünen Wiese angefangen und alles ausschließlich mit Web-Components gebaut.
Und Falk, wie lange machst du schon oder macht ihr ein Team?
Bei mir eigentlich erst zwei, drei Wochen. Also ich habe gerade ein Projekt, wo ich was bei einem Kunden einbinden muss, was halt den Rest nicht beeinflusst.
Und das ist natürlich mit Shadow-Mode und Co. besser. Mhm.
Okay. Genau. Sonst arbeitet noch keiner, zumindest regelmäßig, mit Web Components wahrscheinlich rumexperimentieren.
Das haben schon mehr Leute gemacht.

[12:03] Insbesondere ein Herr Kröner. Ja, ich wollte es gerade sagen.
Also, wenn man rumexperimentieren, als die Arbeit rubrizieren darf, dann kann man bei mir da auch Ja sagen.
Genau. Hast du denn viele, du berätst ja ab und zu auch Kunden, also du bist ja nicht nur Erklärbär, sondern gehst ja auch in Unternehmen rein und schilfst ein bisschen.
Hast du viele Kunden, die Web Components einsetzen oder wie würdest du das sagen?
Ich würde sagen, viele noch nicht. Die meisten, mit denen ich zu tun habe, sind so unterwegs wie du.
Also Awareness ist da, klingt auch ganz interessant, aber da ist man noch nicht sozusagen über den Hügel drüber gesprungen, dass man sagt, wir machen das jetzt teilweise auch aus den nachvollziehbaren Gründen, dass die ja in der Entwicklung, weiß ich nicht, verglichen mit so einer Angular-Komponente dann doch eher nicht trivial sind.
Das ist auf jeden Fall so mein Eindruck.
Fabian hat die Hand gehoben.

[12:59] Genau, also bei uns zum Beispiel ist es so, wir arbeiten jetzt seit einem halben Jahr oder so mit Web Components, aber bisher entwickeln wir keine selber, sondern wir setzen halt auf eine Library, die mit Web Components gebaut wurde, wir sind viel so im SAP-Umfeld und früher musste man halt um irgendwelche SAP-like Frontends zu bauen, deren ganzes JavaScript-Framework, QF5-Gedöns, alles von vorne bis hinten benutzen, und jetzt seit zwei Jahren haben die halt ihre Oberflächensachen als Web-Components und dann bist du halt vom Framework drunter unabhängig und kannst halt dir das Framework aussuchen, aber trotzdem die UI-Elemente, die von denen kommen, benutzen und das finde ich schon einen deutlichen Fortschritt, dass man da nicht mehr an deren Komplettpaket gebunden ist, sondern sich sein Stack so zusammenpuzzeln kann, wie man ihn braucht, aber, trotzdem die Komponenten von denen nutzen kann.
Das ist für uns, die die viel einsetzen, ein großer Schritt vorwärts auf jeden Fall.
Ja, klingt sinnvoll. John?

[13:59] Also ich arbeite auch ein bisschen mit Web-Components, mit Svelte zusammen.
Und was jetzt gerade so ein bisschen auf dem Schirm steht, weil ja da Google mit der Compilance und Ads ausschalten, wenn wir dann ein paar Kunden haben oder Probleme haben, sind wir überlegen, auch so ein bisschen einen Ad-Server aufzuziehen, wo dann halt nicht mit iFrames arbeitet, sondern mit Web-Components.
Das sind wir ein bisschen am rumtesten.

[14:29] Ja, mit Zwelt geht es ziemlich komfortabel.
Also Werbung ausspielen und die dann einsperren in Web-Components statt in iFrames oder was? Genau, das ist die Idee dahinter.
Performance gewinnt, weil beim iFrame natürlich immer das ganze Zeug da mitgeladen wird.
Ja, wobei ich hatte ja heute noch dieses eine Blogpost, was ich gelesen habe, geteilt, wo so ein Browser-Ingenieur sagt so, die Browser sind da auch echt gut drin, iFrames irgendwie schnell zu laden mittlerweile.
Genau. Aber ja, sinnvoll, das irgendwie auch so zu machen.
Dann der Alex. Jo, ich hatte direkt mal eine Frage an alle Leute, die Web-Komponenten regelmäßig nutzen.
Was ist, wurde es schon so ein bisschen mit beantwortet, welche welche Frameworks du nutzt, du nimmst ja ganz plain, nimmst ja Lids, nimmst ja zum Beispiel Angular, was dann zu Web-Components ausgeliefert wird, Zwelt wurde ja schon erwähnt und so weiter und so weiter.
Das wäre eigentlich ganz interessant, mal zu hören, weil ich hatte jetzt unterschiedliche Use-Cases, wo Leute sagen, ja, ich will mich nicht auf ein Framework verlassen, die Software soll gerade in der Industrie irgendwie x Jahre laufen, unabhängig, wie realistisch das ist, aber das wäre so die Idee.
Deswegen auf die Plattform setzen und dann aber kein Framework dafür nehmen.
Ja, würde mich interessieren, was so die Leute mit Erfahrung dazu sagen, mit Web-Components vor allem natürlich, erfahren wir ja alle.

[15:59] Naja, wenn es ewig halten soll und du dann nicht abhängig sein willst davon, ob irgendein HIO-Pi das noch unterstützt in drei Jahren, was willst du machen außer selber?
Richtig, richtig. Die Frage ist natürlich nur, dann kommt man an das Problem mit, dann bauen wir unser eigenes Framework basierend auf Web-Components und laufen in die gesamten Probleme, die eigentlich theoretisch andere Leute schon gelöst haben, müssen sie selber lösen.
Das ist halt die andere Kehrseite der Medaille. Das weiß ich nicht, weil ich glaube nicht, dass du in alle Probleme reinläufst, die alle anderen schon gelöst haben, weil wenn du jetzt wirklich irgendwie sagst, du machst das einigermaßen ein bisschen spezialisiert für deinen Use Case und generalisierst das Framework nur so weit, wie es generalisiert werden muss, dann ist, glaube ich, diese Aufgabe, ich baue mir das selber, nicht ganz so groß, als wenn du jetzt sagst, ich will jetzt irgendwie Angular zu Leibe rücken mit seinem Marktanteil und baue deswegen was, was alles kann, was die können.
Wenn du da einfach kleinere Brötchen backst, glaube ich, ist das gar nicht so unrealistisch.
Das ist ein guter Punkt, natürlich. Also klar, du musst ja kein vollumfängliches Framework à la Angular Vue React und so weiter bauen, das stimmt schon, aber die, üblichen Probleme, also gerade bei Web Components hört man ja viel so, ja, State Management, Templating und Co., die ja von Frameworks schon gelöst sind, muss man ja trotzdem irgendwie angehen, dass sie.

[17:08] Zumindest mit weniger Boilerplate vorankommt, wenn man das möchte.
Natürlich kann man sagen, gut, wir nehmen es so, wie es ist und beißen den sauren Apfel.
Nee, aber da könntest du ja tatsächlich hingehen und eher das über so eine Art Micro-Library lösen.
Also gerade für irgendwie Templating, ein virtuelles DOM, einfach so mit zum Beispiel Tag-Template-Literals.
Da gibt es ja mehr als eins, das das kann und da würde ich ja auch das Risiko, dass da dann irgendwann der einzige Maintainer von einem Bus überfahren wird, nicht ganz so groß einschätzen, weil da musst du vielleicht eines Tages die Library austauschen, vielleicht halt auch nicht, weil das ja möglicherweise ein endlich großes Problem ist, so Zeug auf dem Bildschirm darzustellen und selbst wenn, dann musst du halt einfach nur eins, eine Sache austauschen, nämlich den Rendering-Mechanismus, das wird dann wahrscheinlich nerven, aber es ist halt nicht irgendwie so, als würdest du jetzt eine Migration gleich, keine Ahnung, von React zu Angular oder sowas machen müssen, wo du wirklich im Prinzip alles in die Tonne treten willst.
Also, wenn man das alles einfach nur mal kleiner denkt und irgendwie ein bisschen spezialisierter denkt, dann ist das, glaube ich, alles weniger unrealistisch, als viele das so meinen.
Guter Input, ja, danke.

[18:07] Also vielleicht, um in die gleiche Richtung zu gehen, wir haben tatsächlich auch kein Framework verwendet, sondern nutzen alles oder haben alles mehr oder weniger selbst aufgebaut und haben eine große Basiskomponente, wo alle anderen Webkomponenten von ableiten.
Und die ist gar nicht so groß. Die managt den ganzen Lifecycle.
Natürlich zugeschnitten auf unseren Anwendungsfall.
Und vielleicht, um den mal ein bisschen zu skizzieren, Es geht da um so ein Payment-System.
Und der Kunde, für den wir das machen, der hat halt ganz viele Händler.
Und die Idee ist, dass die Händler das bei sich halt einbinden können, ohne großen Aufwand.
Und wir wissen natürlich nicht, womit die ihre Web-Anwendungen so bauen, ihr internes Portal.

[18:50] Und die sollen das natürlich auch entsprechend ihren Bedürfnissen stylen können.
Das heißt, wir arbeiten deswegen mit Custom Properties.
Das Problem, was wir da eher haben, ist, dass die Liste riesig wird, mit dem, was man da alles stylen kann.
Und das ist dann eher eine andere Herausforderung, aber vielleicht kommen wir da ja später bei dem CSS-Thema nochmal dazu.
Auf jeden Fall auch sehr spannend. Ja, klar, und dann ist natürlich Lightroom, Shadowdom, wo ist ja auch das Thema mit, du kannst ja nicht einfach dann Draft-Componente sagen, hier, ändere entsprechend die Styles, deswegen kann ich mir gut vorstellen.
Genau, aber eine Ergänzung noch, also wir haben zum Beispiel auch Charts, also irgendein Dashboard mit besonderen Widgets, und innerhalb der Komponenten, Und da nutzen wir dann tatsächlich so eine entsprechende Library.
Das bauen wir nicht alles selbst. Alles klar. Macht Sinn.

[19:39] Jens hat die Hand oben. Ja, im Prinzip geht meine Frage, glaube ich, in die gleiche Richtung, die wir gerade diskutiert haben.
Fabian hatte vorhin so nebenher gesagt, dass ja der Vorteil von Web Components ist, dass man Framework-unabhängig ist und man sich dann für ein Framework entscheiden kann, was man gerade so Bock hat.
Also ich übersetze Framework jetzt in React oder Vue jetzt mal für mich, vielleicht auch Svelte.
Dieses mit A, das ist, glaube ich, also für mich ist das, na egal.

[20:14] Aber die Frage ist, ist das wirklich so? Kann ich jetzt wirklich so eine Web-Component einfach in React reinschmeißen oder muss ich da jetzt nochmal ganz viel Konfigurationsarbeit leisten?
Denn also das Framework nimmt mir ja sehr viel mehr Arbeit ab, als so eine Web-Component mir abnehmen kann.
Die Web-Component ist ja erstmal nur dafür da, ein UI-Element zu realisieren und React oder Vue macht ja massig viel mehr.
Aber kann ich einfach so eine Web-Component nutzen? Ich kann mich nur noch an meine Vue-Zeiten erinnern. Da war halt schon das Template mit drin.
Kann ich da jetzt quasi einfach nur die Web-Component injecten und gut ist?
Oder muss ich noch was nacharbeiten?
Wenn das nicht geht, ist das ein Bug im Framework. Weil was du ja machst, ist ein neues HTML-Element erschaffen.
Und wenn die mit HTML nicht klarkommen als Web-Framework, kannst du denen daraus einen Strick drehen.

[21:11] Das beeindruckt die React-Leute bestimmt sehr, ja.

[21:15] Weiß ich nicht. Außerdem, außerdem, ich, boah. Musst du dann gleich immer gleich mit dem dicksten Kriminellen hier auch anrücken mit React. Ja, doch, weil ja sonst keiner auf mich hört, weißt du.
Es hört sich dann immer so an, als müssten wir dann anfangen, demnächst mit React zu arbeiten und keiner hört drauf, dass es vielleicht eine bessere Technik gäbe.
Und ich kann mich nur daran erinnern, es gibt so eine Web-Component-Seite, die darüber informiert, wer was kann.
Und da meine ich, wäre React jetzt nicht mit 100% dabei, sondern eher mit um die 90%.
Und im Zweifelsfall sind die 10%, die fehlen genau die Dinger, die mich interessieren. Also deswegen ist halt die Frage, ist das so easy?

[22:02] Also bei mir ist es jetzt so, ich hatte angefangen mit Lid, habe aber festgestellt, eigentlich brauche ich ja nur Basis-Web-Component ringsrum und dann in meiner Web-Component nutze ich aktuell Preact.
Also ich habe mir auch Padded View und so angeguckt, also ich will es halt zum einen klein halten und zum anderen wollte ich mir auch den Output angucken, also das Bundle, was rauskommt, dass da wirklich Nullabhängigkeit zu irgendwelchen DOM oder sowas ist.
Also ich will jetzt nicht, dass da irgendwie React im Global Scope registriert wird, weil die Web-Komponente soll ja später mal in einer anderen Webseite eingewertet werden.
Also bei mir ist es so, dass ich mit React aktuell da sehr gut fahre, auch wirklich kleine Bundles rausbekomme.
Und prinzipiell bist du aber in der Web-Komponent frei. Du hast dein Shadow DOM-Element und da rein kannst du jetzt mit Vue, React, was auch immer, deine Komponente rendern.

[22:47] Bei uns haben wir uns damals, also mit 12 Web-Components zu verwenden, habe ich jetzt nie irgendein Problem gehabt, auch bei größeren Libraries.
Und zum Schreiben haben wir uns damals fürs Welt entschieden, weil es halt ein Compiler ist.
Also ich kann halt meine Sachen schreiben und was dann auf der anderen Seite rauskommt, ist dann die Aufgabe vom Compiler.

[23:15] Und durch das hast du halt sehr viel weniger Boilerplate-Code.
Es gibt ja die lustigen Memes, Encounter in React, Encounter ins Welt, die Bekannten und jetzt gerade mit der Version 5, wo rauskommt, wird es dann nochmal einfach die ganzen Geschichten zu handeln, vom Speed her und das war eigentlich bei uns jetzt der Hauptgrund, dass wir das Welt verwenden, weil wir gesagt haben, ja, da habe ich gar keine, Library, wo ich quasi dann habe am Schluss, sondern es kompiliert man einfach den möglichst kleinen JavaScript-Code, wo ich dann da rauskriege und da haben wir eigentlich wirklich sehr gute Erfahrungen damit gemacht.

[23:58] Ich würde mal ganz kurz die Frage aufgreifen mit dem Thema React und Custom Elements in dem Fall, so ein Teil von Web Components, weil Web Components sind Custom Element, Shadow Root und Shadow DOM und das dritte war's, was ich vergessen habe.
Weiß bestimmt jemand. Genau, das ist tatsächlich React ist das einzige größere Framework, was halt keine 100% erzielt.
Eben das Problem mit Events und Data Handling, was ein bisschen mehr Aufwand erfordert, habe ich selber noch nicht gemacht, habe aber da schon in ein, zwei Talks Pain Points von anderen Leuten gehört, die das eben entsprechend genutzt haben.
Es ist aber machbar. Also, es erfordert halt mehr Aufwand.
Wenn man ein anderes Framework nutzt, hat man dementsprechend nicht, weil die halt damit ganz gut umgehen.
Man muss halt zum Teil sagen, ah, okay, zum Beispiel bei Vue hier, das ist ein Custom Element, interpretiert das mal bitte nicht als als View-Komponente in anderen Frameworks wahrscheinlich eh nicht einfach zu sagen, hey, das exkluden wir, dann ist gut, aber ansonsten sollte es ganz gut funktionieren.

[24:51] Genau. Vielleicht noch die Rand-Anmerkung, dass der Marvin ja heute auch dabei ist, der hier im Chat sich auch schon sehr gefreut hat über die Erwähnung von Preact und er arbeitet auch in Preact.
Also, genau.
Ja, Preact und Web Components ist eine Liebesgeschichte, oder? oder?
Ich kann vielleicht jetzt sagen, ich habe von einigen gehört, dass die gerne zusammen als Combi genutzt werden, gerade weil das React-Modell vielen vertraut ist und dann möchte man doch als Web-Component seinen Code ausliefern und dann ist das in React ein bisschen schwierig und da hilft dann Pract einfach, das zu bauen.
Ich finde Web-Components generell eigentlich sehr spannend einfach, weil das so ein bisschen auch so die Hoffnung ist, framework- übergreifend Komponenten und UI zu rendern.
Ich versuche es auch immer wieder, die zu benutzen, aber ich stoße auch so ein bisschen, wie eben angesprochen, immer so ein bisschen in das Problem mit dem Styling, weil eigentlich will ich nicht das Styling abschotten, sondern ich will es von außen stylbar machen irgendwie und das irgendwie, da habe ich noch keine gute Lösung gefunden.
Naja, aber wäre die einfachste Lösung nicht zu sagen, man macht das wie React und seine Abkömmlinge und sagt einfach, dieses Konzept Shadow DOM treten wir in die Tonne?
Ist ja nicht zwingend, dass man das macht. Man kann ja auch einfach sagen, wir machen nur Light DOM und ab geht's.

[26:16] Ja, kann man durchaus machen. Ich glaube, die Schwierigkeit ist einfach, wenn man innerhalb seiner Welt ist, ist das alles cool, aber der Vorteil an Web Components ist ja, wenn man Kunden hat, die überhaupt keine Ahnung von Frontend Frameworks haben, vielleicht ein bisschen HTML oder ein Script Tag einbinden können, dass die dann lauffähig gemacht werden und dann wird es immer ein bisschen schwieriger.
Also ich hatte mal ein Projekt, wo wir das halt versucht hatten und Und sobald du halt mehr komplexere Datentypen hast oder die irgendwie austauschen willst oder auch Styling erklären willst, dann ist...
Also ich hab das damals schon ein bisschen herzugegebenermaßen, vielleicht hätte ich bei Webcoupons das getan, aber ich hab das aber nie so richtig hinbekommen, dass die Benutzer einfach Styling ändern konnten.

[27:01] Also auch in der Light DOM-Variante nicht? Habe ich dich jetzt richtig verstanden?
Ich glaube, damals hatten wir die Light DOM-Variante nicht so wirklich hinbekommen, hatten auf die Shadow-Variante zugegriffen.
Weil was ich ja, glaube ich, bei Web Components eine relativ relevante Problematik finde, und das ist jetzt sozusagen ein bisschen genau kontra das React-Modell.

[27:24] Dass das, glaube ich, nicht sinnvoll ist, so ein Konzept herzunehmen und damit sie alle zu knechten.
Also wo man jetzt in React zum Beispiel hingehen würde und sagen würde, jedwedes Konzept, das in meiner Applikation irgendwie stattfindet, manifestiert sich am Ende als eine Komponente in meinem Komponententree.
Sei es jetzt eine Route als Subkomponente meiner Ruderkomponente oder wirklich ein anklickbares Element im Browser.
Ich glaube, das ist bei so Sachen wie Web-Components ganz hilfreich, das ein bisschen weiter auszudifferenzieren und sich zu überlegen, wenn ich mich hinsetze und ich will jetzt ein Problem lösen, das erstmal einzukategorisieren in so Fragen wie, soll das jetzt wirklich eine Web-Komponent werden, die die jetzt so den Universalitätsanspruch von HTML tatsächlich auch verfolgt und wirklich sagt, ich will da absolut universal sein und da halt wirklich so auch wirklich mit Shadow DOM arbeiten, mit Encapsulation arbeiten.

[28:14] Oder ist das möglicherweise was applikationsspezifisches, wo man diese Grundregeln von HTML und wie das alles sein muss und wie sich das alles verhalten soll, einfach ein bisschen aufweicht und so Dinge macht, die in normalem HTML eher kriminell wären.
Und dann ist man halt eben nicht so eingeschränkt und kann diese Werkzeuge einfach viel gezielter einsetzen, da, wo es jeweils hilft.
Und dass man nicht da sich versucht, ein Komponentenkonzept zu überlegen, sie alle zu knechten.
Ich glaube, das funktioniert in React einigermaßen gut, aber außerhalb der Welt wahrscheinlich echt nicht.
Dass man sich wirklich sagt, das machen wir mit Shadow DOM und machen da Encapsulation und vernünftiges Attribut-Parsing und hast du nicht gesehen.
Und für unsere applikationsspezifische Komponente machen wir wirklich irgendwas, brechen die Regeln, machen Light DOM, Inner-HTML setzen und dann gibt es halt eben keine Attribut-API, sondern einfach nur DOM-Properties oder irgendwie sowas.
Dass man das einfach so ein bisschen ausdifferenziert. Wäre so meine Idee.

[29:04] Da würde ich mich echt gerne die Meinung der anderen interessieren.
Ich sehe eine gehobene Hände schon.
Dazu hatte ich gar keine Meinung, aber deswegen sage ich nur kurz mein Sätzchen.
Die Idee, die ich mal mit Web Components hatte oder auf die Idee, die ich gekommen bin nach Newsletter-Artikeln, wäre, Web Components zu nutzen, um zum Beispiel auf einer View-Webseite eine React-Komponente einbinden zu können.
Ich habe es noch nie gemacht, würde mich super interessieren, falls hier irgendjemand Erfahrung damit gemacht hat, weil ich habe halt nur mal auf Vue.js gesetzt und das ist halt die, das Universum ist halt immer noch so, im Gegensatz zu ganzen React-Sachen, die es so gibt.
Und einmal hatte ich das Ding, dass ich eine React-Library einbinden wollte.
Ich habe es dann nicht getan. Ich habe dann schon eine Vue-Library gefunden, beziehungsweise wir haben es dann selber implementiert. Ist ja eh besser.
Aber anscheinend kann man mit Web-Components einfach React in Vue einbinden.
Würde mich interessieren, ob irgendjemand Erfahrung hat, aber ich würde jetzt auch wieder das Wort weitergeben zu dem Diskussion, die wir gerade schon hatten.

[30:06] Genau, ich weiß nicht, ob ich jetzt vor Jens dran war, aber ich spreche jetzt einfach mal.
Ich wollte noch einmal auf den Punkt des Stylings ankommen. Also wie gesagt, du kannst es, wenn du dich dafür entscheidest, alles im Shadowdom wegzupacken, natürlich mit Custom Properties machen. Das können sehr viele werden.
Alternativ, wenn du auf den Shadowdom verzichtest und du hast genau die Situation, dass Kunden bestimmte Sachen vielleicht überstylen sollen, dann kannst du vielleicht auch auch das Layer-Konzept von CSS nutzen.
Das haben wir gemacht in einem anderen Projekt, dass wir so Schichten definiert haben.
Und die unterste Schicht ist quasi nur atomar. Da werden Schriften definiert, Farben definiert, vielleicht Abstände und mit logischen Namen versehen.
Und dann gibt es eine Schicht drüber, in die ein Kunde sozusagen eingrätschen kann und diese logischen Farben, was weiß ich, Primary Color, Secondary Color und so weiter, überschreiben kann.
Und darüber kommt eine Schicht, wo wir aus den Atomaren Properties sozusagen das Styling für die einzelnen Komponenten aufbauen und da nochmal drüber wieder für den Kunden eine Schicht, dass er einzelne Komponenten, die vielleicht nicht so aussehen, wie er das haben will, nochmal selber stylen kann. Das klappt eigentlich ganz gut.
Also wenn man wirklich die ganze Applikation von außen kundenspezifisch stylen lassen möchte, dann ist dieses Leer-Konzept gar nicht so schlecht, meine Erfahrung.

[31:33] Seid ihr auf jeden Fall vorneweg sehr an der blutschigen Kante.
Ja, aber ich meine, es gäbe ja theoretisch auch noch andere Möglichkeiten, das zu machen.
Also du könntest ja zum Beispiel auch sagen, ich liefere jetzt eine Komponente mit irgendwelchen eingebauten Styles raus.
Und wenn die irgendwie jemand überstylen möchte, könnte man ja so Dinge anbieten wie, es gibt ja die Möglichkeit, irgendwie Constructable Style Sheet ans Shadow DOM dran zu assoziieren, dass man halt eigentlich ins Shadow DOM selber Style Text und ähnliches reinschreiben muss, dass man das irgendwie konfigurierbar macht, dass man zum Beispiel ja auch sagen kann, wir konzipieren diese Komponenten und da sind die Styles hinterlegt auf irgendeinem Klassenfeld und wenn du das irgendwie überschreiben willst, dann kannst du ja einfach da auch eine Subklasse draus ableiten und deine Styles entsprechend überschreiben.
Und dann hast du halt eben noch den Layering-Mechanismus und die Custom Properties und so weiter.
Also da scheint mir die Möglichkeit eher zu sein, dass es so viele Wege gibt, die da nach Rom führen könnten und dass man sich da entscheiden muss und nicht so sehr, dass das jetzt nicht möglich wäre, sondern da muss man halt irgendwie was designen.

[32:40] Ich glaube, jetzt bin ich bei Jens. Genau. Also ich glaube, dass dieses Styling-Thema, das braucht keine Lösung durch Webkomponenten, weil es eigentlich schon viel früher vor Webkomponenten in CSS gelöst wurde.
Man muss sich damit beschäftigen Und das kann man ja alles lösen.
Man kann es mit BEM lösen, man kann es mit extra Styling, CSS-Dateien lösen.
Das ist ja jetzt nichts, was jetzt neu herausgekommen wäre und was nicht viele Projekte schon vor 10 oder 15 Jahren gelöst hätten. Also dafür finde ich, ist es inakzeptabel, sowas zu benutzen.
Ich frage mich sowieso, wofür wir das brauchen, diese Webkomponenten.
Und ich frage mich das deswegen, weil ich das auch bei euch in den Diskussionen und bei anderen Podcasts immer so den Eindruck vermittelt bekomme, dass ich der Einzige bin, der noch nicht mit React, Vue oder Angular arbeitet.
Und wenn man sich dann Statistiken anguckt, dann ist es eigentlich genau andersherum.
Also ich arbeite noch in einem klassischen Web-Umfeld mit einem klassischen Content-Management-System.

[33:54] Wo dann auf dieser ultramodernen Sprachenbasis Java Templates erstellt werden mit JSP.
Und das ist ja jetzt nur nicht die unüblichste Variante, um größere Seiten zu erstellen, sondern es ist eher die unübliche Variante, React oder Vue zu benutzen.
Und da stelle ich mir für mich jetzt die Frage, wofür zum Teufel brauche ich denn eigentlich eine Webkomponente? weil ich dafür ja Templates habe.
Und das hier schon mal mehrfach angesprochene Shadow DOM, das finde ich zwar charmant, aber auf der anderen Seite schreckt es mich auch ab, weil dann klar ist, ich kann die Web-Component nur mit JavaScript benutzen.
Ohne ist das einfach tot.
Während wenn ich jetzt einfach das neu so betitelte Light DOM benutze, also einfach nur eine neue Komponente namens Peter minus Kröner erstelle und da drin einfach einen Button und vielleicht noch irgendwas anderes reinschreibe, dann funktioniert die auch ohne JavaScript.

[35:04] Und außerdem, wofür brauche ich es denn jetzt eigentlich, um einen Button zu definieren?
Wozu? Jede Templating-Sprache empfiehlt mir das.
Also wo macht das denn eigentlich Sinn? Das macht doch vielleicht dann Sinn bei etwas, wo ich sowieso JavaScript brauche, wie diese unsäglichen Scroller, wo ich dann mehrere Teaser habe, die ich dann so durchscrolle.
Da brauche ich eh JavaScript für und dann kann ich das auch in der Web-Konferenz machen.
Aber um einen Teaser zu erstellen, einen Button oder ein Eingabefeld, wozu denn bitte schön.

[35:36] Da schreibe ich dann mehr für die Web-Komponente. Das kann ich dir sagen.
Das willst du dann machen, wenn du entweder weißt oder damit rechnen musst, dass du es mit mehr als einer Sprache zu tun haben wirst, in der du dann deine Teaser und Buttons formulieren willst.
Also, wenn du jetzt sagst, das Ökosystem, mit dem du da arbeitest, diese JSP-Anwendung, die verwendet das und die wird das immer verwenden und jeder Code, den ich schreibe, wird niemals irgendwo laufen außerhalb, außer in diesem Kontext, dann ist super.
Aber sobald du damit rechnen musst, dass irgendwann mal eine reine React-Single-Page-Application um die Ecke kommt, dass irgendwer auch ein WordPress befüllen möchte und darin auch diese Komponenten verwenden möchte, die genauso aussehen und sich genauso verwenden, dann sind Web-Components im Prinzip das Einzige, was du so wirklich machen kannst, weil die sich ja am Ende als HTML manifestieren und das der kleinste gemeinsame Nenner ist, von dem halt eben alle, sowohl dein JSP wie auch dein WordPress wie auch dein React, am Ende irgendwie fundamental leben müssen und womit sie sich dann halt eben arrangieren müssen.
Wie gesagt, mit der Ausnahme, dass React halt eben da einen kleinen Bug hat und das nicht so richtig gut kann mit den Web-Components.
Aber im Prinzip ist das so. Du kannst halt eben eine Web-Component nutzen, um quasi so eine Art jQuery-Plugin in HTML runterzubrechen und das ist dann kompatibel zu allem und jedem bis zum Ende aller Tage.

[36:53] Und wenn du das nicht brauchst, dann würde ich davon die Finger lassen.
Wenn du weißt, ich schreibe den ganzen Tag nur React und das wird niemals irgendwas anderes sein, dann schreibst du eine React-Komponente. Ist viel einfacher, sparst dir eine ganze Menge Kopfschmerzen mit.
Wie kriegen wir das jetzt manager-kompatibel formuliert?
Am besten ganz viel Bullshit-Bingo drin. Das ist wichtig.
Ja, Cross-Plattform, zukunftssicher, sowas in der Richtung. Ja, genau.
Investitionssicherheit, Jens. Java ist investitionssicher. Ja, geil, JSP, ja.
Ja, ist ja auch richtig. Und ich glaube halt eben, dass tatsächlich ein dickes Brett das zu bohren ist, weil generell ist ja, so ist das um so Dinge wie irgendwie Bugfreiheit, Also das abgearbeitete Bug-Backlog und irgendwie Stabilität, technische Schulden und so, das lässt sich ja auch nicht manager-technisch formulieren, aber den Kampf haben wir ja auch nicht irgendwie aufgegeben, sondern versuchen das weiter irgendwie auf die Reihe zu kriegen, dass wir ordentliche Software schreiben dürfen.

[38:18] Deadline be damned. verargumentieren, versus alle benutzen React.
Das lässt sich viel besser und einfacher argumentieren, aber es ist jetzt, glaube ich, nicht komplett unmöglich.
Ja, und du hast natürlich auch so ein paar andere Vorteile. Du kannst in einem Content-Management-System, wo du irgendwie HTML einpflegen kannst, auch, oder WordPress auch, kannst du ein Custom-Element einfach einhängen, musst es dann nicht komplett ausformulieren, also sofern sich das dann eben per JavaScript zusammensetzt.
Der Marco hatte ja auch schon schon hier auf den deklarativen Shadow-Dom hingewiesen.
Also das gibt's ja mittlerweile auch.
Genau, das ist unser Urteil. Und ansonsten würde ich sagen, sind Web-Components ja auch praktisch.
Also wenn man jetzt gar nicht auf die Encapsulation so scharf ist oder das Verstecken der inneren Mechanik vor dem Zugriff durch Frameworks, eben einfach durch die Lifecycles, die man hat.
Also sowas wie DOM-Content-Loaded und so ist ja eigentlich, sagen wir mal, oldschoolig.

[39:19] Und was du machen kannst, ist eben diese Lifecycle-Hooks zu verwenden, wo du eben sagst, ich registriere eine Komponente und wenn eine dieser Komponenten irgendwo eingehängt wird, dann initialisiere ich die.
Und völlig egal, ob das direkt zu Beginn ist, also die schon in der Seite ist oder die später wie auch immer eingesetzt, eingeladen wird.
Und ich habe genauso einen Hook, wenn die eben wieder rausgenommen wird aus dem DOM und kann dann hinter mir aufräumen und so Sachen.
Du bist abhängig von JavaScript und da ist die Frage, wofür lohnt sich das?
Für den Button, für die Überschrift, für den Tieren, das sind ja alles Sachen, für die ich kein JavaScript brauche. Nee, nee, da brauchst du auch keine Web-Component.
Ich mach mal alles mit dem CSS, fertig.
Da brauch ich diesen ganzen Krampf nicht. Nee, nee, da brauchst du das auch nicht.
Und dann kann man das halt auch sein lassen. Also ich finde Web-Components isoliert zu diskutieren ist ein bisschen eigentlich Mumpitz, weil die sind ja nichts weiter als HTML mit ein paar Extras, die man dran bauen kann, wenn man möchte.
Also die Frage, die man vielleicht eher diskutieren sollte, wäre in dem Rahmen mehr so Single-Page-Application mit, wir springen ganz in den Kessel mit dem JavaScript hinein und sagen, das ist halt eben einfach die Basis, auf der wir operieren und ohne geht's halt nicht, damit finden wir uns ab.
Oder man sagt halt eben, der Ansatz, den Jens da fährt in seiner Company da mit der, sagen wir mal, eher Backend-fokussierten Herangehensweise, ist vielleicht eher so der sinnvolle.
Und Web-Components können halt eben auf beiden Hochzeiten tanzen, aber ich glaube, das ist eigentlich eher so...

[40:47] Die falsche Diskussionsgrundlage? Also Web-Component ist für mich halt mehr so eine Art Jack-Free-Plugin 2.0.
Ich will halt irgendwie eine einigermaßen portable Frontend-Plugin-mäßige Geschichte haben, die ich überall einsetzen kann und von der ich halt eben ausgehen kann, dass mit der alle arbeiten können.
Und ob sich das am Ende halt eben dann in einer Welt manifestiert, wo sowas passiert, wie der Teaser funktioniert nur, wenn JavaScript da ist.
Oder ob sich das halt eben manifestiert mit deklarativen Shadowdom, in dem, was der Marco hier vorhin in den Chat Chat geschrieben hatte.
Das ist eigentlich eine Frage, die mit dem Gegenstand Web-Component nicht notwendigerweise was zu tun hat, so direkt, weil man kann das halt eben auf alle Weisen irgendwie verwenden und das ist ja eigentlich auch der Punkt, warum man es überhaupt würde verwenden wollen, weil das nämlich mit allem irgendwie zusammengehen kann, aber.

[41:31] Da hängt halt immer so viel dran.
Ich nenne das bei mir selber, wenn ich das an mir selber feststelle, immer so, ich habe irgendwie React-Brain, dass ich automatisch hingehe und irgendwie sagen will, jedes Ding, was in meiner Applikation vorkommt, will ich irgendwie an eine Komponente gießen und muss mich dann immer zur Ordnung rufen, dass das überhaupt gar nicht sinnvoll ist notwendigerweise und dass ich wirklich überlegen sollte, was baue ich hier eigentlich, was ist mein primärer Ansatz, durch welche Linse schaue ich auf meine Applikation?
Ist sie Frontend-fokussiert oder ist sie Backend-fokussiert?
Und dann entscheide ich halt eben, was ich wie aufbereite, unter natürlich auch Einbezugnahme dessen, will ich wirklich überall funktionieren?
So, dann baue ich ein Web-Component oder sage ich, das ist jetzt eh nur ein Projekt, das eine gewisse Zeit halten wird, das nach wird eh alles neu geschrieben, dann mache ich das halt irgendwie alles mit mit meinen kleinseitigen Template-Sprachen, auch wenn die nur eben in diesem spezifischen Framework funktionieren oder mit meinen serverseitigen Template-Sprachen.
Aber ich finde, also Web-Components haben damit eigentlich nicht wirklich was zu tun.
Die haben was mit der Frage zu tun, HTML, Multi-Page-Application oder Single-Page-Application.

[42:28] Und wie sieht mein Gesamtökosystem in meinem großen Kontext aus, wenn das irgendwie Sinn ergibt, was ich da jetzt gerade gefaselt habe.
Es ist halt schwierig. Es klang klug.
Vielleicht ganz kurz reingekritscht, Wir haben jetzt schon zwei Meldungen, die schon ein paar Minuten da sind.
Vielleicht, Falk, stellen wir mal zu dir durch.
Ja, kurz ergänzend zum letzten Thema. Man darf das mit den Custom-Elements auch, man haut es ein bisschen durcheinander.
Also es ist anders, wenn ich das jetzt in React zum Beispiel verwende, weil da macht es durchaus Sinn, dass ich eine Komponente mache für einen Button, weil ich halt mit Tailwind irgendwie 20, 30 Klassen dran habe und die will ich nicht jedes Mal dran schmeißen, wenn ich irgendwo den Button verwende.
Das hat aber nichts mit dem Custom-Element von Web-Komponenten zu tun, weil da würde ich logischerweise kein eigenes Element für den Button schreiben.
Das ganz kurz dazu und noch zwei Anmerkungen zu dem Thema davor.

[43:42] Das ist, finde ich, eigentlich schon ein ganz cooles Konzept.
Und zu Vanessas Frage zum Thema, wie das ist mit Mischen, also wenn ich jetzt verschiedene Web-Components habe mit verschiedenen Techniken.
Also ich hatte beim letzten Projekt das Problem, dass es teilweise dann schon problematisch ist, wenn man halt sowas wie Projekt oder Co.
Einsetzt, was ja bei Änderungen dann einfach mal komplett rerendert zum Teil.
Und man hat dann irgendwelche Techniken eingemischt, also mein Beispiel war es, da war halt irgendein JQuery, Dropdown-Element drinne und das hat mit den Reh-Rendern halt überhaupt nicht funktioniert.
Also es hat sich immer wieder gegenseitig beeinflusst oder wurde rausgeschmissen oder auf einmal war das Dropdown fünfmal da.
Also das versteckte Select war nur einmal da, aber das JQuery-Element wurde vervielfacht.
Also da habe ich schon so meine Probleme mit gehabt, mit den Mischen von den Techniken.

[44:38] Ja. Ja, das JavaScript Skript ist halt dann am Ende irgendwie immer noch global, aber dann ich will gerade dann waren aber die Sachen wahrscheinlich nicht im, Shadowdom drin, oder? Doch? Also...
Ich will gerade, wie Preact das dann geschafft hat, da ranzukommen.
Oder war das dann quasi ein Kind von einer Preact-Komponente oder sowas?
Also in dem Beispiel hatte ich ein Custom-Element Dropdown gemacht.
In dem hatte ich dann die jQuery-Plugin- Funktionalität drin.
Und mein ursprüngliches Problem war, ich hatte Padded View ringsrum.
Und das hat in Kombi mit dem Custom-Element das Problem verursacht, dass man musste andauernd jQuery wieder antriggern, damit es das dann nach dem Währen dann auch wieder überspielt und je nach Reihenfolge hatte ich auch manchmal das Dropdown auf einmal doppelt.
Ja, die vertragen sich nicht so gut, diese zwei Konzepte, ja.

[45:39] Der Alex hat noch was. Jo, genau, also erst mal, ich habe auch noch keine React-Library in einer Web-Komponente, in einem View-Projekt genutzt.
Wenn man natürlich sagt, man hat eine Web-Komponente, die man ganz gerne nutzen möchte, egal mit was am Ende gebaut wird, weil ja X-Frameworks auch zu Web-Komponenten am Ende exportieren können, ja, wie du auch Angular sowieso und so weiter und so weiter, ist das, denke ich, eine ganz nütze Möglichkeit.
Es gibt ja auch mittlerweile Component-Libraries, glaube ich, mit TOSOS zum Beispiel, die ja auch auf Web-Komponenten gebaut sind und so weiter und so weiter.
Das ist, denke ich, eine ganz nette Option dafür.
Und noch als Anmerkung, ich glaube auch, das ist wieder sehr spezifisch, das Vue-Ökosystem ist auch ein bisschen gewachsen, natürlich ist React trotzdem noch dort, aber aber du bist nicht nur hier, vielleicht so ein bisschen so, das nur kurz als Anmerkung zu dem Thema.
Meine Frage, die hatte ich aber schon im Chat geschrieben, und zwar das Thema Server-Side-Rendering und Web-Components.
Ich erinnere mich, als es damals diesen so Halb-Run von Rich Harris gab zu dem Thema Web-Komponenten, war das ja auch ein großes Thema mit, ja, es ist schon die Plattform, aber Server-Side-Rendering ist tricky.
Hatte ein Diamond Erfahrung mit.
Als jemand, der sehr viel mit Server-Side-Rendering, View und Nux macht, ist es immer mal ein Thema, was bei mir meistens ganz oben ansteht mit, wie ist denn da die Kompatibilität, was geht da, was ist noch nicht möglich?

[46:55] Also ich habe da jetzt keine große praktische Erfahrung mit.
Ich bin ja, wie gesagt, auch nur hier der Erklärbär. Ich mache ja keine richtige Arbeit, ich quatsche ja bloß.
Aber ich meine, erstmal würde ich natürlich kategorisieren, dass Server-Side-Rendering ja im Prinzip ein Problem löst, das man ja nur unter sehr bestimmten Umständen hat.
Nämlich halt eben unter dem Ansatz, dass die primäre Sicht auf die Welt die der Single-Page-Application ist.
Und wie der Jens ja vorhin schon gesagt hat, ist das ja eine Sicht, die uns hier als super interessierte Nerds, die erscheint uns, sagen wir mal, relativ weit verbreitet, aber sehr viel Web-Software da draußen ist halt immer noch, ich rendere halt über meinen Java oder PHP ein bisschen HTML raus und ich brauche ein bisschen JavaScript, um das aufzumotzen.
Das, was halt früher Jake Ferry gemacht hat, das wäre halt heute so ein Job, den Web-Components ganz gut machen können.
Und ich würde halt sagen, daran wird natürlich jetzt Web-Component-seitig gearbeitet, mit dem deklarativen Shadow DOM.
Da würde ich aber persönlich so vermuten, dass das von Leuten in unserer Blase hier wahrscheinlich sehr viel heißer gekocht wird, als es am Ende gegessen werden wird.

[48:07] Das ist jetzt nicht irgendwie besonders hilfreich, dass ich das so vermute oder feststelle.
Aber ich würde halt eben nur mal sagen, mir wäre halt wichtig, dass man diesen Aspekt von Server-Side-Rendering so versteht, dass das tatsächlich ein spezifisches Problem löst, das man nicht notwendigerweise hat.
Und wenn man das Problem nicht hat, dann kann man theoretisch so Cowboy-mäßig Web-Components bauen, wie halt heutzutage man das so macht.
Die sind halt eben dann kleinseitiges JavaScript, das sich halt erst kleinseitig manifestiert.
Aber wenn man das halt eben nur verwendet, um seine paar HTML-Formulare und Tabellen ein bisschen aufzumotzen, wie gesagt, so wie früher mit jQuery, dann braucht man das eigentlich gar nicht.
Und da weiß ich halt auch nicht, ob ein allgemeiner Ansatz für Web-Components, der wirklich Allgemeingültigkeit haben möchte, ob der sowas dann notwendigerweise fest eingebaut braucht, oder ob das eher was wäre, dass so spezielle Web-Components, Web-Component-Libraries zum Beispiel, haben müssten.
Also irgendwie, ich baue eine Web-Component-Library, die sagt, ich bin jetzt hier wirklich für Single-Page-Applications gedacht versus ich bin ein anderes Web-Component-Framework oder Library, die jetzt speziell den Use-Case bedient.
Wir wollen einfach nur das Aufhübschen dieses jQuery 2.0, diesen Use-Case ein bisschen einfacher machen, dass man das wieder aufdifferenziert und nicht einfach so sagt, Web-Component, das Ding muss die eine Lösung sein, sie alles zu knechten und das muss halt dann auch eine API geben, sie alles zu knechten.
Ich glaube, das lädt dem ganzen Konzept zu viel auf, wodurch es dann hinterher unbeweglich, schwergewichtig und weniger nützlich wird, als es sein könnte, wenn man das ein bisschen differenzierter betrachtet, würde ich vermuten.

[49:36] Jens, sag mal was.
Ja, du weißt ja, ich liebe ja dieses Thema.

[49:44] Ist das nicht so, dass dieses Server-Side-Rendering eigentlich nur Ausfluss der Erkenntnis ist, also der Erkenntnis der Entwickler von React und Co., dass das, was sie da gemacht haben, für die meisten komplett unnütz in der Gänze ist?
Weil die Idee war ja eigentlich, ich schiebe jetzt erstmal alles das, was viel schneller auf dem Server gerendert werden könnte an den Client und da wird sich alles zusammengebaut.
Und dann haben sie festgestellt, oh, JavaScript ist doch nicht so schnell.
Ich meine, das wussten zwar alle vorher, aber sie haben es halt vorher anders gemacht.
Und jetzt wird mit JavaScript-Mitteln quasi PHP geschrieben.
Also bei Service-Side-Rendering sage ich immer, das haben wir früher PHP genannt.
Nur, dass die Entwickler jetzt halt kein PHP mehr schreiben, sondern sie schreiben jetzt React oder Vue oder you name it.

[50:36] Und dann wird das, was eh statisch ist und überhaupt nicht im Client gerendert werden muss, das wird auf dem Server gerendert.
Und die drei Sachen, die tatsächlich auf dem Client gerendert werden müssten, wenn überhaupt, die werden dann tatsächlich im Client gerendert.
Ich kann mich noch ganz an frühere Zeiten erinnern, als gerade Prototype rauskam.
Da sollte auf der Bankseite, die ich damals betreut habe, sollten dann die aktuellen Börsenkurse immer wieder gegeben werden.
Das ist mal ein Praxiseinsatz, der sinnvoll ist, aber der ja wirklich bei Applikationen vielleicht hauptsächlich vorkommt, aber der ist bei mir, bei so einer stinknormalen Newsseite eher nicht vorkommend.
Da ändern sich halt die Teaser stundenweise oder alle vier Stunden und dann wird sowieso die Seite neu gerendert, weil sich auch das Arrangement ändert.
Dafür brauche ich keine 3-Megabyte-React-Applikation rauszuhauen.
Also ist das vielleicht jetzt eher die Erkenntnis, dass der Weg für die meisten eher nicht funktionierte und jetzt machen wir wieder einen Rückwärtsgang und wir schreiben jetzt einfach PHP mit JavaScript? was gibt.
Ich würde das, sagen wir mal, nicht so brutal klassifizieren wie du.

[51:57] Ich würde das mehr so beschreiben als eine Ausdifferenzierung.
Also du stellst halt eben wirklich, glaube ich, das Wichtigste fest, was man feststellen kann in dem Bereich, nämlich, dass halt nicht alles, was im Browser stattfindet, gleich ist und irgendwie zu sagen, ich baue was, was im Browser stattfindet, also brauche ich dafür eine Standardlösung, die das halt eben alles macht, ist halt, glaube ich, echt nicht ein hilfreicher Ansatz.
Also wirklich, wenn es darum geht, deine statischen News-Seiten zu rendern, wo sich halt eben alle Stunde mal der Teaser ändert, da würde ich halt wirklich sagen, das braucht halt ein ganz anderes Herangehen und ganz anderes Nachdenken, als wenn ich wirklich was hyperinteraktives mache, wo ich irgendwie so eine Art keine Ahnung, No-Code-UI im Browser baue, damit mir sich irgendwelche Manager mit Clicky-Bunty irgendwelche komplexen Workflows zusammenklicken können.

[52:46] Oder halt irgendwie, ich mache so und Google Docs und so, da gibt es halt wirklich ein ganz breites Spektrum und was halt hilfreich wäre, wo halt die Frage ist, ob das Menschen Gehirne leisten können, wäre wirklich zu differenzieren und zu sagen, okay, was bauen wir hier eigentlich, was ist die sinnvollste Linse, durch die man auf das Problem blicken sollte und folgt dann aus dieser Linse, für die wir uns dann entscheiden, die dann Frontend heißt oder Backend heißt, die dann Multi-Page-Application oder Single-Page-Application heißt oder Application oder Webseite heißt, was folgt dann daraus und was für Tools nehmen wir dann dazu her?
Ja, bauen wir jetzt irgendwie in Fancy Pants Reacting oder machen wir einfach nur ein bisschen Java und HTML und CSS? Oder machen wir irgendwie eine Mischung daraus?
Ich würde aber gerne nochmal einen anderen Aspekt da mit einbringen, nämlich, also ich glaube, dass halt gerade JavaScript halt ultra accessible ist für Entwicklerinnen und Entwickler.
Also so viele von uns allen haben irgendwie mit JavaScript auf dem Frontend wahrscheinlich gestartet, inklusive mit selbst und sind dann halt, okay, ich habe irgendwann mal PHP gemacht, aber wie dem auch sei, JavaScript ist mir näher als Java.
Und wenn ich jetzt anfangen muss, halt eine Java-Entwicklungsumgebung irgendwie hochzufahren und so weiter und so fort, dann ist das so weit weg irgendwie für mich.
Und es fällt mir unheimlich schwer, da irgendwie drin zu arbeiten.
Ich glaube, irgendwann, als dieser Need entstanden ist, hey, wir sind eigentlich im Frontend mit unserem ganzen JavaScript-Graffeln ein Stück weit zu langsam, wir müssen auch wieder viel mehr auf die Backend-Seite zu bringen, da gingen diese neuen Überlegungen los und ja, das war alles schon mal da mit PHP. AP.

[54:15] Nichtsdestotrotz der Erfolg, den sowas auch wie ein Vercel beispielsweise, die ja Next.js entwickeln, ja hat und die Geschwindigkeit, die die halt in ihre Applikationen bekommen mit dem serverseitigen Rendering, und da gibt es ja einige Beispiele auf jeden Fall, ich glaube, die ist nicht zu vernachlässigen.
Ich würde nicht sagen, dass die, dass man es nicht schaffen kann, beispielsweise die gleichen.

[54:41] Ja ja, Developer-Experience auf der einen Seite und auf der anderen Seite die gleiche Performance vielleicht auch in Java abzubilden.
Nichtsdestotrotz ist es halt ein Paket, was für alle Leute, die halt irgendwie JavaScript können, halt zugänglich ist, wenn sie sich damit beschäftigen.
Und ich glaube, das ist halt nicht zu vernachlässigen und das zeigt halt der Erfolg auch irgendwie. Ich glaube, da geht es auch noch ein bisschen mehr.
Zum einen natürlich die gemeinsame Sprache, zum anderen natürlich auch das Mental Model.
Wenn man jetzt sagt, man hat halt theoretisch eine Seite, die erstmal Content rendert und dann packen wir JavaScript drauf und merken aber, okay, wir haben eine ganz stinknormale statische Seite, so ein Blog, dann sagt man, okay, jetzt sollen wir vielleicht nur noch einloggen können, da hat man nur noch Personalisierung und dann geht es natürlich los mit, okay, was muss wo gerendert werden, welche Daten haben wir wo und dann kommt man vielleicht irgendwann ein Punkt, wo man sagt, okay, es wird halt doch mehr und mehr Interaktivität.
Trotzdem soll der Inhalt aber serversattig gerendert werden, weil wir hätten ja trotzdem ganz gern die SEO-Benefits. Das ist mit SPA ja ein bisschen trickier.
Deswegen Server-Site-Rendering, was glaube ich auch ein großer Punkt ist, weshalb SSR existiert. Abgesehen von dem Performance- und Speed-Thema natürlich.
Weil Node ist jetzt auch nicht besonders schnell darin, Sachen auf dem Server in String zu konkatenieren.

[55:53] Aber das nur zur Seite. Deswegen ich glaube halt, ganz viele Anwendungen könnten halt, solange sie halt public-facing sind, also jetzt nicht irgendwie hinter Authentication und Co.
Von Server-Set-Rendering zumindest Vorteile mitnehmen.
Auf der anderen Seite gibt es aber auch da genug Interaktivität, dass man sagt, naja, so Content only reicht nicht.
Deshalb wir viele Sachen haben mittlerweile, Island-Architecture, wie wir schon gesehen haben, Astro, wurde schon im Chat erwähnt von Julian, und so weiter und so weiter.
Und noch viele andere Frameworks, Next und Versa, mit diesem Past-Shift-Pre-Rendering und Next, geht ja auch aus eigener Erfahrung, deswegen mit Server-Components, wo man sagt, okay, wir wollen eigentlich so eine Mischung aus beiden, aber das mentale Model in einem Framework zu bleiben, wäre Wäre halt ganz schön.

[56:30] Ich greife schon mal kurz rein, weil ich habe die Zeit im Blick.

[56:35] Und theoretisch wären wir jetzt mit dem ersten Slot durch. Aber wenn du darauf bist ... Ich habe gerade schon einen Chat gepostet. Ich würde einfach sagen, um 16.15, 16.20, wir können einen fließenden Übergang machen.
Wir müssen ja jetzt nicht aufstehen, über Stühle stolpern, quietschende Türen öffnen, holt euch einfach Tee und Kaffee etc., wie ihr das haben wollt.
Wir hätten die Zweitstimmen gehabt bei Framework Jungle 2024 und den Designsystemen.

Erwartungen an den Framework-Jungle 2024

[57:00] Der Framework-Dschungel schließt sich hier irgendwie fast schon ein bisschen an. Vielleicht wollen wir da einfach den fließenden Übergang machen.

[57:06] Ich glaube, ein Punkt, der noch ist, für mich gibt es ja nicht nur Server-Side-Rendering und Client-Side-Rendering, sondern das dazwischen auch noch.
Da gab es eh mal kürzlich eine Folge, quasi HTML over the wire.
Das ist für mich oder für uns in vielen Use-Cases ist das eigentlich ein super Ansatz, wo ich sage, ich haue, also wir haben zum Beispiel eine News-Seite, Finanznews-Seite, da ändert sich täglich das Seitenmenü, weil die die aktuellen News haben wollen, aber der Inhalt ändert sich nicht und wenn dann Google quasi die Seiten wieder besucht, dann waren die davor immer langsam, weil der Server quasi die Seite zuerst mal zusammenbauen musste.
Und da haben wir das dann so gelöst, dass wir gesagt haben, ja gut, das Menü wird einfach dynamisch per Javascript einen eigenen Endpunkt, wo das Menü dann zurück gibt und das bauen wir dann quasi dort dort rein.
Und das hat einen massiven Boost gegeben in der ganzen Geschichte, weil wir quasi die ganzen News sind nur noch statische Seiten, wo wir sogar rausspielen können.
Der Server haut das zurück und das Menü baut sich dann je nachdem auf.

[58:09] Je nach User-Präferenzen, was ihn interessiert und so weiter und so fort.
Und das ist eigentlich auch noch ein spannender Ansatz.
Also das sind so ein bisschen die Twitter-Lösungen, wo du sagst, ja, du hast einerseits sogar statisches Rendering, wo du zurückgibst zwecks Geschwindigkeit und ähm.

[58:31] Fügst da nicht nur ein bisschen Sprinkles dazu mit JavaScript, sondern sagst dann wirklich ja gut, die ganzen Menügeschichten kommen dann so rein, dass wir da quasi diese ganzen Geschichten mit mehr Speed versehen können.
Und das ist eigentlich in ja noch einen spannenden Ansatz.
Gab es auch alles schon immer, nur jetzt, ich glaube, es wiederholt sich ja immer so wieder ein bisschen das Gleiche.
Also seit langem war alles Flat, Flat, Flat Design und jetzt kommt wieder, wieder Glas-Effekte und 3D und alles Mögliche.
Das Rad dreht sich immer ein bisschen in die gleiche Richtung.
Und hoffentlich meistens verbessert es sich ein bisschen dabei, manchmal auch nicht, aber ja.
Das ist wie mit der Kleidungs- und Frisurenmode. Genau. Kümmere dich 50 Jahre nicht drum, und dann bist du wieder der Trendsetter.
Entweder das oder antizipiere das, was immer du gerade machst, in absehbarer Zeit nicht mehr der der bestmögliche Weg ist oder zumindest nicht als der wahrgenommen wird.
Und dann machen wir es mit der Erkenntnis. Das nicht heißt, wenn dann demnächst das Framework nicht mehr funktioniert, oh mein Gott, hätte ich was mit Holz gemacht, weil hätte man ja ahnen können, dass das in Zukunft anders aussieht.

[59:49] Der Falk hat die Hand oben. Ja, ich wollte nochmal kurz nachfragen, benutzt denn jemand Server-Site-Rendering und Web-Components?
Also ich habe das jetzt gar nicht ganz verstanden, weil für mich ist so eine Web-Component ja irgendwie eine Erweiterung von HTML, also etwas, was im Browser stattfindet.
Und Server-Site-Rendering ist für mich ein anderes Thema in dem Sinne. Keine Ahnung.

[1:00:14] Die Idee ist ja, man hat React-Brain, Man sagt, die ganze Web-Applikation besteht aus lauter kleinseitigen Komponenten.
Das heißt, ganz viel Action findet im Shadow DOM statt.
Das ist ja kleinseitig generiert, aber kleinseitig generieren ist ja einerseits die primäre Linse, durch die wir auf die Welt schauen.
Andererseits wollen wir das nicht haben, weil es soll ja vom Server kommen, weil nur dann ist flott.
Also braucht man irgendwie beides, die Quadratur des Kreises.
Das ist so die Idee dahinter.

[1:00:42] Und dafür gibt es ja das deklarative Shadow DOM. Das ist ja relativ neu.
Ich war just dabei, bevor ich anfing zu quatschen, nachzuschauen, wie das da mit der Browser-Unterschützung aussieht. Irgendwer weiß das wahrscheinlich.
Ich glaube, Firefox kann es noch nicht, aber die anderen beiden.
Die anderen beiden, okay, weil es gibt ja drei Browser.
Ja, aber das ist so der Stand der Dinge und das ist jedenfalls die Problemlösung dahinter.
Wieder halt eben, bei gegebener Weltsicht macht dieses Konzept Server-Side-Rendering für Web-Components ganz viel Sinn, aber bei gegebener anderen und völlig validen Weltsicht macht das halt nicht so viel Sinn. Und das ist auch jeweils okay.
Man muss ja nicht immer alles auf einmal benutzen. Man muss ja nicht irgendwie Angular und React und Web-Components miteinander kombinieren.
Man kann das schon machen. Da braucht man halt einen guten Grund dazu.
Aber man kann halt auch einfach sagen, wir haben so viele Möglichkeiten und so viele Technologien. Man pickt sich hier was raus, da was raus, da was raus.
Und solange die halt irgendwie alle auf vernünftigen Standards fußen, können die wunderbar miteinander zusammenarbeiten.
Und dann macht man sich die Welt so, wie es einem gefällt oder wie man es halt eben braucht, um das jeweils aktuelle Problem zu lösen.
HTML over the wire und React kombinieren. Was weiß ich, warum nicht?

[1:01:50] Die kommen sich doch schon nur wieder ins Gehege. So wie bei Falk.
Ja, sicherlich, aber wir wissen dann ja wenigstens, wer schuld dran ist und können da rummöpeln und einen Bug-Report schreiben und so.
Ich weiß, das wird nicht viel bringen, aber deswegen halt eben eine Einschränkung, wenn es auf vernünftigen Standards fußt und nicht irgendwie sagt, so hier, move fast and break things.
Der Alex postet gerade, dass Firefox das auch implementiert hat, wohl schon.
Ich weiß, das ist bei der TPAC, also bei der W3C, bei dem Face-to-Face-Meeting, ich glaube Ende Oktober oder so was, letzten Jahres, da haben die ganz viel zu Web-Components irgendwie vorangeschoben.
Und da weiß ich auch, dass die Firefox-Leute gesagt haben, oder die Mozilla-Leute, deklaratives Shadow DOM, da sind wir jetzt auch dran.
Dann scheinen die jetzt auch tatsächlich auf der Zielgeraden zu sein.

[1:02:45] Der Dennis. Hallöchen. Ja, zum Thema Framework-Dschungel.
Ich weiß nicht, ob das irgendwie bei mir jetzt persönlich jetzt so ist, aber ihr das auch fühlt, aber die letzten Jahre war ich auch mal so, ja, was ist der nächste neuste JavaScript-Framework und der nächste heiße Scheiß und ist das eigentlich cool, muss ich das machen? Also so viel Fear of Messing Out.
Dieses Jahr hatte ich das irgendwie gefühlt gar nicht, weil so wie ihr auch gesagt habt, irgendwie die Tents wiederholen sich oder es kommen mal wieder und andererseits denke ich mir auch so, wenn ein Framework sich ja dann durchsetzt, dann bekommt man das auch mit und man spart ja die Zeit, anstatt wenn man so ein Framework, was neu ist, sich so anguckt und viel Zeit investiert und dann irgendwie in zwei, drei Monate ist das obsolet, weil die anderen großen Frameworks das irgendwie kopiert haben, und da ist halt die Frage, wie seht ihr denn das gerade, verpasse ich irgendwie jetzt gerade ein kasses Framework oder seid ihr da auch mittlerweile etwas geschälter und zu kalender?

[1:03:41] Ich bin auch eben wie du gechillter unterwegs.
Ich finde es immer noch gut, dass es quasi sozusagen Konkurrenz gibt.
Und es gibt immer ja noch die Argumente, dass man das Framework benutzen sollte, was jetzt gerade am besten für das Projekt passt oder sogar mehrere.
So ein bisschen gleichzeitig FOMO als auch, ist mir jetzt auch gerade fast egal, ist bei mir quick, weil es halt wieder so ein ganz anderer Ansatz ist, Also im Endeffekt so React oder Vue, im Endeffekt da kommt halt so eine Webseite raus, die ich auf jeden Fall bauen könnte.
Quick funktioniert angeblich vom Ansatz anders, wobei wir hatten ja die Episode mit Bernhard und Stefan mal drüber, wo wir eigentlich gesagt haben, wir verstehen eigentlich gar nicht so genau, worum es geht und warum wir das brauchen.
Und ich glaube, Stefan hat ja auch erzählt, wir hatten das eigentlich schon mal und vielleicht wiederholt sie es auch nochmal.

[1:04:35] Alex? Ich habe auch keine große FOMO, muss ich ehrlich sagen.
Ich finde es interessant, was jetzt gerade so Richtung Solid, was jetzt ein bisschen populärer wird, Quake und Co. Es ist nett, sich das anzuschauen.
Ich bin erst mal der Meinung, dass man egal, welches größere Framework man aktuell nutzt, sei es React, sei es Angular, sei es Vue, sei es Svelte, man kann halt am Ende mit allen super Sachen bauen.
Und auch selbst ohne Framework kommt man da gut klar, auch mit Web-Components, wie wir es gerade schon erläutert haben. Es kommt auf den Use Case an.

[1:05:06] Ich bin nicht der größte Freund von, wir müssen jetzt auf jeden Hype aufspringen, logischerweise. Es ist halt ganz nett, sich das anzugucken und eben zu schauen, okay, welche Probleme löst das?
In welchen Szenarien macht es denn Sinn, zum Beispiel, einen Svelte statt einen Englert zu nutzen?
Okay, keine Ahnung, performance-technisch, wobei es mit Englert 17 auch wieder ein anderes Thema ist, aber ist es mal ganz nett zu schauen, was geht denn da so, welches Szenario macht denn vielleicht Sinn?
Und gerade, wenn man sagt, okay, ich kann meinen JSX behalten, wenn ich im React-Universum lebe, und ich kann halt auf Solid oder React setzen oder auf Quick setzen in verschiedenen Szenarien, dann why not?
Aber an sich jetzt so, ich glaube, das Interessanteste in dem Sinne ist halt, am ehesten noch Astro, weil das halt zum einen ja auch nicht das klassische neue JavaScript-Framework ist, sondern eher dieses, wir brauchen eigentlich gar nicht so viel JavaScript, lass doch einfach mal alles, was statisch ist, statisch sein und was interaktiv ist, das können wir dann hydraten und dann ist alles gut.
Das ist halt ganz interessant und eben auch zu sehen, wie dann die einzelne Meta-Frameworks darauf reagieren würde, also wie ein Next.js, ein Svelte-Kit, ein Nuxt und so weiter und so weiter reagieren würde und sagen, wie kriegen wir das vielleicht in dem jeweils eigenen Universum unter?

[1:06:13] Für mich sind Frameworks nicht nur Sachen, wo man dann wie Svelte oder Vue oder React oder sowas, sondern was für mich auch entspannter wurde, ist das Ganze, wie man quasi die Sachen baut.

[1:06:28] Ich bin ein großer Fan davon, wenn man die JavaScript- und CSS-Ressourcen nicht mit Frameworks baut, wo mit JavaScript geschrieben sind.
Da ist man halt häufig in Probleme reingelaufen, dass man nach circa einem Monat die ganze Sachen komplett refactoren musste und es nicht mehr gegangen ist.
Meinst du Build-Tools jetzt? Ja, so Build-Tools halt. Also für mich ja auch eine Art Framework.
Und da bin ich schon dieses Jahr so Geschichten rausgekommen sind, wie ES-Build oder so, hat das Ganze schon für mich jetzt massiv entspannt, weil es einfach einfacher geworden ist im Vergleich zu, sagen wir mal, vor ein paar Jahren, wo man mit Webpack oder mit Rollup oder mit weiß nicht was allem und dann immer ein Riesending hatte und dann hat es nicht funktioniert.
Und dann, klar, es gibt immer noch sicher genügend Use Cases, wo man das dann auch benutzen kann, aber das war für mich schon letztes Jahr eine massive Erleichterung, weil das ganze Handling einfach schon einfacher geworden ist in den Geschichten.

[1:07:29] Das ist für mich auch so ein, gehört für mich auch ein bisschen zu Frameworks, also wie die Sachen halt gebaut werden, nicht nur mit was ich die, die Applikationenbau oder die Oberfläche, sondern halt auch das darunter, die Bildtools.
Vielleicht kann man da den Marvin einmal vorlassen, weil der bestimmt genau zu dem Thema eine Meinung hat, nachdem du ja ungefähr zehn Blogposts schon zu diesem Themenblock geschrieben und vorher geforscht hast.

[1:08:05] Ja, ich finde, das Thema Bildschirm ist jetzt ziemlich spannend, weil ich finde, die S-Bild hat erstmal gezeigt, dass man das schnell machen kann.
Das war so davor mal so ein bisschen unklar. Da haben alle hingenommen, dass es langsam ist. Dann kam die S-Bild, hat es schnell gemacht.
Und ich habe das Gefühl, dass wir mittlerweile uns alle so ein bisschen annähern, weil viele eigentlich doch so die gleichen Sachen machen mit dem Bildschirm, sei es Nux, sei es Next.js.
Es gibt immer so diese Grundbasis an, wie ich minimifiziere man ja das Scriptcode, ich kompiliere Typescripts zu was anderem oder ich mache CSS-Module-Imports oder was auch immer.
Aber dann gibt es noch irgendwie so diesen Layer darüber, der dann doch Framework-spezifisch ist.
So wie verstehe ich genau dieses Routing-Konzept von SvelteKit oder SolidStart oder bei Quick, wie gut kenne ich, was ist eine Server-Function, was ist eine Client-Function und kompiliere es entsprechend.
Und ich habe aktuell das Gefühl, dass wir da so ein bisschen doppelt erfinden, so ein bisschen.
Also viele nähern sich ja an Vita, an viele Tools, aber irgendwie auch so dieser gleiche Teil von den Tools, den alle benutzen, der wird irgendwie, ich habe das Gefühl, da ist noch mehr machbar, dass man alle auf das Gleiche setzen könnte und mehr sich über den Frameworks-spezifischen Layer austoben sollten.
Aber mal schauen, vielleicht ist es ja genau dieses Jahr, wo es jetzt passieren wird.

[1:09:20] Und der Jens, würde ich sagen. Mich interessieren ja bekanntermaßen so JavaScript-Frameworks eher nicht so extrem, eher so CSS und.

[1:09:32] Und da habe ich so für mich festgestellt, als ich auf diese hübsche News-Seite gekommen bin, da war alles mit Bootstrap 3 entwickelt worden.
Also schon ein paar Jahre her.

[1:09:45] Und das ist für mich so ein wunderbares Beispiel auch für diese ganzen Java-Script-Frameworks.
Es gibt immer verdammt viele Seiten, die für einen sehr langen Zeitraum gepflegt werden müssen, die nicht einfach mal erstellt werden und nach einem Jahr wieder sterben dürfen.
Und dementsprechend muss jedes Framework, das man nutzt, auch für die nächsten Jahre weiterentwicklungsfähig sein.
Und bei Bootstrip war das zum Beispiel nicht der Fall. Der Wechsel von 3 zu 4 war komplett Breaking Change.
Von 4 zu 5 so ein halber Breaking Change. Das macht überhaupt keine Freude, mit sowas zu arbeiten.
Vor allen Dingen, wenn du dann dein ganzes HTML auf Version 3 gebaut hast und nachher fallen dann alle Teaser weg. die heißen ja auf einmal Cards, das gab es vorher nicht, und Pipapo.
Also es gibt ganz viele Sachen, die da extrem anstrengend sind.
Und das wird bei JavaScript-Frameworks auch nicht anders sein.
Und jetzt letztens habe ich eine Seite oder mehrere Seiten gebaut, die mehr so in die Kategorie, ich mache sie einmal und dann werden sie in ein paar Jahren weggeschmissen und nicht mehr gepflegt gehören. Und die habe ich mit Eleventy gemacht. macht.
Ich liebe Eleventy, aber das Problem da ist dann auch wieder, es ist eine Node-Umgebung.

[1:11:03] Und die entwickelt sich quasi alle drei Tage weiter, im Gegensatz zur Java-Umgebung, wo meine Kollegen mitarbeiten. Die entwickelt sich alle 30 Jahre weiter.
Und wenn ich jetzt in einem halben Jahr diese drei Seiten mal wieder anfassen möchte, die ich mit Eleventy gebaut habe, könnte es sein, dass ich da in Schwierigkeiten komme, wenn ich das nochmal neu installieren muss, weil dann ich vielleicht eine uralte Node-Version bauen muss.
Und die ganzen Tools, die sind ständig aktualisiert.
Also ich habe da ein echtes Problem mittlerweile, da aktuell zu bleiben und weiß auch nicht, erstens, wie man sich die Arbeit erleichtern kann und zweitens, ob es da auch einen Sinn macht, dann eine Seite, die läuft und die auch prima läuft, dann immer wieder aktuell zu halten, nur weil man sie vielleicht in drei Jahren mal irgendwo ein Komma ändern muss oder eine Überschrift oder einen Teaser rausschmeißen muss. Ja, nachher läuft es darauf hinaus. aus.
Das Einzige, was sich da ändert, sind irgendwelche Teaser, die vielleicht noch hinzugefügt werden müssen. Oder unten Copyright-Datum wird geändert.

[1:12:10] Das ist ein echtes Problem. Da können mir auch schon ganz, ganz, ganz, ganz viele Gedanken aus den Köpfen rausströmen.

[1:12:16] Ich sehe das, ich würde ein bisschen das mal von der anderen Seite betrachten.
Es gibt ja auch Frameworks, die benennen sich extra um, wenn sie von zum Beispiel auf einer 3 auf eine 4 wechseln.
Und manchmal Manchmal würde ich wirklich in Frage stellen, ob ich überhaupt upgraden muss an der Stelle.
Also wenn Vue 2 und Vue 3, muss ich tatsächlich auf Vue 3 jetzt migrieren?
Bei Bootstrap 3 und 4, muss ich denn tatsächlich so viele Breaking Changes und TechTab mir aufhaltsen?
Oder kann ich nicht einfach da bleiben?

[1:12:49] Und Java und Frontend-Entwicklung zu vergleichen, kann schwierig sein, weil sich gerade in den Clients, für die wir entwickeln, halt so viel geändert hat.
Und da kann ich, da verstehe ich natürlich, wenn Entwickler von anderen Programmiersprachen sagen, was ist denn bei euch da im Frontend und im Web los? Warum müsst ihr denn ständig was Neues lernen?
Ist natürlich auch, weil sich unsere Geräte teilweise zu stark geändert haben.
Ich würde es einfach so, deswegen hier den Raum werfen, muss ich immer alles migrieren und updaten?
Oder habe ich vielleicht nicht sogar eine Web-Architektur, dass ich sagen kann, das da drüben funktionieren, ich mache da den Deckel drauf.
Und wenn ich die Seite weiterentwickeln muss, muss ich sie vielleicht auch von der UX her oder vielleicht mit anderen Architekturen weiterentwickeln, fange aber vielleicht gar nicht mehr wieder an, die Programmiersprache wieder mir neu beizubringen oder entwickle mein Feature einfach anders.
Und jetzt höre ich auf zu reden, weil ich habe so viele Hände hinter mir.

[1:13:48] Ja, das ist ein cooles Thema. Ich glaube, wir können auch erst mal sagen, Frontend ist, ich hoffe, ich mache jetzt keine Feinde, Frontend ist deutlich komplexer als Backend.
Einfach aus dem einfachen Grund, dass wir so viele Browser haben, so viele Geräte haben, das so viel ändert, kann ich da nur Vanessa anschließen.
Ich sehe auch sehr viele nickende Leute, das freut mich.
Ich bin noch nicht der Erste mit der These, aber irgendwann hat das mal sehr, sehr mir resoniert.
Ich weiß nicht, ob man das so im Deutschen sagt, sorry, ich weiß nicht.

[1:14:14] Ja, hier finde ich vielleicht damit keine Feinde, wer auch immer das dann anschaut.
Schreibt mir gerne Hate-Kommentare, ist kein Problem, ist fein, aber bleibt nett.
Zu dem Thema, was Marvin gerade gesagt hat, nochmal, würde ich ganz gerne aufgreifen.
Der Punkt, mit dem, okay, alle Frameworks und vor allem die Meta-Frameworks nähern sich so ein bisschen mehr an und da gehe ich komplett mit, vor allem, wo man dann irgendwann wirklich sagen muss, okay, im Frontend-Ökosystem die neuesten Aplikationen, fast jedes Framework setzt, aktuell auf Vite als Dev-Server und dann Roller, BS-Build und so weiter zum Bundling.
Gibt halt so Ausnahmen wie zum Beispiel Next.js.

[1:14:53] Wir sagen, gut, wir haben TurboPack. Das ist halt unser Eigengewächs in dem Sinne.
Gut, der Tobias, der vorher in Webpack gearbeitet hat, baut da den Nachfolger.
Macht auch Sinn zu sagen, hat der Infrastruktur unter Kontrolle.
Aber an sich, so Open-Source-technisch, geht's halt eigentlich fast alles in die Richtung Vite.
Angular mit dem neuen Release in Vite, Solid, Quick usw.
Ich hab im Chat mal verlinkt, Vinci, weiß ich nicht genau, wie es ausgesprochen wird, wo die Idee ist, kommt aus dem Toll-Universum, zu sagen, man nimmt Beat und Nitro als Basis für Metaframeworks und zu sagen, ich kann meine kleinseitigen Sachen definieren, ich kann meine serverseitigen Sachen definieren, das so ein bisschen als Basis zusammen.
Finde ich einen sehr spannenden Ansatz, um doch zu sagen, vielleicht kriegt man das dann doch eben alles auf den unteren Layern so ein bisschen vereint, und schaut mal, was dann eigentlich der Unterschied ist zwischen den Frameworks, abgesehen von die einen nutzen halt Svelte, die anderen Vue.
Da bin ich mal gespannt, ob die Reise hingeht im Jahr 2024.

[1:15:48] Ich finde, du sprichst da einen sehr guten Punkt an, weil auch so, um auch auf die Frage zurückzukommen, müssen wir updateen.
Ich muss immer noch dran ein bisschen denken, vor ein paar Jahren, in JavaScript haben wir normale Webseiten gebaut und keine Apps, wie wir es heute alle fast als selbstverständlich nehmen. Das heißt, es gab einen riesen Wandel.
Entsprechend viele Frameworks, viele Versuche, wie gehen wir mit dieser neuen Art zu arbeiten um, was ist die beste Methode.
Und ich habe das Gefühl, jetzt so ein bisschen so nach den ganzen Explorationen kommen wir auch so ein bisschen so in die Phase, wo okay, wir wissen so ein bisschen so die Rahmenbedingungen, was brauchen wir, was brauchen wir nicht, und entsprechend gehen wir jetzt auch ein bisschen entspannter ran, wenn es jetzt neue Frontend-Frameworks gibt oder auch, in dem letzten Jahr jetzt sind auch ziemlich viele wieder auf den Signal-Ansatz gesprungen, PRACT inklusive, das ist eigentlich auch so ein Ansatz, wo konzeptionell ist ja ziemlich gleich gut, die einen haben vielleicht nutzende Funktionen, um Getter zu machen, die anderen haben eine Property, Aber konzeptionell ist es das Gleiche und ich habe das Gefühl, jetzt beruhigt sich das wieder so ein bisschen.
Also natürlich, wenn man von außen auf diese Szene schaut, immer wow, da geht ja total viel ab, ist ja alles Chaos.
Aber ich glaube, das ist einfach nur daher, weil wir halt eine ganz neue Art von Entwicklung geschaffen haben, innerhalb sehr kürzester Zeit und jetzt beruhigt sich das wieder.
Und da bin ich eigentlich deswegen besonders gespannt auf dieses Jahr, was jetzt kommen wird, weil das ist auch noch neue Türen vielleicht, wo wir jetzt so eine stabile Basis haben. Was sind jetzt die neuen Sachen, die wir besser machen können? Da bin ich sehr gespannt.

[1:17:13] Ich würde den Gedanken, die Frage nochmal, ob wir überhaupt updaten müssen, auch noch eine andere Frage stellen, ob wir überhaupt Frameworks brauchen.
Das hat mich nämlich letztes Jahr auch geflasht, dass bei meinen Kunden dann gar kein Framework war und nicht mal TypeScript und dass das halt alles auch noch funktioniert und läuft und man dann halt, ja, für Zukunftssicherheit, also JavaScript wird halt JavaScript bleiben und dann hat man auch nicht die Upgrade-Probleme dann.
Oder irgendwie, ja, wie bindet das Framework da jetzt und so, sondern nee, man schaut sich an, wie das mit JavaScript läuft und funktioniert.

[1:17:47] Hatten die kein Framework? Weil ich bin ja der Meinung, man kann ja eigentlich nicht kein Framework haben, weil der Akt des Programmierens an sich ja darin besteht, dass du irgendwelche Strukturen und Standardisierungen und APIs und Abstraktionen schaffst.
Das ist doch ein selbstgeschriebenes Framework, oder nicht?

[1:18:06] Also jetzt kein Standard-JavaScript-Framework wie Angular, React oder so von den Großen. Hm. Sondern halt.
Ja. Ja, also weil ich meinte ja nur ein bisschen auf den Rückgriff von den Web-Components von vorhin, wo wir ja auch so darüber sprachen, um Himmels Willen, sowas kann man doch nicht selber leisten.
Das kann man halt eben schon, indem man es halt eben einfach nicht macht, macht man es dann gleichsam automatisch.
Es ist natürlich von Vorteil, wenn man dabei dann darüber nachdenkt, was man tut und ein bisschen Ahnung hat und tatsächlich sich vielleicht umgeschaut hat im Ökosystem, was es da so gibt und sich da die besten Ideen geklaut hat.
Aber das ist halt wirklich so ein Ansatz, den würde ich ja gerne mehr sehen.
Weil ich meine, auf der einen Seite kann man natürlich argumentieren, wie einige von uns das bisher gemacht haben, von wegen, es findet eine Harmonisierung und Standardisierung statt, von der ich jetzt auch selber noch nicht so unbedingt überzeugt bin, weil ich nicht weiß, wie viel mein Blick auf die Welt tatsächlich jetzt beinhaltet, ob ich nicht links und rechts der Scheuklappen irgendwas übersehe.
Aber selbst wenn das so wäre, wäre es ja trotzdem gut, wenn irgendwo noch lustige Ideen ausgekocht würden.
Das wäre dann halt auch so mal vielleicht mein motivierender Aufruf an die versammelten Nerds.
Man kann sowas auch selber machen. Da gibt es eigentlich kein Verbot.
Das ist nicht irgendwie was, was irgendwie unmöglich ist und schwer zu schaffen ist.
Vielleicht wird es nicht gut. Oder vielleicht wird es nur einen eingeschränkten Use Case bedienen können. Aber man kann es ja mal probieren.

[1:19:34] Ja, so ein bisschen hat man das, glaube ich, vor einem Jahr oder was vielleicht doch, ich glaube, vor einem Jahr in unserer Folge zum State of Jazz, glaube ich.
Also da haben wir auch so ein bisschen das Thema besprochen und eben auch die Tatsache, dass man sich so ein bisschen unabhängig macht von diesen von außen hereingetragenen Breaking Changes, ist, wenn man Dinge eben selber, baut, auch wenn man eben langsam ist, aber ich glaube, das kommt ja auch immer auf den Kontext an.
Also in einem Agenturumfeld würde ich das niemals machen.
Da muss man einfach schnell liefern und auch irgendwie Garantien abgeben, bis man fertig ist und gleichzeitig hat man natürlich die Möglichkeit auch viel auszuprobieren, aber wenn man eben an einem Produkt baut, das lange lebt, da finde ich, macht das schon mehr Sinn.

[1:20:26] Da gibt es auch viele Plug-Artikel dazu, also wie man sich sein eigenes Framework baut, also mit Template-Literals und sowas ist das ja alles relativ simpel möglich.
Die Sache ist nur, am Ende baut man ja auch bloß wieder irgendwas nach.
Also am Ende komme ich auch bloß bei was raus, was letzten Endes in einem anderen Framework sehr ähnlich ist. ist.
Und zu dem Thema Updates nochmal, also ja, das ist halt auch, wenn man ein Projekt nach einem Jahr aufmacht und man muss irgendwie NPN-Update oder sowas machen, das ist ja auch einfach bloß eine Hölle.
Also man hat halt so viele Abhängigkeiten drinnen und dann wirft der Compiler einen raus, dass da Paket Y abhängig von X ist und das hat aber eine zu geringe Version, also Updates ist tatsächlich so ein Ding, wo ich auch immer sehr mit hartere.

[1:21:05] Aber trotz Package-Log und solchen Konzepten, also ich finde, dass die das ja ja ganz gut gelöst haben, das Problem.
Also das quasi so die erste Person, die das einmal, die quasi den Install macht, die Versionsnummern dann festnagelt und sofern alle eben bei der gleichen Notversion bleiben, was ja bei NVM dann möglich ist, dass man dann so da die Sicherheit hat, dass das überall reproduziert die gleichen Pakete sind.
Aber du willst ja updaten wegen der Sicherheitslücke. Der einen Sicherheitslücke in dem einen Paket und danach ist nichts mehr mit irgendwas kompatibel. Das ist das Problem.
Ja, genau. Aber es kommt ja immer drauf an.
Also ob das wirklich notwendig ist, weiß ich nicht.
Also man muss sich, glaube ich, dem auch so ein bisschen widersetzen.
Kannst du nicht. Vor allem, wenn es in deiner Builder-Chain drin ist.
Sorry. Es kann schon selbst bei Install-Probleme geben, wenn halt die Versionsnummern nicht festgeschrieben sind. Also wenn in deiner Package halt nur so Kurbelwässerns nochmal entstehen, dann kannst du auch da schon, wenn du ein Projekt hast, nach Jahren wieder aufmachst, kannst du da durchaus probieren können.
Ich glaube, wenn du eine Log hast... Ich bin auf Node 0.10. Das läuft. Hey.
Wenn du eine Package-Log hast, sollte es ja eigentlich ausreichen, zu sagen, bitte installiere genau die Version, die in der Log vorhanden ist.
Selbst wenn du dann eine Version mit Carrots... Natürlich, die Version zu pinnen macht auch viel Sinn, denke ich.

[1:22:35] Das große Problem natürlich, wenn wir aber Millionen von Packages haben, im Vergleich zu allen anderen Package-Ökosystemen, ist ja das JavaScript-System das das vielfältigste mit seinen schönen vielen Vorteilen und auch Nachteilen.
Ihr kennt ja alle die klassischen Is-Even, Is-Odd, die guten Pakete und zu schauen, ob die Zahl gerade oder ungerade ist. Solche Geschichten.
Das Update-Thema ist dann entsprechend tricky. Ich glaube, solange man halt reproduzierbare Builds hat, sagt man gut, auf der Node-Version läuft es, alles in Ordnung.
Sobald es Sicherheitslücken gibt, muss man natürlich gucken, ist es nur für den Build- oder Dev-Prozess relevant, ist es was, was in Production Probleme bereitet, kann immer noch abwägen, sagen, will ich das jetzt upgraden, fixen oder ähnliches.
Aber am Ende, klar, wenn man nach drei Jahren ein Frontend-Projekt aufmacht, kann es gut sein, dass sehr viel Arbeit erwartet und man lieber sagt, vielleicht schreibe ich das Ding doch nochmal neu.
Das ging vielleicht einigen schon mal so bei Side-Projects, wo man sagt, ah, ich habe jetzt nochmal Zeit und dann füllen wir es vielleicht doch nochmal weg.

[1:23:36] Zu dem Punkt kein Framework oder Framework, das fand ich auch nochmal ganz interessant, weil das ist ein Thema, was mich sehr viel beschäftigt, weil eben, auch bei mir viele Leute sagen, ja, okay, warum muss ich denn jetzt Frameworks Y benutzen und bin dann eben abhängig versus ich kann mir mein eigenes bauen und da hatten wir jetzt auch schon ein bisschen, Peter ja auch schon was zu gesagt, was in die Web Components ging, Ich glaube, ein großer Vorteil, der hier noch so halb beleuchtet wird, ist halt das Thema Open Source.
Dass man also sagt, okay, ist es vielleicht nicht nur die, keine Ahnung, 10, 20, wenn man Glück hat, oder drei Entwickler aus der Firma, sagt, okay, wir gucken und bauen das jetzt mal selber, oder das eine Team, oder die zwei Teams, sondern das sind halt so viele Augen, so viele Möglichkeiten, Bugs zu reporten, natürlich auch, dass es so vielfältig eingesetzt wird.
Wenn man natürlich jetzt sagt, okay, wisst ihr was, wir bauen unser eigenes Open Source Framework für einen bestimmten Ansatz, ist das auch erstmal ein guter Start, aber auch da braucht man natürlich, um vielleicht mehr Bugs zu finden oder mehr Szenarien abzudecken, ja auch irgendwie ein bisschen die kritische Masse, um das wirklich so, ich sag mal, Battleteste zu machen, wie es jetzt die größeren Frameworks sind.
Weil ich glaube, das ist noch ein großer Punkt.
Ach, und dann kriegst du auch noch ganz andere lustige Probleme, sobald du das machst.
Ich hatte letztens einen Spaß mit einem Bug, den ich hatte, weil ich hab TypeScript verwendet und.

[1:24:52] Ein anderes Package von von einfach irgendeinem Open-Source-Menschen, der halt sowas gebaut hat, was halt hier Tag-Template-Distributes für Virtual-DOM-Rendering-Zeug machte.
Und das war halt eben nach einem Update von TypeScript nicht mehr kompatibel.
Und dann bin ich halt im Bug-Tracker von der entsprechenden Library aufgeschlagen und hab dem Menschen gesagt, hey du, hier deine Library funktioniert mit der neuesten TypeScript-Version nicht.
Und die Antwort von dieser Person war dann natürlich, ihr ganzes TypeScript-Heinis geht mir einfach gewaltig auf den Keks.
Ich nutze die Library nicht, ich will nichts mit der zu tun haben.
Meine Library hat nur Typdefinitionen, weil irgendwer da mal einen Pull-Request für gemacht hat.
Und jetzt hat diese andere Library, nämlich TypeScript, einen Update gemacht, mit der ich nichts zu tun habe, wo ich keinen Einfluss drauf habe, die ich nicht benutzte, die ich nicht mal gut finde, die ich nicht unterstützen möchte.
Aber weil ich jetzt hier meine kleine Open-Source-Library betreibe, rücken jetzt lauter so Leute wie du an und mürpeln rum, dass mein Produkt kaputt geht, das quasi eine implizierte Dependency hat auf etwas, das niemand sich jemals ausgesucht hat.

[1:25:50] Was ich schon relativ krass finde. Aber da würde ich halt rangehen und sagen, zum einen Open Source, einige Leute, die Open Source unterwegs sind, wissen, ja, jeder PR, den man mergt, bedeutet halt auch, okay, man muss halt das Feature dann maintainen.
Heißt also, wenn ich Type Definitions hab und dann sagt, oh, die gehen kaputt, ich wollt's echt gar nicht, kann man von vornherein sagen, hey, nimm doch Definitely Typed, ist mir egal, pack das da rein, ich will das nicht supporten.
Und auf der anderen Seite kann man genauso sagen, ja, es ist halt Open Source, Open Source Maintainer, die sind da nicht dafür verantwortlich, dass jetzt dein Projekt kaputt geht in dem Sinne.
Heißt, okay, wenn man das wirklich fixen möchte, dann ab damit mit einem PR.
Ich würde immer noch behaupten, dass es zeitlich weniger Aufwand ist, zu sagen, natürlich jetzt, wie groß das Framework und Kurs, als zu sagen, ich baue das selber und entdecke dann vielleicht irgendwann Fehler und so weiter und so weiter.

[1:26:38] Ja, ich wollte nur sagen, irgendwie, die Darstellung, die wir ja zuvor in der Diskussion hatten, von wegen man sucht sich seine Dependencies aus, dass das tatsächlich so einfach auch immer nicht sein kann, weil sozusagen dem Rufe des TypeScripts zu widerstehen, auch wenn man das selber nicht benutzen möchte, aber irgendwie tausend Leute auf einen einquatschen, man möge das doch bitte irgendwie eben machen.
Hey, akzeptiere diesen PR mit dieser einen Datei, wie schlimm kann es schon werden? Das verlangt, glaube ich, dann auch Weitsicht und Widerstandsfähigkeit, die man, glaube ich, nicht von allen Menschen, die so ein Open-Source-Library machen, erwarten braucht. Ja, absolut. Das gebe ich dir für recht.

[1:27:14] Dieser Dependency-Kram ist komplizierter als Update ja oder nein, Nein, sondern halt irgendwie, da gibt es eine ganze Menge implizite Sachen, Einflüsse, die da auf einen einwirken, Sub-Sub-Subdependencies, Sicherheitslücken.
Das ist schon ein relativ komplizierter Zirkus, glaube ich, und ich weiß gar nicht, ob man da so als Individuum groß was dran machen kann oder ob das jetzt einfach so eine Art Naturgewalt ist, mit der man sich jetzt arrangieren muss. Keine Ahnung.
Im meisten Fall muss man sich damit arrangieren, weil auch da, man kommt in solche Projekte rein und hat im wenigsten Fall so, ja, Greenfield, wir können jetzt entscheiden, wir setzen uns zum Beispiel auf das Framework und dann nehmen wir nur die Libraries, die einen großen Teil Arbeit abnehmen und den Rest bauen wir selber.
Es ist ja doch oft auch so, dass man sagt, man kommt vielleicht in Projekte und dann sind dann hier hunderte Pakete, wo man vielleicht die Hälfte gar nicht mehr braucht oder es nicht mehr enthält.
Das ist ja nochmal die nächste Stufe. Aber ja...

[1:28:00] Ja, die spannende Frage ist, was ist da für die Entscheidungsgrundlage?
Also wie diskutiert man das?
Wie framet man das? Durch welche Linse guckt man darauf, um diese Entscheidung zu treffen?
Ich habe da für mich persönlich keine vernünftige und das irritiert mich sehr.
Also außer halt eben so Brauchgefühl von wegen, die Erfahrung sagt mir, da kannst du dich nicht darauf verlassen oder das ist seit Ewigkeiten einfach zuverlässig und meine Erfahrung sagt mir, das funktioniert seit Ewigkeiten.
Aber wie geht man dann mit irgendwelchen neuen Tools um, die da um die Ecke kommen?
Also wie bewertet man die und wie entscheidet man, ob man das jetzt in seine Welt integriert oder nicht?
Wo man ja weder über sein eigenes Projekt notwendigerweise weiß, wo sich das hin entwickelt, noch über dieses Tool weiß, wo es sich hin entwickelt im Laufe der Zeit.
Das sind ja sämtliche Unbekannte und ich habe kein vernünftiges mentales Framework, um das zu jonglieren und das finde ich doof.

[1:28:47] Ich sag mal, eine kleine Abschätzung wäre halt erstmal zu sagen, man guckt sich den Code an und sieht, okay, es sind vielleicht zwei Dateien.
Macht es jetzt Sinn, das Paket zu installieren? Oder will ich vielleicht einfach die zwei Dateien kopieren und bin dann selber für die Implementierung und das weitere Bugfixen verantwortlich?
Ich glaube, das ist erstmal ein guter Start, dann zu sagen, okay, lohnt sich diese Dependency wegen zwei Dateien oder kriegen wir das vielleicht selber gefixt und übernehmen die einfach, geben Credits, alles gut, können trotzdem ab und an mal gucken, ob es noch welche Bugfixes gab, schreibt einen Kommentar und gut ist.
Ich glaube, schwieriger wird es natürlich dann bei großen Libraries, vor allem auch eher größeren, unpopulären Libraries, wo man sagt, ah, dann gibt es da Komplikationen und so weiter und so weiter.
Ja, das ist tricky. Aber ich glaube, da spielen sehr viele Faktoren und Rollen von hinten. Wer hat das? Wer schreibt das?
Ist das jemand, der regelmäßig Open-Source unterwegs ist, der vielleicht sogar, Vollzeit-Open-Source, was ja tatsächlich einige Leute auch machen, unterwegs ist, sagt, okay, da gibt es eher eine Chance, dass da Updates kommen.
Wie viel Nutzer hat das? Wie populär ist das? Auch keine Garantie.
Gibt es nie, aber es sind zumindest so Indikatoren.
Vielleicht kann ich ganz kurz da einmal rein, Peter.
Ja, genau. Weil wir hatten auch noch ein paar Wortmeldungen.
Fabian hat seine Hand jetzt schon wieder runtergenommen.
Jetzt wollte ich vielleicht nochmal da nachfragen. Fabian, ich nehme an, du wolltest vielleicht ein bisschen in eine andere Richtung, aber vielleicht können wir das trotzdem machen.
Ja, ich hätte nur zu dem Punkt vorher noch mit, wenn man das eben selber baut und nicht auf den Framework gesetzt, haben wir vor ein paar Jahren bei uns in der Firma mal versucht und wir haben ein langläufiges Produkt, also jetzt keine Agentur, sondern schon eine Software, die viele Jahre läuft, und wir sind davon wieder weg und ich finde das gut, weil.

[1:30:15] So am Anfang war das ganz cool und konnten wir das so machen, wie wir es brauchen und so weiter, aber dann hast du irgendwann am Ende merkst du, was Falk auch schon meinte, am Ende baust du irgendwie, wie funktioniert Routing, wie funktioniert State, wie funktioniert dies, das Und die Probleme haben andere Leute einfach schon mal besser gelöst in einem größeren Team mit mehr Hirnschmalz als man selber, sondern baust du das nochmal nach und es ist in der Regel schlechter dokumentiert, schwieriger für Leute anzuborden, die die Konzepte bei dir nicht kennen, die andere Frameworks aber schon kennen, die kommen viel schneller rein, wenn du auf was setzt, was schon halbwegs bekannt ist und so weiter.

[1:30:47] Deswegen war ich jetzt so, wie es zumindest bei uns gelaufen ist, von dem Ansatz am Ende nicht überzeugt und bin ganz froh, dass wir wieder auf eines der großen Frameworks setzen, wo du auch Bewerbern einfach sagen kannst, hey, wir benutzen Framework X und die sagen, ja, kenne ich, finde ich cool, habe ich Bock mitzuarbeiten und sind recht fix ongeboardet und sind am Start.
Und du kannst dich dann wirklich auf fokussieren, wie lösen wir Probleme für unsere Kunden und wie bauen wir Features für unsere Software und nicht, wie bauen wir das Ganze drumherum, was andere schon machen.
Ich bin dort auch noch ein Punkt, also ich bin selber auch Maintainer von diversen Open-Source-Projekten, wie der Marvin ja auch und für mich jetzt, wenn ich jetzt ein Framework aussuche, auch immer so ein Punkt, wo ich schaue, wie ist die, Community, also jetzt gar nicht nur, wie ist der Code und wie ist die Qualität, klar schaut man auch drauf, das ist manchmal auch ein bisschen schwer durchzusehen, sondern zum Beispiel auch zu schauen, wenn jetzt jemand kommt mit einem PR, wie lange dauert es, wo jetzt wirklich nur nicht, ich mache Types, wo es heikel ist, wie vorhin erwähnt, sondern wirklich ein Bug-Fix, wie lange dauert es, bis was gemerged wird, wie lange dauert es, bis was released wird, ist für mich auch immer relativ wichtig, weil wenn ich ja was verwende, muss ich ja damit rechnen, dass ich irgendeinen Use-Case habe, wo ich auf was stoße, da ist irgendwo ein Bug, weil.

[1:32:07] Es gibt ja quasi kein fehlerfreies Framework und da ist für mich dann schon wichtig zu wissen, okay, ja, wenn ich jetzt was entdecke und wenn ich ein PR mache und den auch sauber aufbaue, dass es dann nicht irgendwie fünf Jahre dauert, bis das gemerged ist.
Und das ist jetzt nicht dahergeredet. Also ich habe wirklich ein paar PRs offen oder die haben Jahre gebraucht, bis da irgendjemand da mal reingekommen ist und gesagt hat, ja okay, können wir merchen.
Das waren dann nur so kleine Sachen wie ein Post-CSS-Plugin, wo was falsch war.
Und das finde ich auch immer so bei der Auswahl von einem Framework auch noch so ein wichtiger Punkt, wie ist die Community, ist die neben den Code-Qualität, ist die freundlich, ist sie nicht irgendwie, oder lässt sie nicht irgendwann alles liegen und ist natürlich klar, wenn ich jetzt ein Framework nehme, wo nur eine Person maintained, ist es natürlich ein viel größeres Risiko, dass man da irgendwie nie einen Fehler gefixt kriegt und am Schluss irgendeinen eigenen Fork sich nehmen muss und den dann weiter annimmt, weil das einfach nicht gemerged steht, also alles schon erlebt.

[1:33:18] Ich finde, das ist eine sehr wichtige Diskussion. Weil es ist auch ein Thema, wo ich auch als Maintener ein bisschen nicht weiß, ganz wie ich damit umgehen soll.
Weil es gibt einerseits so Projekte, wo man sagt, okay, Projekt wird es auch wirklich, viele Firmen das nutzen und so, da ist schon die Erwartung, dass es wie ein Produkt behandelt wird.
Sprich, dass es auch maintained wird und Bugfixes rechtzeitig reinkommen.
Aber andererseits gibt es auch so Sachen, wo ich einfach mal aus lustiger Laune was geschrieben habe, einfach gesagt, okay, komm, ich hau den Code einfach online, vielleicht findet jemand anders das so sinnvoll. voll.
Aber jetzt nicht mit dem Gedanken, ich mache jetzt ein volles Produkt, ich supporte das jetzt bis in alle Ewigkeit und ich maintaine das jetzt für immer.
Das ist irgendwie schwierig, weil sobald man irgendwie Code Online stellt, erwarten alle, dass man das auf alle Ewigkeit maintained und supportet und Fragen beantwortet.
Und ich habe auch, ich meine, keine Ahnung, ich habe 350 Repositories auf GitHub öffentlich oder so.
Ich kümmere mich vielleicht um fünf, wenn ich ehrlich bin, weil ich habe einfach nicht die Zeit dazu, mich um alle zu kümmern, weil dann würde ich nichts anderes mehr in meinem Leben machen.
Und das ist auch so ein bisschen schade, weil eigentlich sagt die die MIT-License, ganz klar, hier ist der Code, mach, was du willst, mehr oder weniger.
Aber es ist halt mittlerweile irgendwie immer so eine Erwartung, sobald es auf GitHub wird, alles müssen maintained werden, rechtzeitig beantworten und ich muss ganz ehrlich sagen, ich schaffe das nicht, ich schaffe das nur halt bei den populärsten Projekten wie Project.

[1:34:37] Da steht das irgendwo bei deinen Projekten quasi oben direkt dran, dass du sagst, hier, das ist nur so ein kleines Projekt, das wird nicht maintained, wenn ihr das benutzt, passt auf, kümmert euch selber oder Oder ist das für jemanden, der es benutzen will, sofort ersichtlich?

[1:34:52] Ja, vielleicht ist es gut, dass er anspricht. Vielleicht ist es einfach ein Thema, wo man richtige Erwartungen setzt, dass man halt direkt irgendwie in den Readme schreibt, hey, ist nur ein Hobbyprojekt.
Nutzen auf eigene Gefahr oder ähnliches. Vielleicht soll ich das mehr machen.
Es gibt auch so die Badges mit den drei Herzen.
Wenn du drei Herzen hast, werden sie selber noch aktiv verwendet.
Zwei Herzen, ja gut, wir schauen, wenn was kommt.
Und ein Herz, ja, schau selber, wo du hinkommst.
Freunde von mir machen das auch so und das finde ich eigentlich schon noch ganz cool, weil du dann siehst, ja okay, siehst du ein Package und sagst, okay, das kann ich dann, jetzt kann ich es entweder verwenden oder aber ich sage, ich nehme es als Inspiration und baue das halt noch aus oder schreibe die an und sage, hey Jungs, ist es in Ordnung, wenn ich das jetzt da übernehme?
Das ist natürlich auch schon passiert, dass ich dann gesagt habe, ja, das Package ist für mich extrem wichtig.
Verwende ich viel, habe die meisten Bug-Reports, die meisten Fixes gemacht.
Und so, wo dann die Leute gesagt haben, du, ich setze dich als Maintainer rein, wo du quasi die Rechte kriegst über das Repo, kannst selber releasen, kannst merchen, weil du eh der bist, wo am meisten da rumfurzt.
Also da gibt es schon Wege, wie man das machen kann. Klar, als Einzelmann oder Firma ist es schwer, alles immer zu beantworten.
Aber für mich ist natürlich auch bei einem Framework immer so, es steht und fällt ein bisschen mit der Dokumentation.

[1:36:19] Und da habe ich selber gemerkt, wenn man sich selber dann mal in die Nase nimmt und das Zeug mal ein bisschen niederschreibt und sich die Zeit nimmt, dass man dann schon sehr viele Fragen, wo dann da reinkommen könnten, vorweg nimmt und dass dann auch der Aufwand kleiner wird, wenn man da ein bisschen, wenn man auf GitHub die Wiki-Seiten benutzt oder was auch immer, ist gar nicht nicht so viel Aufwand, dass man sowas hat gemacht, also, aber klar, ähm.

[1:36:47] Es ist manchmal auch krass, was man da für Kommentare kriegt.
So, hey, du hast das geschrieben, jetzt musst du das fixen.
Und dann denke ich so, ich muss gar nichts. Also der Ton ist manchmal schon heftig.
Also da habe ich schon Kommentare gekriegt, wo ich gedacht habe, in welcher Welt lebst du?
Ich mache das in meiner Freizeit oder ich mache es als Einzelfirma.
Habe ich das gemacht, nehme es als Inspiration. Aber der Ton geht gar nicht.

[1:37:12] Ja, es gibt halt beide Seiten. Also das ist schon...
Und mich würde es sehr interessieren, vielleicht mag da jeder kurz die Hand heben, muss jetzt nicht jeder was sagen, aber jeder kurz die Hand haben, wer auf der Arbeit, also für das Projekt, für das man so Geld bekommt, schon entscheiden musste, auf welches Framework man setzt oder auch auf irgendwelche Libraries vielleicht die größer sind.
Und ich sehe jetzt zwei, drei, vier Händchen. Wer auch immer was sagen, oh, einige Händchen.
Wer auch immer zuerst loslegen möchte, wie habt ihr denn entschieden und habt ihr auch euch Sorgen gemacht, ob die Entscheidung dann falsch ist oder was passieren könnte, wenn sie falsch war?
Ja gut, Sorgen, dass sie falsch ist, die Entscheidung, die hat man, glaube ich, immer.
Bei dem Projekt, wo ich jetzt drin bin, bin ich quasi verantwortlich im Frontend.
Als Architekt zu sagen, was wir jetzt nehmen und was wir eher nicht nehmen und das ist ganz klar, dass man manchmal schon ein bisschen Blut schwitzt, zu sagen, ist das jetzt die richtige Entscheidung, weil ja quasi die Projekte laufen ja über mehrere Jahre, bei einem sind wir jetzt fast sechs, sieben Jahre dran und es wird wahrscheinlich nochmal so lange dauern und wird halt Stück für Stück ausgerollt und klar, das ist ist.

[1:38:35] Ist natürlich auch immer wieder dabei, wenn man sagt, jetzt nehmen wir doch was anderes.
Gab es auch schon ein paar Mal bei den größeren Projekten, wo du sagst, jetzt baust du es wieder um.

[1:38:48] Ja, wir haben bei uns letztens auch den Stack gewechselt, wie schon ganz am Anfang ganz kurz angesprochen, sind wir halt im SAP-Umfeld und haben halt vor ein paar Jahren, als es angefangen hat, auf die Sachen von SAP gesetzt und die sind, wenn man es jetzt mit moderneren Frameworks vergleicht, mit irgendwie MVC und XML-Views und so, das macht nicht mehr so richtig Spaß, wenn man mal ein moderneres Framework benutzt hat und auch das Onboarding von Leuten ist halt hart, weil du niemanden findest, der sich damit auskennt und so weiter.
Das heißt, das waren bei uns halt Kriterien, als wir irgendwann gesagt haben, so jetzt, wie machen wir neue Projekte, dass ich halt auch irgendwie versucht habe, zusammen mit Recruitern bei uns in der Firma rauszufinden, was sind denn auch Sachen, womit Leute gerne arbeiten, auch sowas wie State of Jazz insofern nicht spannend zu sehen, wo haben auch Leute Bock drauf, das Umfeld Leute zu finden ist eh hart und einerseits, was können Leute, aber womit haben Leute auch Bock zu arbeiten, so ja, React kann jeder so ein bisschen, aber wollen die Leute das überhaupt oder gibt es andere Sachen, wo die eigentlich richtig Bock drauf hätten, aber die Firmen das immer nicht machen. Also das waren so Gedanken.
Klar guckt man auch ein bisschen Verbreitungen so, aber ich meine, die meisten Standard-Use-Cases, die man so hat, die kriegt man mit allen der großen Frameworks irgendwie gelöst.
Da hatte ich jetzt nicht so ein paar Tests hier und da, hatte ich jetzt nicht so die Probleme.
Und dann hat auch einfach Präferenzen im Team so ein bisschen abgefahren, was ist so vom Feeling, wo kommt ihr schnell rein, was macht euch Spaß zu lesen und so.
Und bei uns war halt relativ schnell klar, dass wir so aktuell wie Single File Components ins Welt und View geschrieben werden, das Ding sind, wo da guckst du mit einem Blick drauf.

[1:40:15] Liest natives HTML und CSS, verstehst, was da vor sich geht, dass das bei uns im Team relativ schnell ein Konsens war, wo alle gesagt haben, so haben wir eigentlich Bock zu arbeiten, das macht uns Spaß.

[1:40:25] So sind wir da rangegangen.

[1:40:32] Ich glaube, gerade mit einem Team, was bereits jetzt existiert, da muss man natürlich gucken, wie so der Kenntnisstand ist.
Also wenn du sagst, du hast jetzt einen neuen React-Developer und einen Angular-Entwickler, dann zu sagen, wir nehmen Angular, ist vielleicht tricky, außer man sagt, wir brauchen das halt für den spezifischen Use-Case und da hat das eben den Vorteil gegenüber allen anderen Frameworks, deswegen machen wir das jetzt.
Wenn man natürlich sagt, man baut irgendwie neu auf oder sagt, wir brauchen eigentlich eh, wir haben nur drei Leute, brauchen eigentlich zehn und müssen recruiten, dann sieht das natürlich nochmal anders aus.
Ich kann ein interessantes Szenario berichten. Ich war mal als SSR-Experte, wenn man das nennen möchte, bei einem Projekt mit dabei, was zusammen mit einer Agentur realisiert wurde.
Und da wurde sich auch für ein Tech-Stack, für ein Framework entschieden.
Und nach einem halben Jahr hat das Team dann gesagt, ey, haben wir keinen Bock drauf und wir können eigentlich auch alle React, also wir schreiben jetzt neu.
So einfach zu sagen, gut, okay, wir ändern das jetzt. Und ja, die Performance war ja auch schon viel besser und irgendwie ein paar Tests.
Das war auf jeden Fall auch sehr spannend zu sehen und hat auch nochmal ganz gut gezeigt, es ist sehr wichtig, was das Ziel davon hält in dem Sinne.
Ob es besser oder schlechter geworden ist, dahingestellt, aber das war eine ganz interessante Erfahrung, die ich so auch noch nicht hatte.

[1:41:51] Vielleicht ein Aspekt nochmal. Das Ganze vom User her gedacht, von dem Endanwender her gebracht.
Was braucht er eigentlich? Was bauen wir eigentlich für Anwendungen?
Und da vielleicht auch nochmal die Referenz zu diesem Abschnitt aus Microsofts Microfrontends in Action Buch, wo so ein bisschen beschrieben wird, was für eine Applikation bauen wir eigentlich?
Eigentlich sind es mehr Dokumente, die wir haben, oder ist es eine wirkliche Anwendung? Daraus abgeleitet mache ich Server-Side-Rendering oder Client-Side-Rendering.

[1:42:23] Ja, der Aspekt ist ja durchaus auch relevant.
Also was braucht der Kunde? Was ist gut für ihn? Und wir sind relativ schnell dazu gekommen, also das, was wir eigentlich haben, das sind eigentlich mehr Seiten, deswegen Server-Side-Rendering.
Das schränkt die Wahl schon mal ein bisschen mehr ein in der Frameworks.
Und dann, was habe ich für Mitarbeiter natürlich, ja, bei uns im Unternehmen, fünf Produkte, riesige Produkte, die alle in Java entwickelt sind und jedes Produkt hat, weiß ich nicht, Seiten mit 100 Tabellen, also hunderte Seiten, wo Tabellen drauf sind, die willst du nicht alle loslassen, dass die jedes Mal von Grund auf neu wieder ihre Tabelle bauen, dann musst du schon irgendwie was davor bauen, also wir haben es, auf die bestehenden Frameworks oder Bibliotheken, die wir verwenden, auf jeden Fall nochmal eine Schicht davor gebaut, weil wir zum Beispiel sicherstellen wollen, dass wenn ich in der Tabelle eine Spalte dazu füge, dass die auch ein- und ausgeblendet werden kann über einen Button, der natürlich meistens nicht zu diesem.

[1:43:32] Tabellen-Bibliotheksbaustein gehört. Den muss man halt selber dazu bauen und wir wollen es den Anwendern da möglichst einfach Also den Entwicklern einfacher machen, die Tabelle so aufzubauen, dass es konsistent ist an allen Stellen und dass sie eben nicht runter auf das HTML müssen und alles quasi von Grund auf neu bauen.
Ich habe da vielleicht noch kurz zu, was Vanessa vorgestellt hat, was ist falsch und was ist richtig.
So wie der Alexander gerade gesagt hat, ich habe mich im Rahmen meiner Masterarbeit jetzt gerade damit beschäftigt, ein wenig so die Historie zurückzuschauen, also 30, 50 Jahre, richtige, falsche Technologieentscheidungen.
Und wie er gerade gesagt hat, wenn man ein Produkt oder nach sechs Monaten draufkommt im Team, dass man sich einen neuen Framework baut, dann ist das der Umstieg normalerweise eh gar, also ist eh machbar, weil das Wissen, das man aufgebaut hat, ist ja eher dieses, Domänenwissen und das Wissen, wie die Anwendung überhaupt geschrieben wird und was das im Endeffekt dann für Technologie ist, im Endeffekt, wie wir vorher gesagt haben, sind alle die Frameworks sehr, sehr ähnlich und natürlich trifft man am Anfang eine Entscheidung, aber wie definiert man falschen, wie definiert man richtig und das sind im Endeffekt nur means to an end und das Wissen, das man im Laufe der Zeit aufbaut, ist eh dann übertragbar von A bis Z eigentlich.

[1:44:52] Mir fällt gerade noch dazu ein, ich habe ja auch irgendwie behauptet, man kann ja auch immer dann für genau den Anwendungsfall die richtige Technik benutzen.
Das sage ich in der Theorie öfter, in der Realität sage ich das nie. In der Realität...
Haben wir jetzt selber an der Website, ich meine, die Landingpages ist so ein Klick-Dingsbums, damit habe ich gar nichts zu tun, aber ansonsten haben wir gerade auf den ausgelockten Seiten so ein paar Web-Components, weil da brauchen wir kein JavaScript-Framework, aber halt so ein bisschen JavaScript für Passwort-Validierung, also nicht Passwort-Validierung, aber ob das neu gesetzte Passwort allen möglichen Regeln entspricht.
Und auf der Webseite an sich, dann ist es fast ausschließlich Vue.js wieder ein bisschen Web-Components.

[1:45:34] Hier und da hätte vielleicht mal was anderes, also gerade, ich glaube, so PetitVue oder Astro oder irgendwie sowas von diesen kleinen, hätte vielleicht hier und da besser gepasst, aber dann haben wir uns stattdessen da an der Web-Component wieder benutzt, weil ansonsten habe ich das Problem, was jetzt viele hier erwähnt haben.

[1:45:50] Dann habe ich halt diesen mentalen Switch und stattdessen sage sage ich, vielleicht ist das jetzt nicht 100% technisch das absolut Perfekte, aber das ganze Team weiß, wovon ich hier an der Stelle spreche.
Unser Team ist jetzt natürlich auch super klein. Das heißt, ich habe jetzt nicht irgendwie ein React-Team und ein Vue.js-Team, wie ich es bei anderen Firmen vielleicht auch schon mal gesehen hatte.
Ich finde den Punkt ganz gut mit dem, theoretisch gibt es halt passendere Tools für Szenarien, aber wie hoch ist eben der Overhead dann zu sagen, wir nutzen das Ganze, wir lernen uns vielleicht da ein.
Wir brauchen auch jemanden, der dann entsprechend das Wissen hat.
Hat, sonst fängt man ja wieder bei zumindest nicht 0, aber so 20% an, sei es ein anderes Framework, andere Ansätze und Co. und vor allem was für einen Impact hätte das?
Weil ich immer das hätte, hätte voraus, aber wenn wir jetzt wirklich sagen, wir nutzen keine Ahnung, Svelte statt Vue oder React oder ähnliches für einen Anwendungsfall, ist das was, was uns am Ende bessere Conversions bringt?
Ist es am Ende was, wo man sagt, okay, das macht einen großen Unterschied?
Ich glaube, gerade bei sowas wie Data Visualization ist halt ganz nett, dass man sagt, gut, auf den Low-End-Devices funktioniert das super, läuft das performant, das ist natürlich wichtig zu bedenken, aber am Ende eben die große Frage, was bringt uns da generell ein neues Tool, egal in welche Richtung, nicht mal Framework dafür einzusetzen, im Vergleich dazu, was wir halt an Overhead zum Lernen, Maintain und Co. bräuchten.

[1:47:08] Ja, voll. Also wie schon gesagt, bei mir verspreche ich mit dem Team eigentlich eine Verbesserung in der ganzen Hinsicht, weil ich denke, wir setzen jetzt mehr auf Sachen, die weiterverbreitet sind, die mehr Leute kennen, auf die mehr Leute Bock haben und so weiter.
Aber es ist ganz cool, einer bei mir im Team wird jetzt auch eine Bachelorarbeit genau über den Vergleich schreiben und eben verschiedene Vor- und Nachteile dann auch vergleichen.
Eben auch, auch ein Punkt dabei ist eben genau wie du gesagt hast, ist das jetzt nur für uns als Entwickler cool, was schon hilft, um eine wartbare Software zu schreiben, die noch ein paar Jahre leben soll, also ist DX nicht ganz unwichtig, aber dieses nur weil es eine coole Developer Experience ist, kommt dann am Ende auch was Cooles für die User aber raus oder haben wir als Entwickler halt Spaß, aber die Features sind trotzdem scheiße, das ist natürlich nochmal ein ganz anderer Punkt, und natürlich was ich mit dem Produktteam dann immer diskutiere, sagen, hey, warum wollt ihr hier den riesen technischen Umbau machen, was bringt es denn Usern denn am Ende, da muss kommt da auch genug bei raus?
Oder ist es halt, weil wir Entwickler halt Spaß dran haben, mit coolen neuen Sachen zu arbeiten?
Absolut. Ich glaube, das ist immer das klassische Problem auf der einen Seite.
Man will eben möglichst gute Developer Experience haben, möglichst Spaß am eigenen Job natürlich haben, auch Features zu bauen und Co.
Aber genau, man will halt eigentlich dem Business auch entsprechend, hilft man damit aus, nichts mehr sagt, man hat jetzt den schönsten Weg gefunden, Code zu schreiben, sondern dass man entsprechend die Features realisiert.
Und ja, das ist immer so ein bisschen, man muss ein bisschen ausgleichen immer, aber generell ich bin auch voll dabei, User Experience geht vor Developer Experience.

[1:48:31] Den halt leider auch nicht alle so, das ist der andere Punkt.
Ja, das mit der Developer Experience, würde ich so vertreten, dass eine gute Developer Experience dazu hoffentlich führt, dass man eine gute User Experience hat, dass dementsprechend, wie schnell kann ich den Bug fixen, wenn ich den Bug innerhalb von 20 Minuten gefixt habe?
Ich weiß aber auch, wie der Git-Prozess ist und ich habe Pull-Requests, die werden, da hängt ja noch viel, viel, viel mehr dran.
Und mein Ding mit Vue oder es wäre jetzt mit React und Angular das Gleiche, ich habe mich ja nur für ein Framework entschieden, ist einfach, weil ich in einem Projekt arbeite, das ist keine Webseite mehr, das ist eine Web-Applikation, die wahrscheinlich auch super overcomplicated ist, aber da geht es nicht um Teaser oder es ist kein Shop, sondern wir haben einfach extrem viele Interaktionen drin.
Und das Gefühl, was ich schon noch habe, ist, dass es für diese Frontend-Frameworks halt relativ viele Death Rails, gibt relativ viel Aufmerksamkeit auf X und Mastodon und Co.
Und das vielleicht wahrscheinlich einfach lauter ist als irgendwie Astro und etc.
Ich denke, da sind ja auch gerade die Sage of JS sehr interessant, wenn man eigentlich sieht, wie die restlichen 98 Prozent von dem Web so aussieht.
Was ich allerdings sehr stark darauf achte, ist gerade bei den Packages, die ich einsetze, da dann so nativ wie möglich zu bleiben. Also ich habe jetzt eine Library für Charts und...

[1:49:57] Ich glaube, ich habe diesen Accessible-Modal-Dialog-Dings drin und eine, glaube ich, für den Kalender.
Und da gab es auch immer so eine Zwischenlibrary. So, das ist die Vue.js-Library für den Kalender.
Wo dann halt so ein Wrapper drin ist, wie so ein API-Gateway.
Das ist ganz nett, mache ich aber nie. Weil dann habe ich genau dieses Framework auf Framework auf Framework. Das weiß ich, weiß.
Das hat wahrscheinlich nur eine arme Person geschrieben, die dann irgendwann in zwei, ach, zwei Jahren, zwei Monaten hören, ach, guck mal, die Version von dem Chart.js hat sich jetzt geupdatet, warum ist das jetzt noch nicht bei dir drin?
Ja, Leute, ihr habt was anderes zu tun, dann gebt mir einen Pull-Request.
Das heißt, davon versuche ich wirklich so richtig JavaScript wie möglich dann zu bleiben bei den Packages.
Und auch da fahre ich immer den Weg, so viel wie möglich selber zu schreiben, auch wenn ich da oft in Argumentationen rein muss, auch jetzt gerade innerhalb von meiner Firma, wo ich dann irgendwie argumentieren muss, warum bestehe ich jetzt darauf, das selber zu bauen, sozusagen das Rad neu zu erfinden, wenn es doch dafür schon Libraries gibt und da versuche ich mir auch die Research zu machen, da schaue ich mir an, wie gut maintained ist dieses Ding, wie viele Leute können daran arbeiten, wenn es sein muss, wie viele Leute brauchen das und brauche ich wirklich eine Library oder kann ich es einfach selber schreiben und dann auch noch vertraue ich dieser Library oder könnte die mir sonst wieder meine Daten oder die User-Daten da abknüpfen.

[1:51:24] Ja, aber ich meine, das ist doch auch nicht alles. Also ist das maintained oder manchmal wird das ja auch gefragt, von wegen steht da eine große Firma hinter oder so.
Und ich weiß halt irgendwie nicht, ob das wirklich valide Indikatoren für irgendwas sind.
Weil selbst wenn das irgendwie so das Idealbild eines Open-Source-Maintainers dahinter ist, kann diese Person trotzdem von einem Bus überfahren werden.
Und wenn da die Firma, die dahinter steht, noch so groß ist, kann die trotzdem morgen aufgekauft werden Oder der kann wegen irgendwelcher Wirtschaftskrisen sonst was passieren und dann wird das entsprechende Budget gekürzt.
Oder einfach nur eine Version 2 rauskommen, die einen komplett anderen Fokus setzt, mit dem man nichts mehr zu tun haben möchte.
Also, das ist, was ich vorhin ganz zu Beginn mal meinte mit so, mir fehlt irgendwie das mentale Werkzeug, um zu bewerten, ob ich jetzt eine Library einsetze.
Ich operiere halt immer so auf Bauchgefühl mit halt der Überlegung halt so, ja, okay, wird schon passen, weil gibt's halt schon ewig, ist stabile, große Firma und so weiter und so weiter.
Aber ich weiß halt eben nicht, ob das wirklich tragfähige Dinger sind.
Und ich habe halt so den Verdacht, dass das halt eben nicht der Fall ist.
Ich kann das aber auch nicht genau quantifizieren. Das ist halt eben mein Problem.
Ich glaube, ich weiß da was nicht, aber ich weiß nicht, was ich nicht weiß.
Oder ich weiß nicht, für was mir welche Werkzeuge fehlen.
Jens, hast du Werkzeuge?

[1:52:51] Nicht wirklich, aber ich glaube, deine Bedenken sind gleichzeitig richtig und auch falsch.
Also der große Vorteil von Frameworks ist ja, dass sich meistens viele Menschen über einen längeren Zeitraum kluge Gedanken für eine Problemlösung gemacht haben.
Und diese mir dann abnehmen. Das wurde vorhin schon mal angesprochen, wenn ich dann, ich komme bis zu einem gewissen Grad mit Web-Components meinetwegen weit und dann muss ich auf einmal Routing oder sonst was lösen, was andere ja schon mal in einem größeren Zusammenhang gelöst haben.
Das Gleiche ist bei UI-Components wie bei Bootstrap und you name it, ja genau das Gleiche.

[1:53:38] Für mich ist immer der entscheidende Faktor, wie gut ist die Dokumentation und wie gut kommt man da rein?
Denn die Alternative wäre ja, all das selber zu entwickeln.
Und das wird bei euch genauso sein wie bei uns auch. Es gibt Sachen, die sind selbst entwickelt, natürlich.
Und da ist der Brustfaktor extrem hoch. Da haben wir ganz, ganz wichtige Sachen in unserer Architektur.
Hier hat einer entwickelt. Ein zweiter hat noch drauf geguckt beim Entwickeln.
Wenn einer von den beiden kündigt, stirbt, was auch immer, haben wir ein Problem.
Wenn beide weggehen, haben wir ein sehr großes Problem.
Und dieses Problem hätten wir nicht, wenn wir auf Standards gesetzt hätten, die dann vielleicht irgendwann mal in eine Sackgasse laufen oder die dann abgedatet werden müssen, hinter der aber mehrere Menschen stecken.
Und man könnte ja auch auf die verwegende Idee kommen, bei irgendeinem Open-Source-Projekt versuchen, den Maintainer oder irgendeinen der Aktiveren anzusprechen und zu sagen, dann könnt ihr uns gegen, wir werfen jetzt mal ein bisschen Geld gegen euch, könnt ihr uns nicht bei Problem XY helfen.

[1:54:56] Und das ist für mich dann schon wieder der riesengroße Vorteil von Frameworks.
Zum einen, dass sie mir Arbeit abnehmen und zum anderen, dass ich schon theoretisch wüsste, wen ich gegen Geld zur Problemlösung anhören könnte.

[1:55:13] Muss ich dazu noch ganz kurz kommentieren. Ich als jemand, der so eine Person wäre, finde es auch ganz gut.

[1:55:23] Ich wollte nur ergänzen, also ich glaube, was den Busfaktor angeht, du hast ja immer, also die Frameworks, die nehmen ja immer so Standardaufgaben einem ab, aber du hast ja trotzdem immer noch, also deine Prozesse modellierst du ja immer noch in eigenem Code.
Also ich glaube, das lässt sich sowieso nie vermeiden, dass du zumindest Teile deines Codes eben Busfaktor gefährdet sind.
Also, oder so sagen wir mal, bedroht sind davon.
Man kennt das ja irgendwie Leute, die schon lange in einem Betrieb sind, die wissen, wie irgendwie Dinge laufen.
Also bei der Rheinischen Post war das auch so. Da war eine, die war schon 25 Jahre dabei.
Die hat man immer gefragt, wenn man irgendwas wissen wollte.
Die wusste immer alles, wie das da funktioniert, wie die alten Systeme funktioniert haben, warum Daten so sind, wie sie sind.
Und da schützt einen auch irgendein tolles Framework nicht vor.
Also es nimmt einem halt einen Teil ab, aber du hast ja immer den Boost-Faktor in jedem Projekt, würde ich sagen.

[1:56:30] Okay, aber der Brustfaktor ist ein numerischer Wert, den kannst du ja größer oder kleiner gestalten.
Genau, aber ich meine, das ist ja dieses Ideal, dass die Chefs ja gerne sagen, jeder ist ersetzt oder sollte ersetzbar sein.
In der Realität ist das ja gar nicht. Genau, in der Realität funktioniert das einfach nicht. Also ich habe noch nie irgendwo gearbeitet, wo das so richtig funktioniert hätte.
Also im besten Fall hast du vielleicht irgendwie zwei, die das schaffen, so zusammen.
Dann dürfen die nie zusammen im gleichen Bus sitzen und auch nie im gleichen Flugzeug.
Aber du schaffst es eben nicht wirklich, dieses Know-how über viele Leute zu verteilen.
Also, jeder ist so sein Knowledge-Silo irgendwie für bestimmte Dinge.
Ich weiß nicht, wie es beim Hans ist.
Hans hat ja auch ein Riesenteam.
Wie das bei euch aussieht. Ich glaub, das ist dir auch irgendwie wichtig, oder?
Ja, also grundsätzlich kann man schon sagen, dass das, was eben gesagt wurde, nämlich dieser Busfaktor, der ist auch bei uns, also auch selbst wenn man ein großes Team hat, ist der präsent.
Wir haben jetzt auch einen größeren Umbruch hinter uns, wo auch Leute gegangen sind und wo man halt auch sieht, dass man selbst in großen Teams es nicht halt immer hinbekommt, dass alle Teilbereiche irgendwie abgedeckt sind mit Redundanzen, sage ich jetzt mal.
Und das Thema Open Source spielt da natürlich auch rein.

[1:57:55] Es gibt Teams, die greifen halt auf wenig maintainte Open Source Projekte zurück und stellen dann fest, wir hatten das ja eben auch in der Diskussion, okay, vielleicht übernehmen wir hier auch etwas oder forken das beispielsweise, um es selbst dann zu maintainen, weil die Maintainer das nicht mehr machen.
Ich denke, das tritt immer wieder auf und es ist irrelevant, wie groß das Team ist, weil im Endeffekt, also beziehungsweise ich glaube, es sind die Regeln, die wir halt uns selbst auferlegen, um sozusagen die Guardrails so ein bisschen, also sozusagen die Leitplanken, in denen wir uns bewegen.
Ja, das ist, glaube ich, das Entscheidende.
Wenn wir sagen, wir verwenden nur Open-Source-Projekte beispielsweise, die eine bestimmte Qualität haben, in Anführungsstrichen, die eine bestimmte Anzahl an Maintainern haben, so, dann kann man vielleicht davon ausgehen, dass man das schafft.
Und wenn man halt dann intern diese Guardrails auch für sich selbst anwendet und sagt, okay, ein Projekt, was ich intern entwickle, muss mindestens von so und so vielen Leuten gecovert sein beispielsweise, dann kann das positiv sein.
Ich habe das noch nirgendwo so erlebt, dass das komplett durchgezogen wird.

[1:59:13] Also ich glaube, du kannst natürlich so durch Pair- und Mob-Programming und so, da kannst du natürlich auch sehr viel so quasi Wissenstransfer bekommen.
Aber am Ende brauchst du halt Zeit.
Und Leute, die halt lange irgendwo sind und die Domäne sehr gut kennen, können das trotzdem nicht innerhalb von einem Jahr irgendeiner neuen Mitarbeiterin oder so vermitteln.
Also du brauchst einfach Zeit.
Und je mehr Zeit ins Land geht und man in einem Projekt ist, desto mehr weiß man darüber. Ich glaube, das ist einfach nicht anders lösbar.
Also man kann diese Zeit nicht, also man kann die sicherlich teilweise beschleunigen, aber so am Ende ist das einfach das Limit.

[1:59:55] Vielleicht auch, kann man das auch mal übertragen, um jetzt so die Brücke zu

Design Systeme

[1:59:58] schlagen zum Thema Designsystem.
Wir wollten ja, glaube ich, jetzt um die Zeit darüber wechseln.
Denn ich glaube, auch ein Designsystem ist halt etwas, wenn wir uns darüber mal jetzt unterhalten, was natürlich, je länger man sowas auch verwendet, also ein System innerhalb, sagen wir jetzt mal, mit verschiedenen Teams oder so an einer Sache arbeitet, wo es Zeit braucht, das zu erlernen.
Was mich jetzt mal als Eingang da interessieren würde, wie sieht das bei euch aus?
Habt ihr in der Vergangenheit in euren Projekten Designsysteme erfolgreich einsetzen können? Verwendet ihr das noch?
Oder auch wenn ihr vielleicht mit mehreren Leuten, also in Teams unterwegs seid, wie schafft ihr es halt diesen Wissenstransfer, gerade auch wenn es jetzt um Neuerungen in dem Designsystem geht oder so, aufrecht zu erhalten?
Oder habt ihr vielleicht auch gegenbeispiel und sei bei uns ist das total gescheitert weil das würde mich auch sehr sehr interessieren nicht öffnet mal einfach oder wäre es einfach mal hier in die runde vielleicht hat ja jemand eine coole story dazu.

[2:01:10] Jens, ja. Entschuldigung. Ja, Jens, ja. Wieso? Entschuldigung.
Ja, also ich habe quasi zwei Storys zu diesem System.
Zum einen, als ich in die Firma gekommen bin, da gab es schon sowas ähnliches für die Entwickler.
Und jetzt stehen wir vor einem Relaunch, der bestimmt recht lange dauern wird.
Und jetzt wird gerade so ein Designsystem von den Designern entwickelt.
Mein Problem bei der ganzen Geschichte überhaupt, bei diesem Designsystem, ich liebe diese Dinger, oder Komponentenbibliotheken ist, dass das immer Silos sind.
Entweder für Designer oder für Entwickler, aber niemals für beide gleichzeitig.
Du hast immer eine technische Hürde, immer eine technische Sperre.
Du kannst nie gleichzeitig wirklich daran arbeiten.
Und wir arbeiten als Frontendentwickler in der Komponentenbibliothek.
Das ist unsere Oberfläche, mit der wir kontrollieren, ob das, was wir gemacht haben, korrekt ist.

[2:02:15] Und das ist natürlich dann was ganz anderes, als was die Designer tun.
Es wäre wunderschön, wenn es da mal etwas gibt. Ich weiß noch genau, mein uralter Arbeitgeber, Sinna Schrader, hatte mal sowas vor sieben Jahren oder sowas, mal in der Mache, das war so in der Anfangszeit von React, da haben die sowas gemacht.
Das ist dann, glaube ich, nach einem Jahr oder nach zwei wieder eingestampft worden. und den typischen Open-Source-Tod gestorben.
Aber auch da hast du dann wieder das Problem, dass du eine Fixierung auf eine Technik hast. Du musst React nehmen, damit das funktioniert.
Und dieses Maintainen, das ist für mich das Größte und die Kommunikation, weil das Maintaining bei uns selber in der Frontend funktioniert ja, weil wir da drin arbeiten.
Das muss ja wieder zurückgespielt werden zu den Designern.
Ja, das ist ein super spannender Punkt.

[2:03:35] Auch dazu erzählen, bei uns ist es auch extrem schwierig, ein Designsystem einzuführen und das aber auch durchzusetzen, aber vielleicht, also Thema Kommunikation, vielleicht können wir da gleich noch was drauf eingeben, Marco erstmal.

[2:03:51] Ja, ich staune gerade, wie viele Leute ihr habt.
Wir haben deutlich weniger. Bei uns ist es so organisiert, wir haben ein kleines Team, was halt die Komponenten baut für die Produktteams, die die Produkte entwickeln.
Und ja, durch diese Trennung mit der Schnittstelle kann dieses Team auch super viel machen.
Wir haben parallel dazu jetzt kein Design-System dokumentiert, sondern wir sagen dazu Bedien-System, also welche Komponenten gibt es, wie verhalten sie sich, wann benutze ich sie.
Das ist ein riesiger Papiertiger mit Positiv- und Negativbeispielen, sage ich mal.
Design-System ist es deswegen nicht, weil das Design nachher vom Endkunden kommt, also die Bank sagt dann genau, wie was aussehen soll.
Ja, das, was wir selber machen können, das kriegen wir relativ gut gemanagt, das kriegen wir auch gut hin.

[2:04:38] Das, was aber dann in den Produkten letztendlich gemacht werden muss, das haben wir zwar schön aufgelistet, protokolliert, da gibt es riesige Backlogs, das scheitert dann meistens an der Beauftragung.
Das heißt, da ist dann kein Budget da oder andere Sachen sind wichtiger.
Das ist die Story, die ich dazu erzählen kann. Mhm.
Also da auch wirklich die Kohle zu haben, dann auch einmal sowas ordentlich aufzusetzen, in Anführungsstrichen, also die Zeit einfach zu machen.
Also konzeptionell haben wir das gemacht, aber die Umsetzung dessen, was dann an To-Dos, an Issues rausgepolstert ist.
Wie gesagt, das, was wir selber im Team machen können, das kriegen wir super hin.
Aber das, was eben in den Produkten gemacht werden muss, das muss natürlich dann auch von den anderen Teams gemacht werden.

[2:05:28] Und bei denen rutscht das immer ganz nach unten ins Backlog.
Was wäre das für ein Beispiel, was die dann machen müssten, was dann aber irgendwie verschütt geht?
Also zum Beispiel, ich sag mal, Tooltips richtig benennen.
Also, dass nicht auf einem Senden-Button nochmal als Tooltip senden steht sowas.
Das hat man ja manchmal, dass da irgendein Entwickler nicht wirklich nachdenkt und dann Dinge reinschreibt, die wenig hilfreich sind für den Anwender.
Das können wir in der Komponente nicht realisieren, weil das eben je nach Anwendungskontext unterschiedlich ist.
Und ja, das müssen dann die Produktteams selber lösen. Okay.
Vielleicht bevor wir zu dir, Andreas, kommen vielleicht mal ganz kurz Show of Hands in der Frage aus dem Chat, wer verwendet denn sowas wie Storybook oder Storybook itself?
Man sieht einige Leute nicken, ein paar Hände gehen hoch, manche schütteln den Kopf.

[2:06:35] Wir hatten jetzt drei Händchen hier oben. Okay. Vielleicht gehen wir gleich nochmal drauf ein, aber dann erst zu dir, Andreas.
Genau, ich kann vielleicht auch drauf eingehen. Also ich sehe das wie Jens, dass so der Hauptpunkt ist, dass die Kommunikation zwischen den Teams, auch zwischen Design und Frontend-Team, so eine Hürde ist, die im Moment auch bei uns, oder nicht eine Hürde, aber ein Problem darstellt.
Bei uns ist das Ganze technisch, gesehen aus einem Need entstanden, dass wir quasi schon verschiedene Komponenten hatten, die aber für verschiedene Produkte gebraucht haben.
Von daher aus technischer Sicht benutzen wir auch Storybook, haben die Komponenten quasi dann technisch aus einem Repository in ein eigenes gesondertes Repository übertragen.
Aber genau, ich sehe auch den Punkt, die Kommunikation zwischen den einzelnen Teams vor allem.
Also wie benutzt man die Produkte? Natürlich Natürlich kommt auch der Punkt Dokumentation mit ins Spiel und da kann man ja auf Storybook-Ebene oder generell sehr viel tun.

[2:07:40] Genau, das ist so ein Punkt, den wir haben und wir haben uns auch schon verschiedene Tools angeschaut, mit denen man quasi, ich kenne das jetzt nur von der Storybook-Ebene, quasi Storybook mit dem Designsystem verbinden kann.
Ich komme gerade nicht mehr auf die Produktnamen, aber da gab es auf jeden Fall etwas.
Aber genau, es ist, denke ich, so, in der Basis geht es auf, was Jens gesagt hat, so, dass es, ja, die Kommunikation untereinander so ein Hauptpunkt ist.
Aber es hat sich für uns schon so in dem Sinne ausgezahlt, dass wir jetzt sehr viele verschiedene Produkte haben, die unser System gerne nutzen möchten oder auch schon nutzen, aber es ist gerade erst so in der Entstehungsphase, würde ich sagen.
Also bisher war es mehr intern genutzt für uns.

[2:08:33] Ja, Jens, schließt du wahrscheinlich nahtlos an. Ja, ich habe mal vor einiger Zeit mit dem Tim Kraut, der auch hier im Chat ist, in einem Team zusammengearbeitet.
Und da waren wir ziemlich viele Entwickler und auch einiges an Designern.
Und damals haben wir es so gelöst, dass ich persönlich mit einem Designer immer mindestens einmal in der Woche das Designsystem durchgegangen sind und haben Aktualisierungen besprochen.
Also wir beide waren dann immer dafür zuständig, für unsere jeweiligen Teams die auf dem neuesten Stand zu halten.
Das hat eigentlich ganz gut funktioniert. Das ist eine Krücke, aber das war 2017, glaube ich.
Oder 2016. Und ich glaube, das ist immer noch nicht besser geworden.
Wir müssen das immer noch Hand zu Fuß machen. Und so schlimm es ist, man muss mit anderen Menschen aufhören.

[2:09:34] Und da entstehen ja häufig die Konflikte. Bei uns ist das auch ein Thema gewesen.
Also ich sage mal so, die Wunschvorstellung, die man häufig hört, ist halt irgendwie, man drückt, irgendjemand aus dem Design ändert eine Farbe irgendwo irgendwo oder einen Padding, drückt einen Knopf und auf allen Endgeräten updatet sich alles.
Und so diese Prämisse oder diesem Ziel irgendwie hinterherzueifern, finde ich persönlich ziemlich cool.
Also wenn man das irgendwie schaffen könnte, ich habe es noch nie erlebt, zumindest in einem, sagen wir mal, etwas größeren Kontext jetzt.
Also vielleicht kriegt man das hin mit einem Projekt, aber selbst da ist es halt schwierig. Was wir halt hatten ist, wir wollten relativ viel Automatisierung so reinbringen.
Beispielsweise man arbeitet in Figma, dann muss da ein entsprechendes Setup haben und muss entsprechend die Design-Tokens richtig aufsetzen und dann kriegt man es vielleicht hin, dass man auf Knopfdruck dann ein JavaScript oder ein JSON mit den Tokens exportiert bekommt.
Und wenn man die dann in der Code-Implementierung richtig eingebaut hat, also bei uns sind es jetzt auch beispielsweise Apps, die dann nativ geschrieben werden und auch Webseiten und so weiter, dann bekommt man es vielleicht hin, dass darüber entsprechend eine Art Automatisierungspipeline angestoßen werden kann.

[2:10:58] Dennoch kann das natürlich auch zu Problemen führen.
Was, wenn da mal dann irgendwie was bricht im Design oder ähnliches und dafür braucht man halt, ja, muss man halt miteinander sprechen.

[2:11:11] Ich weiß aber nicht genau, wie man diese Gespräche halt hinbekommt.
Jens, was du jetzt eben sagtest, einmal in der Woche setzt man sich zusammen und spricht die Änderungen durch und arbeitet sozusagen Hand in Hand.
Das scheint ja aus erster Perspektive wahrscheinlich der beste Weg zu sein.
Was waren trotzdem die Probleme bei euch?
Eigentlich keine. Also ich kann mich jetzt direkt an keine Probleme erinnern.
Du musst natürlich, du spielst ja immer so ein bisschen stille Post.
Weil ja niemand das erstmal so richtig aufschreibt.
Also die Übergabe ist ja meistens erstmal vom Design an Entwicklung, aber umgekehrt muss natürlich auch die Entwicklung darauf hinweisen, so wir haben jetzt dies und jenes von euch von den letzten ein, zwei Wochen umgesetzt.
Schaut nochmal drauf. Oder wir haben es anders lösen müssen, weil, wie auch immer.

[2:12:09] Man muss es eigentlich unterschreiben. Ich habe bei unserem jetzigen Designsystem irgendwann mal damit angefangen, so eine Art Änderungsliste zu führen, immer so monatsweise.
Hat sich niemand für interessiert und dann habe ich es nur noch ein halbes Jahr abgebrochen.
Aber für einen selber ist es vielleicht gar nicht mal so doof.
Ich habe das damals nur für die Designer gemacht und sehr viel später ist mir aufgefallen, das wäre eigentlich auch klug für uns gewesen, damit wir dann wissen, wann haben wir was gemacht, Wann sind sie in die Grütze gegangen?

[2:12:46] Ja, ein Thema, was ich auch noch festgestellt habe, gerade wenn es halt um mehrere Teams geht, die auf ein Designsystem zugreifen, ist halt die Versionierung dessen oder halt das auch aktuell zu halten sozusagen. zu sagen.
Also wie schafft man es und wir haben da keine gute Lösung gefunden, dass halt alle Teams immer zur gleichen Zeit updaten.
Ich kenne da noch von einem anderen Projekt, ich habe mal bei Rewe Digital gearbeitet, die wollten irgendwie einen Button von Rot auf Grün ändern und das hat so viele Teams betroffen, dass dieses Projekt ein ganzes Jahr lang ging oder so was oder ein halbes bis ein Jahr lang ging, bis dann überall diese Farbe umgesetzt wurde.
Don't quote me, aber so ungefähr um den Dreh.
Und das ist natürlich etwas gewesen, da zeigt sich halt, dass man ein anderes System braucht.
Also ich habe nur noch nicht verstanden, wie man es hinbekommt, das halt wirklich einzuführen und auch so eine Größe dann, auch wie bei Rewe Digital jetzt oder so, dann umzusetzen.
Es sind ja einige Tools im Chat genannt worden. Ich weiß jetzt nicht, vielleicht möchte auch jemand nochmal erzählen, wie er sie das in ihren Projekten umsetzen und welche Tools er vielleicht auch einsetzt.

[2:14:09] Andreas? Ja, ich kann vielleicht nur gerade zu den zwei Tools etwas sagen, die ich da gelistet habe.
Einmal UX-Pin.
Die haben, soweit ich das noch in Erinnerung habe, eine sehr große Integration auf der technischen Ebene, dass man quasi auch auf der, wenn man TypeScript oder so benutzt, die Typisierung quasi mitnehmen kann in deren Produkt.
Dass quasi dann auch im designteam diese properties genutzt werden können.

[2:14:46] Umsetzungstechnisch weiß ich gar nicht mehr das war schon etwas anspruchsvoller in dem sinne dass man quasi auf der code ebene dann quasi vorbereitungen treffen musste und das ganze basiert oder basiert auf dem werk ökosystem von daher hat man da auch ein Buy-in auf der Seite.
Und Story-to-Design hatte ich jetzt noch nicht selbst ausprobiert, aber das war zumindest sehr spannend vom Ansatz her.
So das, was ich in dem Sinne weiß, wenn es auch um den Punkt Storybook geht, ist, dass viele dieser Tools, diese Stories, die man sich in Storybook quasi anschauen kann, nur als Bild oder quasi als gottgegeben hinnehmen kann und dann quasi diese Sachen ins Designsystem einbinden kann, aber nicht aktiv verändern kann.
Das ist so das, was ich da als Learning mit rausgenommen habe, aber ich weiß nicht mehr, ob das auf alle Tools zutrifft.

[2:15:49] Ansonsten, die wir im anderen Thread beschrieben hatten, das war eben zu einem Storybook und da im Gegensatz dazu auch noch Histoire.
Da haben wir jetzt nochmal die Auch die Diskussion von vorher aufgegriffenem Storybook ist natürlich das weit Verbreitetste. Ich glaube, mittlerweile wird es auch als Testing-Tool zusätzlich noch benutzt.
Also das ist jetzt so ein Allrounder richtig geworden. Aber gerade im Vue-Umfeld gab es, vor allem wenn ich mich richtig daran erinnere, in Vue 2 immer Probleme, dass man gemerkt hat, irgendwie wurde Storybook halt doch für React geschrieben und da geht's nahtlos rein.
Und mit Vue war das so, da hat manche Sachen einfach nicht so gut funktioniert.

[2:16:32] Ähm, dementsprechend, äh, wurde dann von einem der Vue-Core-Mitarbeiter auch Histoire geschrieben.

[2:16:38] Hat, muss nicht unbedingt mit Vue zu tun haben, es lässt sich zum Beispiel auch fürs Welt einsetzen und dann ist wieder die Frage, will man jetzt diese eierlegende Wollmichsau von Storybook eher nehmen? Wir kennen wahrscheinlich sehr viele Leute, hat aber diverse Komplexität einfach drinnen, weil es eben sehr viele Probleme behandelt.
Oder Histoire, was eben sehr gut verwendbar ist fürs Welt- und View, weil es auch deren Sonntag sehr gut folgt und man hat nicht das Gefühl, man müsste jetzt wieder so ein neues Tool lernen oder hat da ein Hassle.
Mit Storybook bin ich einmal leider mit reingerannt in dieses Problem von Storybook 4 auf Storybook 5.
Hat relativ lange gedauert, dass man sich auch gefragt hat, ist es jetzt wirklich notwendig, dass man mehrere Developer teilweise dazu braucht, diese Migration zu machen? Eigentlich wollen wir ja Features entwickeln.
Vielleicht war das nur unser spezielles Problem.
Ich denke, was wir viel mehr als jetzt mal diese eine technische Migration immer wieder zu besprechen hatten, war, wie baut man das jetzt wieder allgemein auf?
Also hat man da jetzt noch so einen Atomic-Ansatz oder ist einfach alles irgendwie eine UI-Komponente?
Und die Frage, was ist denn eigentlich eine UI-Komponente? Also wann darf denn eigentlich was in die Pattern-Library rein?
Ist es, sobald wir irgendwie denken, das hat jetzt Properties für Text und Farbe und könnte jetzt in jedem Kontext verwenden oder kommt irgendwas erst in der Pattern-Library, Storybook oder etc. etc.
Rein, wenn wir das auch tatsächlich an mehreren Stellen verwenden.

[2:18:04] Hattet ihr denn auch solche Diskussionen wie, ab wann darf es in die Library, ab wann ist es ein Base-Button, App-Button?

[2:18:17] Ja, also ich kann mal vielleicht von unseren Teams ausgehen, also diese Diskussionen haben wir gar nicht so stark geführt, weil es bei uns häufig der Fall war, dass wir eher von etwas rückmigriert haben also beispielsweise es gab komponenten die halt da waren und jetzt hat man überlegt wie bauen wir halt das design system auf das heißt man muss also man wollte dadurch dass wir halt hauptsächlich ein produkt haben was halt eine ja ein frontend hat und was jetzt gar nicht so stark unter sich stark unterscheidet oder so von theming oder wie wie auch immer, ist es für uns einfach wichtig, dass wir die Komponenten nach und nach alle im Designsystem irgendwie vorhalten.
Aber es gibt natürlich schon, wenn ich jetzt mal nachdenke, so Unterschiede.
Aber diese Diskussionen, die wurden nicht so stark geführt. Also was kommt jetzt auf der einen Seite rein und was muss aber im Produkt bleiben?

[2:19:19] Grundsätzlich stelle ich mir aber vor, dass das auf jeden Fall ein sehr, sehr wichtiger Punkt ist, gerade wenn man jetzt unterschiedliche Kundenfrontends oder ähnliches mit dem gleichen Designsystem abdecken wollen würde. oder?
Ja, also das war einfach in einem sehr, sehr gießigen Kontext, wo man wollte da generell einfach nichts falsch machen.
Man hatte noch nicht so viel Erfahrung, sondern man hatte eher so dieses Projekt, wir wollen das jetzt bauen für Kunden später.
Jetzt ja gerade hatte ich am Anfang von der ganzen Diskussion den Kopf geschüttelt bei, wer eigentlich Storybook oder ähnliches verwendet.

[2:19:51] Ich sehe da auf jeden Fall für die Developer Experience, oder vielleicht sozusagen Designer Experience große Vorteil, wenn man es mehr mehr verwenden würde und alleine der mentale Shift, dass ich jetzt erst die UI-Komponente in Isolation implementiere, ohne da den ganzen Kontext schon im Hintergrund zu haben und vielleicht da habe ich jetzt persönlich immer noch mal mehr im Hintergedanken, du, ich teste das jetzt noch mal durch für Texte, die sich umbrechen oder vielleicht für dynamische User-Inputs, die jetzt gar keinen Space oder gar kein Leerzeichen drin haben, bricht das alles richtig um, funktioniert das mit jedem, eben wenn die Komponente noch ein Hintergrundbild oder irgendwo ein Bild drin hat, funktioniert das gut, wenn es einen transparenten Hintergrund hat oder einen weißen, braucht es sonst eine Border etc.
Also ich entwickle die Komponenten immer ganz gerne erstmal komplett losgelöst von der Seite, damit sie dann auch da gut funktioniert.

[2:20:48] Und auf der anderen Seite werde ich auch oft konfrontiert dann mit der Diskussion oder dem Argument, Aber ist das nicht eigentlich Figma?
Können wir das nicht alles in Figma machen?
Warum sollten wir denn zusätzlich zu Figma jetzt noch einen Storybook in die Welt schaffen?
Weil sollte da dann nicht eh jeweils zweimal das Gleiche drin sein?
Und ich finde generell ist an dem Argument sehr viel dran.
Daran, in der Realität sehe ich es ganz selten, dass es gut funktioniert.
Ich habe das jetzt so ein bisschen ähnlich wie mit Jens, ich habe da immer meine Stunde mit dem Design und da reden wir, kotschen wir drüber, wie schaut es denn aus, was ist bei euch neu und haben wir das eigentlich?
Weil man braucht auch sehr gute PMs oder POs, die sich dann darum kümmern, wenn Design möchte jetzt eigentlich mal so kurz was reindesignen, wird dann immer so ein bisschen reingesneakt in so eine andere Feature entwickeln.
Du, wenn du eh schon die Komponente da einsetzt, kannst du noch die drei Sachen dran ändern und dann ist halt, also wir haben, ich arbeite halt in einem kleinen, guten Team und da funktioniert das halt, dass ihr sagt, du, Design, ich habe das und das jetzt mitgeändert, passt, kannst es auch nebenbei mit abtesten.
Je größer und je struktureller, das wird vielleicht auch je komplizierter.

[2:22:06] Ja, zu zwei Punkten ganz kurz. Das eine, also wir entwickeln meistens, wenn wir jetzt ganz neue Komponenten entwickeln, die erstmal ganz spezifisch für den einen Use Case und gucken, dann gibt es noch einen generelleren, weil ich die Erfahrung gemacht habe, viele verlieren sich, wenn sie direkt versuchen, eine total generische Komponente zu bauen, die überall funktioniert, verlieren sie sich in endlosen Details und verlieren den Use Case, für die wir sie jetzt gerade brauchen. auch so ein bisschen aus den Augen.
Aber meistens ist das eben bei uns auch so, dass das Feature erstmal spezifisch an einer Stelle eingesetzt wird und dann, wenn das nächste kommt, merkt man so, hey, der Use Case erweitert sich und es wird generischer.
Es funktioniert bisher bei uns ganz gut, aber es ist natürlich immer so eine Abwägung. Ist das jetzt eine neue eigene Komponente? Baut man eine bisherige rein?
Wird es irgendwann eine Schweizer Taschenmesser-Komponente, die alles kann?
Das ist natürlich immer so der alltägliche Diskussionspunkt.
Und was mich sonst noch so als Frage in die Runde interessieren würde, nutzt ihr denn die Designsysteme, egal ob es jetzt konkret in Storybook oder irgendwas implementiert ist oder auch nur irgendwo niedergeschrieben, in der Firma auch verbreiteter als Kommunikationstool?
Also ich habe oft das Gefühl, irgendwie die Designer machen gern so ihr Ding und die Entwickler gern so ihr Ding, aber eigentlich entfaltet es seine Macht dann, wenn man es eben auch mit POs, mit anderen Stakeholdern benutzen kann, um über Sachen und Konzepte zu sprechen, um halt auch Aufwände abzuschätzen und solche Sachen. passiert sowas bei euch?

[2:23:34] Vanessa hat mich eben noch auf eine Sache gebracht. Und Fabian, also deine letzte Frage.
Ich wollte es, habe mich bemüht.
Das Fleisch ist offensichtlich schwach.
Das heißt, die POs und die Designer waren eher nicht so in der Lage oder bereit oder willens, da wirklich dran mitzuarbeiten. Weise.
Vanessa hat mich draufgebracht, dass ich mir immer sehr viele Freunde gemacht habe unter den Designern mit der kurzen Ansage, die Wahrheit liegt im Browser, deswegen ist es sehr hübsch, was ihr da in eurem jeweiligen Design-Tool macht.
Die Wahrheit ist das, was in meiner Design-Bibliothek drin ist, weil das haben wir umgesetzt aus euren Vorlagen und wenn das jetzt abweichend davon aussieht, dann liegt das schlicht und ergreifend daran, dass in eurem Design-Tool, Sachen möglich sind, die bei uns im Web einfach nicht möglich sind.
Diese Ansage wird immer schwieriger. Weil erstens, die Brause wird immer viel besser werden.
Und weil jetzt bei uns jetzt auch in der Firma Fickmann auch dazwischen kommt.
Und das ist das erste Tool, das so richtig.

[2:24:46] Webby ist. So richtig.
Also die vorherigen waren webbiger als Photoshop.
Kein Wunder.
Aber ich sehe jetzt schon als Gefahr voraus, dass ich argumentieren muss, dass ich nicht einfach den Code aus Figma nehmen kann und den dann, also dass ich gar keinen Aufwand mehr habe, weil die Maler und Lackierer, also die Designabteilung, haben ja schon alles gemacht. Ich muss mir ja den Figma-Code rausnehmen.
Und das wird nicht so funktionieren, nicht so richtig. das mache ich vielleicht beim, könnte ich bei meinem Weblog machen oder bei meiner Kochseite, aber nicht bei einer richtigen und das wird schwierig glaube ich, dank Figma und Figma wird ja überleben also Adobe darf es ja nicht kaufen, das heißt die Chance dass es überlebt ist jetzt gestiegen dadurch, dass Adobe es nicht zugrunde richten kann ist doch schon mal etwas.

[2:25:51] Also ich würde dir da auch auch total recht geben. Also ich glaube, dass Figma halt, oder jetzt Tools wie Figma, sagen wir einfach mal, und die nächste Stufe davon, dass die halt ganz viel obsolet machen werden von den Diskussionen, die wir halt heutzutage führen.
Ich stelle mir so vor, früher haben wir noch geschaut, dass wir halt unser CSS halt wirklich so handcraften und so, geringe, also so wenig Buchstaben wie möglich verwenden, um so wenig über die Leitung halt transmitten zu müssen und damit der Parse halt da nichts mehr macht.
Im JavaScript ist ist das Gleiche gewesen.
Heute in Anführungsstrichen interessiert uns das recht wenig.
Das ist ein Vorteil für uns als Entwickler und Entwickler, weil wir uns anderen Problemen irgendwie widmen können, glaube ich, an manchen Stellen, ist zumindest meine persönliche Meinung.
Und dann auf der anderen Seite ist es aber auch so, und das trifft halt gerade für Designsysteme dann halt auch zu, ist es halt gar nicht mehr so wichtig, ob jetzt eine Duplizierung einer Eigenschaft im CSS drin ist oder so, weil das macht dann halt irgendwie mein mein Bild-Tool hinten raus, genau so.
Und dieser Code, den wir halt heute schon sehen von AI-Tools, die halt irgendwie anhand eines Designs eine Komponente bauen.

[2:27:06] Der ist halt ja heute schon nicht schlecht und wenn wir jetzt mal, sagen wir mal, nächstes Jahr gucken oder in zwei Jahren gucken, wenn wir dann die AI-Tools, die wir dann haben, in dem Bereich haben werden, dann ist halt die Frage, was ist die Aufgabe von uns als Programmiererinnen und Programmierern, um diesen Code halt dahin zu biegen, wo wir ihn brauchen oder widmen wir uns hauptsächlich Funktionalität und so weiter und so fort.
Aber das ist vielleicht ganz kurz dazu ein Punkt, weshalb ich mich eigentlich gemeldet hatte.

[2:27:34] Es passt aber auch irgendwie so ein Stück weit zu der Fragestellung.
Da war aber nochmal ein Kommentar aus dem YouTube-Chat, nämlich wie funktioniert es eigentlich, dass wir halt diese Kommunikation gut überbrücken oder gut bauen sozusagen zwischen Design auf der einen Seite, Engineering auf der anderen Seite.
Und da sagt wahrscheinlich der Moritz von Wo wir sind, ist vorne, dass es KollegInnen gibt, bei denen konsequente Versionierung der einzelnen Komponenten, also einzelne Komponenten versioniert und ein eigenes Design-System-Team plus Komponenten, die entweder als Web-Components, hatten wir vorhin, oder als NPM-Pakete vertrieben werden, in Anführungsstrichen, also intern dargestellt werden, nehme ich an.
Dass die zum Erfolg führen, auch at scale sozusagen.
Und eine Frage, die ich mir noch gestellt habe, auch, wie handhabt ihr das zum Beispiel, wer ist verantwortlich für das Designsystem?
Gibt es, Jens, wie du sagtest, dich und eine Person aus dem UX-UI, die das hauptsächlich leaden, die das dann vielleicht aber auch programmieren?
Gibt es dedizierte Personen oder habt ihr eher vielleicht auch ein Setup von einem dedizierten Team im Sinne von.

[2:29:00] Also mehrere Leute arbeiten an einem Design-System, aber halt nicht an den Hauptprodukten oder gibt es in euren Kontexten vielleicht aber auch sowas wie eine Art Federated Team, dass mehrere Produkt-Teams gibt, die sich um etwas kümmern und aus diesen Teams gibt es vielleicht jeweils eine Person, die sich dann um das Design-System mitkümmert und da gibt es dann so eine Art Supergroup von Design-Systemen. Wie handhabt ihr das?

[2:29:33] Ist das überhaupt ein Problem für euch? Oder ist es, also ist es das nicht?
Im Chat geht's auch ordentlich her, ich muss das mal nachlesen, alles.
Chef, ich sehe deine Lippen, dass sie sich bewegen, aber ich höre dich nicht.
Ich wollte ja nur gucken, ob ihr aufpasst.
Genau, die Die Hannah, die hier zugeschaltet ist, aber wahrscheinlich aus Gründen gerade sich nicht anmücken kann, hat im Chat die Frage gestellt, ist in eurem Kontext überhaupt für alle Beteiligten das Ziel beziehungsweise der Wunsch vorhanden, tatsächlich ein Designsystem zu erschaffen?
Oder nutzt man einfach nur ein Tool?
Also ich würde das wahrscheinlich so jetzt interpretieren.
Also baut ihr eigene Designsysteme Design-Systeme oder nutzt ihr fertige Design-Systeme in euren Projekten?
Könnte aber auch sein, ob man einfach nur so ein Tool hat, damit man halt die 20 Komponenten sehen kann, aber das ist ja an sich noch kein Design-System.
Okay, ja, stimmt, so wird es gemeint sein.

[2:30:49] Und ich habe auch die Befürchtung, dass ...
Also ich habe auch immer noch nicht ganz genau verstanden, was ein Designsystem ist. Ich habe da so ein paar Bücher.
Ich glaube, das ist dann im Prinzip einfach das Regelwerk und Tokens und all diese Dinge. Der hört es ja noch nicht auf.
Tokens sind ja auch nur ein kleiner Bestandteil davon. Tokens ist jetzt auch nur was Technisches, damit ich dann zum Beispiel in verschiedenen Applikationen, vielleicht sogar iOS, Android, Web halt die gleichen Hexcodes runtergebracht habe, aber das Buch, das ich gelesen habe, dummerweise bin ich nicht in dem Raum, wo die Bücher sind, glaube ich, das heißt einfach Thinking in Systems und das hat jetzt per se noch nicht mal was mit Code oder Designs zu tun, sondern das ist wirklich damit, dass die ganze Firma an dem gleichen System arbeitet oder sowas.
Aber vielleicht ist das Designsystem dann das Regelwerk und du hast noch nichts gestaltet oder gebaut, aber aber du kannst dann, oder das Regelwerk gibt dir alle Antworten beim Prozess des Designs und Bauens.
Genauso beim Design oder beim grafischen Design vielleicht irgendwie.

[2:31:59] Farben, Texte, Textgrößen, Fonts, all diese Dinge und dann bei der Implementierung auch so Sachen wie Motion Design, Barrierefreiheit, so was muss da alles drin sein und dass du Also wenn du vielleicht eine Checkliste hast, anhand derer du jede Komponente in deinem Designsystem abarbeiten kannst und gucken kannst, ob die eben deinem Designsystem folgt oder nicht.
Aber da würde ich auch sagen, dass wir auch eher Tools haben als ein tatsächliches Designsystem.
Oder es ist eher so, dass sich das dann eben aus den Komponenten ergibt und dann neue Komponenten darauf wieder zurückgreifen. dass es so ein Hin- und Herprozess ist.

[2:32:50] Der Jens? Ja, also ich habe bislang in allen meinen Teams und Firmen, wenn nur die Begeisterung für Designsysteme, früher hießen die noch nicht so, da waren das dann Photoshop-Dateien, die als JPEGs in PowerPoint reingeknibbelt wurden, nur von den Designern gesehen.
Und bei den Entwicklerkollegen war eigentlich ich immer nur der Einzige, der das immer total sexy fand.
Ich war dann auch dafür zuständig, dass dann Barren Spectral eingeführt wurde, weil damals das Storybook ja nicht so weit war, einfach HTML darzustellen.
Und alle anderen sehen es, glaube ich, als Tool an. Als mehr oder minder nerviges Tool oder auch praktisches Tool, um Komponenten in Isolation zu entwickeln.
Und dafür ist es ja auch sehr praktisch. Also bislang habe ich immer nur wahrgenommen, dass bei meinen Vorländischen Entwicklerkollegen das Ganze sehr pragmatisch als Tool genutzt wurde, aber da jetzt nicht die darüber stehende Idee als so besonders wichtig und sexy und so angesehen wurde, das war eher die Arbeit der Designer.

[2:34:10] Ich glaube, es ist wieder stumm, oder? Ah, okay.
Jetzt hast du zu viele Knöpfe, um dich zu anlügen. Wie viele hast du denn?
Ich hab den ganzen Bildschirm voll.
Vielleicht ist ja ein Designsystem, also ich mein, wir im Deutschen betrachten ja Design immer so mit der grafischen Brille.
So, für uns ist das ja immer bunte Farbe, aber eigentlich heißt ja Design eher so, ja, wie entwickelt man generell was?
Und ESLint und auch Test Driven Development und Co.
Könnte ja letztendlich auch ein Designsystem sein, dass man eben dann auf seinen, oder anhand dessen der Code eben beschrieben und ausgerichtet wird und eben nicht das Optische.
Und ich glaube, da sind wir alle schon eher Fans von solchen Leitplanken, in denen wir uns bewegen beim Coden.

[2:35:14] Also bei uns hat auch in erster Linie Storybook mal geholfen unter den Entwicklern, dass man eben einen zentralen Punkt hat, wo alle Komponenten, die wir so haben, dokumentiert, abgebildet sind und man nicht dazu kommt, dass der eine für das Problem, was es zu lösen gilt, wieder seine eigene Komponente baut, obwohl jemand eigentlich schon mal eine gebaut hatte, die das Problem zu 80 Prozent schon löst.
Und wenn man eine neue Property hinzufügt, hat man selber auch wieder gelöst.
Also das als zentrale Plattform, um auch Wissenstransfer eben gerade, wenn Leute noch nicht so lange dabei sind, noch nicht alle Komponenten können, dass du immer sagen kannst, hier ist dein zentraler Anlaufpunkt, guck mal da rein, da hast du eine gute Übersicht, was wir so haben und so.
Also das war der Instant-Mehrwert, den wir hatten.
Aber deswegen auch meine Frage vorher, was ich mir natürlich so ein bisschen mittelfristig hoffe, dass es halt eigentlich ein Tool auch zur Kommunikation, interdisziplinär ist und man halt auch mit anderen Leuten drüber sprechen kann oder wenn eben Anforderungen reinkommen, man sagen kann so, hey, wir haben hier die und die Komponenten.
Passt deine Anforderung dazu oder nicht?
Oder ist der und der Punkt bei der Anforderung so wichtig, dass wir es mit einer existierenden Komponente vielleicht eh schon lösen könnten oder kann also auch für solche Diskussionen und zur Konzeption und so von Anfang an auch mit mehr Leuten zu nutzen, aber.

[2:36:30] Ja, ist bisher noch so mein Wunschtraum, den teilen noch nicht so viele, deswegen auch eben so zur Frage von Hannah, also bei uns ist bisher auch bisher mehr ein Tool als ein umfängliches System, was auch von vielen Leuten genutzt wird und sich Leute beteiligen, so.

[2:36:47] Ja, sonst gab es an der letzten Smashing Conference in Freiburg auch auch ganz interessante Talks rund um Designsystems von Dan Donald oder so, die eben auch versucht haben herauszustellen, wie groß der Wert ist.
Dass es eigentlich nicht nur um Design, Code und Dokumentation geht, was so die praktischen Outcomes sind, sondern eigentlich ein Mittel zur Kommunikation und auch Beziehungen von Leuten, die am Produkt arbeiten und so.
Aber bisher ist das bei mir noch so Theorie, noch nicht in der Praxis.

[2:37:19] Also bei uns kommt das schon vor, dass eben ein neues Feature gewünscht und geplant wird und dann können wir eben vor allem wir Entwickler, weil ich glaube, wir haben irgendwie den besten Überblick über die Komponenten, weil wir irgendwie ständig an denen rumbauen.
Ich habe das Gefühl, dass das Design da nicht immer mehr so ganz den Überblick darüber hat.
Aber dann können wir eben sagen, hier gibt es was, was eben so ähnlich ist und wir können euch alles bauen, klar, aber sinnvoll ist das nicht.
Und ihr wollt ja auch immer noch gleichzeitig irgendwie, dass alle Core-Web-Weite jetzt erfüllt sind.
Und wenn wir dann irgendwie alles immer neu bauen, dann shippen wir immer mehr Zeug.
Also überlegt es euch, die Komponente gäbe es.
Und dann kann man auch manchmal so ein bisschen prototypen damit und zeigen, okay, in die Richtung könnte man diese Komponente dann eben bringen.
Ist es gut oder muss es so sein, wie ihr euch jetzt überlegt habt?
Und dann, da hat man seine Kommunikation, die endet manchmal so und manchmal so.
Ich würde sagen aber meistens damit, dass man dann die vorhandene Komponente nutzt, weil da steckt einfach auch schon so viel drin, was man direkt als Mitnahmeeffekt hat, also auf so vielen Ebenen, dass sich das einfach lohnt.
Ich würde jetzt mal einer Person noch das letzte Wort für die Design Systems geben und dann machen wir den den Deckel drauf und das Closing.

[2:38:48] Aber no pressure jetzt.

[2:38:52] Ich würde sagen, dem Stefan, der ist nämlich jetzt noch hier reingesneakt.
Oh Gott, ich habe gerade gesagt, ich habe je bewegend geschrieben, es ist no pressure und niemand muss aktiv werden.
Genau, aber ich, genau, ich kann ja hier, der Stefan, der hat ja in seiner Firma damals auch dieses hervorragende, wie hieß es, Diamond oder wie irgendwie sowas hieß das? Sketchmine.
Sketchmine, ja genau. Sketchmine gebaut.
Ja, aber ich glaube, so hervorragend war das dann gar nicht. Ja, das war super.

[2:39:51] Ihre Mock-Unterlagen laden und haben immer ein aktualisiertes Komponentensystem gehabt. Die Idee war cool.
Das Problem war halt, dass Sketch mit jeder meiner Versionen das Dateiformat verändert hat.
Es war auch kein öffentliches Format. Das haben wir eigentlich reverse-engineert und gehofft, dass wir irgendwie da was rauskriegen.
Und schlussendlich haben wir es bleiben lassen, weil es einfach den Aufwand da nicht gerechtfertigt war. Da war dann auch ein Zustand da, der war okay.
Und mit dem sind wir eigentlich ganz gut gekommen. Mittlerweile haben wir aber den Technologie-Stack geändert und wir nutzen jetzt React als Komponenten-System, also als Framework und ich glaube sogar Figma für die Mocks.
Und da gibt es ja recht gute Integration.

[2:40:42] Braucht man es nicht selbst machen. Wir hatten auch gerade im Chat schon, wir haben auch alle Links nach bestem Gewissen eingesammelt.
Die werden wir dann auch noch mal in die Shownotes und vielleicht in das YouTube-Video hinein editieren.

[2:40:59] Vielleicht finden wir da auch jemand, der oder die uns darüber was erzählen kann.
Ohne weiter darauf einzugehen, sonst hockt man hier noch lange, fällt mir dazu noch ein, die Technik von, ich hoffe, ich spreche es jetzt richtig aus, aus socio-technical systems design, um so eine ganze Firmenstruktur und die ganze Organisation und jetzt eben nicht nur aus der technischen und Design-Ebene zu strukturieren.
Ich haue da auch nochmal einen Link rein, dann schauen wir mal, dass wir eine Episode rauskriegen.
Ansonsten hatten wir jetzt heute drei Diskussionsblöcke.
Mal schauen, ob mein Kopf noch funktioniert. Aber heute ist ja noch gar nicht so spät. Es ist ja noch gar nicht 22.30 Uhr, wie sonst, wo mein Kopf schon mal halb schläft.
Wir haben gesprochen über Web Components, über den Framework Dschungel 2024 oder auch einfach ganz im Allgemeinen und über Design-Systeme.
Hat denn gerade jemand was auf dem Herzen, auf den Lippen, was ihr heute als Erkenntnis gelernt habt oder was ihr nochmal irgendwie im Hinterkopf habt und loswerden wollt?

[2:42:14] Also ich möchte nochmal eine Sache unterstreichen jetzt aus der letzten Diskussion.
Ich fand das interessant, auch nochmal von anderen Leuten zu hören, dass dieses Kommunikationsthema rund um die Designsysteme halt auch in anderen Teams halt ein großer Punkt ist.
Und das unterstreicht einfach nur nochmal meine Wahrnehmung.
Und das fand ich echt gut, auch nochmal zu hören, jetzt so aus den verschiedenen Perspektiven.
Von daher danke dafür auf jeden Fall.

[2:42:47] Für mich ist das in diesen Gruppen immer wieder so interessant, wie unterschiedlich und gleichzeitig wie gleich wir arbeiten.
Also eigentlich ist dann auch schon egal, mit welchem Framework, die gleichen Probleme haben wir trotzdem. Trotzdem, auf der anderen Seite arbeiten wir aber auch in komplett verschiedenen Team-Strukturen.
Es sind Open-Source-Maintainer mit hier an Bord, Leute, die mit JQuery zu tun haben.
Ich sehe das immer ganz spannend, je nachdem, mit wem ich spreche, dass es oft so einen Wir-Developer und die anderen, die Designer gibt.
Dann gibt es Team, da ist das alles so total vermischt und da macht man halt alles zusammen so ein bisschen.
Und deswegen, ich finde diese Gruppe immer unfassbar spannend und möchte mich auch nochmal persönlich bedanken für alle, die heute hier aktiv teilgenommen haben oder auch passiv mit dabei waren und hoffentlich auch ein bisschen was, Neues hören konnten.
Ja, kann ich mich anschließen und naja, vielleicht könnte man das ja öfters machen als 600 Folgen oder so oder alle 100, ja.
Hat mir echt gut gefallen und Und wir nehmen das mal mit und überlegen uns da mal was.

[2:43:58] Genau, und euch allen auf jeden Fall auch vielen, vielen Dank fürs immer reinhorchen in den Podcast.
Das ist echt super cool. Und dass wir jetzt schon 14 Jahre am Start sind.
Genau, und wir haben auch mal anlässlich unserer Sponsoren tatsächlich, haben wir mal ein paar Stats ausgesucht, die wir jetzt ganz frisch auf der Seite haben.
Das vielleicht noch so zum Abschluss. Seht ihr auch, wie oft ihr hier schon und wie viele Stunden ihr gehört habt möglicherweise.
Genau. Dann vielen Dank. Euch einen schönen Sonntagabend noch.
Auch an alle, die bei YouTube zugeschaltet sind und die das hier später nachhören.
Und dann hören wir uns und sehen uns vielleicht in der nächsten Ausgabe diesen Formates. Vielen Dank.
Ciao, ciao. Danke euch. Macht's gut. Macht's gut. Ciao. Danke, ciao.

[2:45:03] Music.

[2:45:18] Bis zum nächsten Mal.

Revision 600: Fishbowl-Diskussion

Webentwicklung: Themen sind Web-Components, Single-Page-Anwendungen, Backend-Ansätze, Framework-Auswahl, Team-Kommunikation und Designsysteme. Effizienz durch bestehende Tools und zukünftige Episoden zu ähnlichen Themen.

Chapters

Long Summary

Brief Summary

Tags

Transcript

Revision 600: Fishbowl-Diskussion

https://workingdraft.de/600/

Web Components

Erwartungen an den Framework-Jungle 2024

Design Systeme