Web Components – warum sind sie so hilfreich?


Ashley: Willkommen zur nächsten Ausgabe der Taktsoft Campus Podcast. Der Podcast für Software und IT Professionals. Mein Name ist Ashley Steel und heute habe ich Jonas Ulrich bei mir.


Ashley: Hallo, Jonas. Wie geht's dir heute?


Jonas: Hi! Gut, gut.


Ashley: Schön, dass du Zeit für uns gefunden hast. Und heute Abend geht es um das Thema Web Components. Aber bevor wir da einsteigen, magst du ein bisschen von deinem Werdegang erzählen und was du gerade so machst? Das wäre gar nicht ganz interessant für uns.


Jonas: Ja, gerne. Im Grunde angefangen mit Websites schon in der Jugend, früher viel Gaming betrieben und da brauchte man auch immer eine Website. Das war so der erste Kontakt im Grunde zu HTML. Und so weiter. So 2000 rum würde ich sagen ungefähr. Und dann 2003 mein Abitur gemacht und nach Bonn gegangen, um Informatik zu studieren. Das war damals so das Interesse, das auch lange gemacht, zehn Semester insgesamt in diesen zehn Semestern. Aber gelernt, dass ich nicht Informatik studieren möchte, tatsächlich, sondern eigentlich viel lieber arbeite, was dann halt auch recht früh, schon während dem Studium angefangen hat. Also ich glaube, 2005 haben wir das erste Mal mit Leuten, genau, die wir auch im Studium kennengelernt haben, eine Firma gegründet und seitdem haben wir eigentlich immer durchgehend mit Web Technologien zu tun gehabt. Ja so ist es im Grunde entstanden und seitdem arbeite ich bei der Rumesmeile als Entwicklungsleiter.


Ashley: Ja super viel erfahrung die du mal mit uns mal teilen kannst heute. So, wenn ich das Thema Web Components der Fall und vor allem bei mir erst mal so Sachen wie Thema Wiederverwendbarkeit oder Platform übergreifend dann das sind so die erste Sachen, die bei mir im Kopf kommen. Aber erstmal muss ich einfach mal die Frage stellen Was sind dann eigentlich Web Components? Was sind das für Dinge in Anführungsstrichen? Ja.


Jonas: Das hört sich wahrscheinlich greifbarer an, als es dann tatsächlich ist, weil es irgendwie dieses Komponente enthält, was irgendwie, glaube ich, für viele mittlerweile ein greifbares Wort ist, weil man den ganzen Tag mit Komponenten zu tun hat. Web Components selber sind aber erst mal nur ein STANDARD, also eine Spezification, die definiert, wie ich bestimmte Elemente schreiben kann. Also eine Erweiterung quasi von dem, was man als HTML kennt. Da kennen viele wahrscheinlich HTML, wie man es schon lange hat mit HTML4 und dann hieß es irgendwann HTML5. Und mit diesem Umstieg zu HTML5 hat sich halt auch so ein bisschen die Art Spezifikationen zu schreiben geändert. Vorher gab es halt eine große HTML Spec. Das war dann zum Beispiel der HTML 4.01 STANDARD. Der hat alles beschrieben, was mit Websites zu tun hatte. HTML5 hat damit im Grunde so ein bisschen aufgehört und angefangen zu sagen, es gibt verschiedene Standards, die parallel liegen, die auch irgendwie in Relation zueinander stehen, die sich beeinflussen und weiterentwickeln. Und in dem Kontext gibt es halt eine Reihe von solchen Spezifikationen, die unter diesem Mantel Web Components gefasst werden. Das ist, würde ich sagen, vielleicht etwas abgehoben noch, aber das sind Web Components, also im Grunde eine Sammlung von Spezifikationen, die das, was wir im Browser machen können, erweitern, also wie wir Elemente schreiben, wie wir mit JavaScript interagieren, da einfach bestimmte neue Dinge hinzufügen, um uns die Arbeit mit genau dem, was du gesagt hast, wiederholbaren Elementen, also Reviews, arbeiten zu können. Und um auch so eine Isolation erreichen zu können, was mit den bisherigen Mitteln nicht nativ möglich war. Dafür musste man dann auf ein Framework setzen, ob das reaktive oder andere, also die haben alle dann ja eigene Ansätze, wie so eine Komponente isolieren und an den Start bringen. Das ist dann hier quasi standardisiert der Fall.


Ashley: Dann vielleicht mal jetzt ein bisschen provokativ, dann du sprachst dann von von Spezifikation Satz Nummer vier HTML5, die es schon gab. Was ist denn jetzt eigentlich neu dran? Was, was, wo? Wo sind die Erneuerungen, die die neuen Eigenschaften, die, die mit Web Components man hat ja.


Jonas: Für den Einzelnen wahrscheinlich gar nicht so direkt spürbar, weil er je nachdem, welchen Ansatz er bisher verfolgt. Oder wenn er das noch gar nicht tut, dann ist es natürlich alles neu. Aber jemand, der schon mit React oder Angular oder ähnlichen Dingen arbeitet, der wird wahrscheinlich wenig überrascht sein von dem, was er in so einer Web Component weg sieht, weil er dann sagen wird Ja gut, das kann ich doch auch alles schon seit Jahren. Der Grund aber, das zu spezifizieren ist natürlich, da einen gemeinsamen STANDARD runterzubringen, also im Grunde diesem Gesamt Web Ökosystem eine Richtung zu geben und zu sagen, so soll das entwickelt werden und alle steigen früher oder später auf einen gemeinsamen STANDARD um. Also die Utopie ist natürlich, dass auch alle anderen, das heißt React und Angular, alle Web Components verwenden und damit so eine Komponente austauschbar wird, also sowohl in nutzbar als auch in react als auch in jeder anderen Sprache oder halt in einer ganz reinen HTML Seite. Und diese Standardisierung an sich ist eigentlich das Interessante daran, weil es lenkt, wohin sich das Web entwickeln wird, weil die Browser folgen der Spezifizierung, das heißt, welche Features wir zur Verfügung haben als Entwickler geht am Ende genau aus diesen Spezifikationen ja hervor.


Ashley: Und lasst uns dann nachher mal später zu diesen Themen Standards zurückkommen. Aber dann, bevor wir da einsteigen, welche Vorteile habe ich dann durch den Web Companies? Vorteile, die ich so in der Vergangenheit oder die jüngste Vergangenheit nicht gehabt habe?


Jonas: Du kannst Sachen direkt machen, für die du vorher Tuning benötigt hast, das heißt zusätzliche Komplexität in Form von Abhängigkeiten, Frameworks und Bibliotheken, die halt so was für dich gemacht haben. Aber die musst du halt auch kennen, die musst du einsetzen, dann nimmt nicht jeder das Gleiche. D.h. Das ist tatsächlich neu an der Stelle. Das ist anders und man bekommt halt die Möglichkeit, zum Beispiel als Autor von Komponenten selber diese halt wirklich unabhängig zu schreiben und nicht mehr davon abzuhängen, nur einen ganz spezifischen. Es sind ja nicht mal Nischen, unbedingt. Aber nur einen Markt bedienen zu können, also derjenige für React Komponenten zu sein, obwohl die Komponente selber von ihrem Aussehen, von ihrem Verhalten überhaupt nichts mit React zu tun hat. Also es muss keine Reaktion sein. Das ist einfach die spezifische Implementierung, die Weg dann voraussetzt. Und sich davon lösen zu können, würde ich sagen, ist das, was wirklich neu ist.


Ashley: Okay, verstehe. Und wenn, wenn du über Standards spricht, gibt es dann einen STANDARD oder gibt es mehrere Stände? Sprich Welche Bestandteile gibt es? Die, die standardisiert worden sind?


Jonas: Es gibt im Grunde nicht mehr jetzt ganz global gesprochen diesen einen HTML STANDARD. Das ist etwas, was seit HTML5 so nicht mehr existiert. Und da hat auch ein anderer Shift so ein bisschen stattgefunden. Vorher wird jeder viel über die W3C als Organisation gelesen haben, die Standards erlässt, die quasi die Richtung bestimmt. Und irgendwann so 2004 rum, glaube ich müsste es gewesen sein, wurde die WC AG gegründet. Im Grunde durch die Browser Hersteller selbst, die unzufrieden mit der Entwicklungsgeschwindigkeit der Standards waren und gesagt haben, so wie sich das entwickelt, kommen wir einfach nicht vorwärts. So alle bauen ihr eigenes Türmchen auf und nichts funktioniert mehr zusammen. Wir müssen Geschwindigkeit bekommen, damit das nicht völlig auseinander läuft. Und da haben sich dann halt alle großen Browser Hersteller zusammengesetzt, diese WC AG gegründet und gesagt, wir übernehmen quasi den STANDARD und seitdem folgen im Grunde, da würde ich sagen, folgt die web gemeinde im Grunde der WC AG in ihren vorschlägen und spezifikationen, weil am ende diese halt in browsern landen, also real dementsprechend mit dem wir arbeiten und in dieser wie der WC KG gibt es halt und da kommen wir dann genau zu dem Wort Components selbst. Im Grunde drei solche Standards, drei Spezifikationen, die eine Rolle spielen. Das ist interessanterweise auch nicht mehr Versionierung. Also auch da hat man nicht mehr dieses, das ist die 4.01 oder die 4.1 oder so, sondern das ist der STANDARD, die nennen das Living STANDARD mittlerweile also eben nicht wie bei Browsern, wo ja auch nicht mehr jemand sagt Hast du den Chrome 69 oder den Chrome 71, weil man halt den aktuellen Chrome hat? Ist das hier ähnlich von der Entwicklung? Es gibt nicht diese diskreten Zwischenschritte, sondern im Grunde einen lebenden STANDARD, auf den man dann verweist und davon also dieser lebende STANDARD, dieser HTML Living STANDARD heißt ja tatsächlich auch enthält zum Beispiel die Spezifikationen für Templates und Slots für Custom Elemente, also HTML Custom Elemente und zusätzlich gibt es die Dom Spec, die im Grunde beschreibt, wie das Dokument Object Model in HTML funktioniert. Das heißt, das, was wir alle schon lange benutzen, wenn wir Text schreiben, ist das Dokument Objekt Model auch mit JavaScript mit dem Dokument Object Model interagieren. Das tun wir auch schon sehr lange, ob wir jQuery benutzen oder nicht. Sowas wie Create Node und so sind Dinge, da arbeite ich auch heute schon mit dem Dom. Abgekürzt sagt man da ja auch gerne. Und da gibt es halt eine Erweiterung drin, den Shadow Dom. Das heißt, da ist es quasi ein Ausschnitt dieses lebenden Dokuments für die Dom Spec der Dinge, für die Web Components enthält, nämlich diesen Shadow Dom. Und beim HTML Living STANDARD ist auch alles, was HTML betrifft drin. Relevant für Web Components sind aber genau die Sachen zu Templates und Slots und zu HTML Custom Elements.


Ashley: Und das sind die wesentlichen Elemente, wo man sich darauf fokussieren sollte.


Jonas: Denn genau, es gibt noch die HTML Imports Zweck. Dies ist aber Working Draft. Daran wird auch noch gearbeitet. Das ist kaum einsetzbar. Man kann damit in verschiedenen Browsern schon experimentieren, es ist aber noch nicht gewährleistet, dass es dann Cross kompatibel ist. Also da ist diese Standardisierung einfach noch nicht durchgeführt zu Ende. Da wird es dann so ein bisschen darum gehen, weil wir es den anderen jetzt etwas ausführlicher sprechen, sage ich vielleicht einmal kurz was zu den HTML Imports. Da geht es einfach darum, auch Dokumente in andere Dokumente importieren zu können. Also wenn wir von so einem Dokument Object Model, so einen Dom Tree, also die Baumstruktur, im Grunde von Markup reden, einfach auch so eine Struktur importieren zu können. Wir können heute schon CSS importieren, wir können JavaScript importieren, es gibt aber keine native Möglichkeit in HTML HTML selber zu importieren. Darum dreht sich dieses Spec, all das, was es heute real gibt und was auch eigentlich gemeint wird, wenn man über Web Components redet, besteht aber aus diesen anderen drei Parts, also das Custom Element. Aus dem und aus diesen Templates und Slots.


Ashley: Und du hattest mehrmals Systeme. Ich sag mal so, die die Hersteller mit WCF AG das Thema Browser gibt es dann irgendwelche Abhängigkeiten, sondern muss ich mir Gedanken machen? Firefox, Chrome, Edge, Opera oder. Oder ich sag mal so, es ist Browser unabhängig, um das mal ein bisschen so platt auszudrucken.


Jonas: Es ist eine sehr, sehr berechtigte Frage, weil es sehr unterschiedlich ist. Also allein schon diese verschiedenen Spezifikationen, Spezifikationen, die wir jetzt angesprochen haben, sind unterschiedlich gut unterstützt, je nach Browser Hersteller. Das heißt, wenn ich Firefox und Chrome benutze, die da immer so ein bisschen mustergültig vorangehen, dann habe ich da keine Probleme. Die unterstützen das alles, was in diesen Spezifikationen steht. Bei den anderen Imports ist es etwas unterschiedlich, was sie jeweils unterstützen und wie sie es machen, aber das ist sonst vom Support voll. Opera ist da auch sehr gut, aber zum Beispiel Safari fällt dann da auch ab. Da ist es nur teilweise unterstützt. Das heißt es kommt dann schwer drauf an, welchen Teil der Spezifikation ich nutzen möchte, ob dieser kompatibel ist oder nicht. Ganz schlecht sieht es dann aktuell noch im Edge aus, wo es keine native Implementierung für Web Components gibt. Bisher. Die ist in Arbeit, da wird heiß dran gearbeitet, bin ich mir sicher. Aber das ist noch nicht fertig und das wirft dann auch im Grunde automatisch eine andere Frage auf Kann ich denn das Wort benutzen? Also da kann man sich ja fragen. Wenige von uns können sich glaube ich aussuchen. Meine Zielgruppe benutzt nur Firefox und Opera.


Ashley: Es reicht ja da das. Das kann man nicht machen. Eben eben.


Jonas: Und die Realität ist halt der Internet Explorer und mittlerweile dann der Edge sind natürlich auch im Umlauf. Weit verbreitet, einfach als STANDARD Browser auf vielen Systemen auch teilweise je nach System Umgebungen auch gar nicht anders erlaubt als den zu benutzen. Das heißt man kann das nicht wirklich ignorieren an der Stelle und deswegen ist die Frage sehr berechtigt. Kann ich denn damit irgendwas anfangen? Jetzt?


Ashley: Aber wie du sagst, ich denke die anderen Hersteller werden sich dann auch so in die richtige Richtung bewegen. Und wie bei allen Sachen ist da bis dann das das adoptiert wird.


Jonas: Genau das ist ja auch ein Druck der dann insgesamt aufgebaut wird. Genau eine gewisse Masse da ist. Dann kann auch keiner sich mehr verwehren dem Ganzen zu folgen. So ungefähr. Und das ist diese kritische Masse an der Stelle eben.


Ashley: Und du hattest auch, du hattest auch das Thema Frameworks angesprochen. Da gibt es dann bestimmte Frameworks, die man, die man heute benutzen kann. Und welche Frameworks wären das genau?


Jonas: Das ist ich würde das so ein bisschen zweiteilen. Es gibt sowohl Frameworks als auch Poly Fields. Was noch ganz interessant ist Diese Poly Fields erlauben im Grunde einfach nur, die nativen Funktionen auch in anderen Browsern zu verwenden. Das sind im Grunde auch kleine JavaScript Bibliotheken, die dann gezielt diese nicht vorhandene Funktionalität nachbauen und quasi kapseln, so dass ich als eins Web Autor normal meine Web Components schreiben kann, so wie es nach STANDARD richtig ist und dann sich dieser Poly Filterung kümmert, anderen Browsern das beizubringen. Dann brauche ich dann auch nur dort zu laden, wo entsprechende Funktionen fehlen. Und da gibt es schon ganz gute Lösungen, um auch zu sagen, ich möchte jetzt über Components selber schreiben, ich möchte gar nicht auf ein Framework zurückgreifen, dann kann man dort auf so Compiler oder Poly Fields zurückgreifen, die genau diese Funktionen für einen ergänzen.


Ashley: Und kann so ein paar von diesen Frameworks nennen das, dass man wirklich weiß, okay, ich kann dann da suchen.


Jonas: Genauso bei den Frameworks ist etwas einfacher. Bei den Poly Fields ist es tatsächlich so, dass es komplett auf das Problem ankommt. Also wenn zum Beispiel ein Browser keine Custom Elements unterstützt, dann brauche ich einen Custom Elements Poly Fill für diesen Zusatz. Da ist entsprechend sehr daran orientiert. Und da gibt es dann meistens auch genau eine Lösung, wenn man danach sucht, die das implementiert. Wenn es um die Frameworks geht, kann man da aber schon wesentlich konkreter werden, weil es da natürlich verschiedene Ansätze gibt und ja, auch etablierte Hersteller, also vieles von dem, was da jetzt heute verwendet wird, kommt halt aus größeren Umfeldern. Also es gibt zum Beispiel Polymer, das ist eine große große Framework Ansatz, der im Kontext von Google entwickelt wurde damals, unter anderem um das Material UI umzusetzen, also das, was man in den Web Applikationen von Google selbst sieht. Wenn die irgendwelche Komponenten einsetzen, dann sind das fast ausschließlich Material UI Komponenten. Und in diesem Material UI gibt es halt auch einen Teil, der in diesem Polymer drin ist. Das ist mit Element oder mit HTML. Das sind dann gezielte Compiler, die einfach nur Web Components für mich erstellen können, das heißt, ich schreibe HTML in einer bestimmten Form, wie das lit Element von mir erwartet. Das ist dann auch nicht der STANDARD, der web component oder so, das ist einfach wie literatur es macht. Und dann übersetzt mir lit html und with element das in eine web komponente, das heißt nutzt genau die richtigen Schnittstellen, die neu geschaffen wurden, konvertiert das Markup in eine Form, wie es nach Web Components erwartet wird, damit alles zusammenstecken wahr ist. Übernimmt quasi für mich diesen übersetzungs vorgang. Und das ist auch, was ich sagen würde, was heute die meisten machen, dass sie so eine Tool Chain verwenden, um das für sie zu machen. Und neben Polymer gibt es da viele andere Substanzen. Ist zum Beispiel auch sehr verbreitet, ist auch ein sehr zielgerichteter Ansatz. Kommt wiederum an der Stelle aus dem Bionik Umfeld, die so diese ganzen Phone Gelb Cordova Anwendungen, also Webanwendungen auf dem Handy. Bevor React Native sehr beliebt geworden ist, wurden ja oft die Anwendungen auf dem Handy quasi als Single Page Apps geschrieben, also als Web Apps, die auf dem Handy einfach nur in einem Browser Frame laufen. Da ist n Ioniq sehr groß geworden. Das machen wir aber auch nicht mehr nur. Und die haben unter anderem auch so einen Compiler geschrieben, der sich Stenzel nennt, der auch genau so ein Format entgegennimmt, eine leicht andere Template Sprache wieder hat, die aber am Ende auch dann kompatible Komponenten rendert.


Ashley: Und gibt es dann auch so ein Community rund um dieses Framework, so wo man gibt es so ein Community, wo man sich dann austauschen kann und mehr Informationen bekommen kann, lebt, lebt so ein Community.


Jonas: Schwierige Frage, weil sie tatsächlich an der Stelle schon lebt, aber glaube ich nicht so öffentlich ist oder zumindest nicht als so öffentlich wahrgenommen wird, weil man halt unterscheiden muss tatsächlich wieder wieder zwischen dieser Spezifikation Ebene, wo ja sehr trocken, vielleicht für manche über Mailinglisten kommuniziert und über komplexe Dokumente gesprochen und in zwei wöchentlichen Wikis gesprochen wird. Das ist halt schwierig für den durchschnittlichen Entwickler, da den Einblick zu haben und da so dran zu sein. Da muss man dann schon selber sehr viel Zeit investieren. Nichtsdestotrotz findet diese Entwicklung im Grunde komplett im Offenen statt. Also ich kann da reinschauen, diese Dokumente werden veröffentlicht, ich kann Protokolle von solchen Sitzungen lesen. Ich kann auch oft an diesen Sitzungen einfach teilnehmen, wenn ich Interesse habe. Sie sind auch nicht unter Ausschluss der Öffentlichkeit oder so, sondern das ist eine eine eigentlich sehr offene, transparente Geschichte, aber nicht so direkt nützlich für den Alltag. Und da kommt dann eher die Community des Ansatzes, den ich wähle, ins Spiel. Das heißt, wenn ich halt derjenige bin, der gesagt hat, bei Stenzel habe ich mein Glück gefunden, da fühle ich mich total wohl, weil das schreibt Templates genauso wie ich das Mag und da habe ich die richtigen Freiheiten und andere Sachen brauche ich aber nicht mich drum kümmern. So, dann werde ich halt in der Stenzel Community sehr fündig werden, wenn es darum geht sich darüber auszutauschen.


Ashley: Ich ich ich wollte zum Schluss eine Frage stellen und ich glaube es ist sehr schwierig zu beantworten bzw die Antwort wird wahrscheinlich sein, es kommt drauf an, wo starte ich dann das als Entwickler, wenn ich sage okay, ich will mich mit diesem Thema Web Components befassen. Ich habe verstanden, es gibt verschiedene Frameworks, es gibt verschiedene Plattformen, es gibt verschiedene Teile von Spezifikationen, wo, wo, wo fange ich denn überhaupt an? Das ist eine gute Frage. Man ruft dich an, oder das.


Jonas: Ist vielleicht ein bisschen zu teuer auf Dauer. Nein, es geht eigentlich ganz einfach, weil, wie gesagt, auch da ist es im Grunde sehr offen und ich würde da jedem empfehlen, tatsächlich mal auf die das Mozilla Developer Network als auf die MDM Dokumentation zu gehen. Die haben eine hervorragende Seite vom Scope einfach auch her zu diesem Thema, wo ich genau diesen Abriss sehe. Was sind die Teile der Spezifikation, was gehört dazu? Das sind aber auch nicht 400 Seiten. Ich muss nicht die Spec selber lesen, sondern es ist für mich heruntergebrochen. Und ich habe auch von da links auf Tutorials, die mit ganz einfachen Komponenten anfangen und ich würde auch da wirklich jedem empfehlen. Wenn einem das Thema interessiert, sollte man da anfangen mit den Basics. Und einfach mal so ein einfaches Beispiel selber sich im Editor zusammen hacken und im Browser testen und nachvollziehen, wie das ganze funktioniert. Weil es ist nicht kompliziert, es ist nur auf Dauer etwas. Wenn man das jetzt für hunderte Komponenten in einem sehr komplexen Frontend machen muss, dann will man das halt nicht mehr von Hand tun. Genauso wie wir ja auch nicht mehr CSS Dateien von Hand schreiben, sondern Saas benutzen oder nicht mehr jede HTML Datei einzeln pflegen, sondern Templates wie händelbar so oder so verwenden um uns nicht zu wiederholen. Genauso will man dann halt auch nicht das 100. mal die gleiche Template Funktion schreiben, sondern man möchte halt einfach, dass ein Framework einem diese Template Funktion abnimmt. Und deswegen glaube ich sollte man es zwar kennen, man sollte sich damit auseinandersetzen, man sollte wissen, was dahinter passiert. Am Ende wird man sich aber dann auf einen solchen Ansatz festlegen, wahrscheinlich um dann damit weiter zu lernen und dann ganz konkret auch was zu bauen.


Ashley: Ich denke, jeder der das Podcast bis zum Schluss gehört hat, wird froh sein, dass es dieses konkreten Tipp gibt. Da kann ich mal einsteigen, denn den einfachen Einstieg in ihn in diesem Bereich Super John ist das. War das Wahnsinn, was du da gerade erzählt hast? Ein sehr komplexes Umfeld, aber ich glaube, du hast wirklich die, die die wesentliche Teile da rübergebracht und vor allen Dingen diesen Tipps gegeben Welche Frameworks gibt es, wo, wo kann ich anfangen?


Jonas: Und ich hoffe, dass das auch möglich ist. Na ja, wir kann ja jetzt auch schlecht vier Stunden lang sprechen und selbst dann würde man es lange nicht ausschöpfen. Eben. Ich glaube, dass es für den Rahmen ein guter Einstieg und wir würden da will ich vielleicht einmal noch generell besprechen, da kann man einfach generell auch drauf schauen, wenn es um andere Themen geht. Web Components ist da gar nicht das einzige Thema. Da haben sich halt sehr viele Leute extrem viel Mühe gegeben, diese Themen zugänglich zu machen. Also genau diese Brücke zwischen Spezifikation und ganz konkretem Framework, so ein wenig zu schlagen, damit es eben nicht so unzugänglich bleibt. Und das kann ich einfach nicht oft genug empfehlen, die sind ja hervorragend.


Ashley: Die Dokumentation find ich toll, dass du da auch wiederholst und zum Schluss ja super. Johannes, ich bedanke mich recht herzlich bei dir, war sehr interessant. Vielen Dank für deine Zeit und ich würde sagen mal bis bald, mal wieder. Ja, super. Ciao. Tschüss. Talkshow Campus Podcast Der Podcast für Software und IT Professionals. Im Taxi Campus Podcast beschäftigen wir uns mit einem breiten Themenspektrum, um euch zu helfen. Praxis Fragen zu Technologie, aber genauso Fragen zur Umsetzung, Prozessen oder Projektorganisation. Danke, dass er dabei ward. Euer Talkshow Campus Podcast Theme.