Deep Dive 182 –

Vite mit Dominik Göpel

10.06.2025

// Podcast
// Deep Dive 182

Shownotes

Vite ist aus der Toolchain vieler Entwickler:innen nicht mehr wegzudenken. Mittlerweile unterstützen fast alle großen JavaScript-Web-Frameworks den Bundler – und das, obwohl das Projekt erst gut vier Jahre alt ist. Vielleicht benutzt ihr Vite ja schon lange, ohne es zu merken?

Wir haben mit Dominik Göpel einen echten Vite-Experten im Gespräch. Er ist als Maintainer Teil des Teams hinter Vite und spricht mit uns im Detail über das Projekt.

Von Dominik lernen wir mehr über die Entstehungsgeschichte von Vite und wie es damals von Evan You als Build Tool für Vue.js entstand. Außerdem erfahren wir, wie agnostisch das Toolset mittlerweile ist. Es geht um die verschiedenen Zielgruppen, die Vite bedient – von den Macher:innen selbst über diverse Framework-Teams bis hin zu zahlreichen Plugin-Entwickler:innen und den Entwickler:innen, die Vite in ihrem Alltag einsetzen.

Dominik berichtet uns von den architektonischen Entscheidungen, die für Vite getroffen wurden, um eine optimale Development Experience zu ermöglichen. In dieser Podcast-Folge erfahrt ihr, wie die Zusammenarbeit mit Frameworks wie Svelte, Nuxt oder Astro funktioniert und welche Tools das Team nutzt, um eine dauerhafte Kompatibilität zwischen dem Bundler und über 30 Frameworks sicherzustellen!

Download

/transkript/programmierbar/deep-dive-182-vite-mit-dominik-goepel

Jan: Hallo und herzlich willkommen zu einem neuen Deep Dive hier in der programmier.bar und wie Dennis das letzte Mal lustig festgestellt hat, mir gegenüber in der mittleren Ecke im virtuellen Studio sitzt heute der Garelt. Hi Garelt.
Garrelt: Moin. Moin. Hallo zusammen.
Jan: Moin. Garelt, wir wollten heute ein bisschen über JavaScript Toolchain
Dominik Göpel: Und
Jan: deswegen meine erste Frage an dich, hast Du Veed schon mal benutzt?
Garrelt: Ja, auf jeden Fall. Wir haben WordPress auf Veed umgebaut in dem Zuge auch, als wir U3 migriert haben und es war einfach alles besser seitdem.
Jan: Okay, das war nicht abgesprochen. Das wär auch super peinlich gewesen, weil ich wusste nicht, was Du halt Platz nutzt. Ich hab einfach gehofft, dass ihr schon irgendwie das Richtige macht und wie benutzt, so. Wenn der jetzt gesagt hättest, ja, nee, wir wir machen hier was ganz anderes oder was ganz Eigenes, das wär natürlich peinlich geworden. Mhm. So. Gut, dass wir alles richtig machen. Gut, dass wir alles richtig machen. Wir wollen heute nämlich über Viet sprechen und auch wenn Gerhard schon viel Ahnung von Vietat und das schon quasi jahrelang im Einsatz hat, gibt's Leute, die noch mehr Ahnung von Vietat haben und deshalb haben wir uns den Dominic eingeladen. Der ist nämlich Vietat Maintainer. Hallo, Dominik. Hallo, eingeladen. Der ist nämlich Vita Mainainer. Hallo, Dominic.
Dominik Göpel: Hallo zusammen. Schön, dass ich da sein darf.
Jan: Schön, dass Du da bist. Schön, dass Du dir Zeit genommen hast. Vielleicht einmal da draußen für alle, die noch nicht benutzen oder vielleicht, ketzerrischer formuliert, noch nicht bewusst benutzen, einmal abzureißen. Was macht denn für die Developer da draußen? Was ist so der 30 Sekunden Pitch?
Dominik Göpel: Veed ist ein sehr moderner Bundler. Und Bundler sind im Allgemeinen Tools, die Eingabedateien, HTML, JavaScript, CSS oder Format von diversen Frameworks nehmen und daraus wieder HTML, CSS und Java Script produzieren, was aber optimiert für die Browser dann ausgeliefert wird, sodass die Nutzer die Webseiten schön angezeigt bekommen und dabei möglichst wenig abgefeuert werden und die Anzeige möglichst schnell passiert. So, ne. Das ist letzten Endes ein Optimierungstool. Man kann das auch alles von Hand machen, aber da wird man leider verrückt bei.
Jan: Also ich ich muss ja sagen, ich mach Softwareentwicklung schon, weiß nicht, 15 Jahre oder so was. Als ich angefangen hab, war so was wie Galb irgendwie der heiße Scheiß damals, ja. Und und ganz davor gab's natürlich gar keine Tooltrainins, da hat man so seine eigenen Dateien einfach zusammengeschmissen und und und fertig. Und gefühlt dreht sich in diesem Ökosystem, wo ich ja immer nur so zugucke, weil ich da nicht so ganz hundertprozentig zu Hause bin, aber dreht sich das alle paar Jahre und es gibt irgendwie immer was Neues. So, da gab's mal Webpack und dann gab's Parcel und jetzt machen irgendwie alle wieder. Und ich frag mich immer so, muss das denn wirklich sein? So ganz ketzerisch einmal ein Zum Einstieg die Frage, ja? So was bringen diese neuen Bundler irgendwie immer so revolutionär mit oder was machen die anders, dass irgendwie alle paar Jahre die Leute ihre Bundler wechseln?
Dominik Göpel: Tja, warum bist Du auf Feed gewechselt, Gerd?
Jan: Sehr, sehr gut, sehr gut. Direkt zurückgespielt.
Garrelt: Also es ist, glaub ich, vor allen Dingen eine Performancegeschichte. Also am am Ende hat Viet einige Sachen deutlich besser gemacht als Webpack, vor allen Dingen das lokal Entwickeln, weil es da einfach viel, viel schneller geht. Die haben dann anderes System reingebracht und auch andere Technologien, die Webpack so nicht hatte, so was wie E-S Bild, was dahintersteckt. Aber am Ende auch einfach viel, viel bessere und einfachere Konfiguration. Es war halt neu gedacht. Webpack war einfach 'n Pain, so bestimmte Dinge zu machen. Macht das viel besser. Und am Ende auch 3 hat das so empfohlen und das hat halt so gut synergiert so, ne, weil die die ganzen Tutorials und alles, was man online gefunden hat, immer so, ja okay, so machst das halt mit.
Jan: Und das muss ich ja sagen, Dominik, da kannst Du deine eigene Einschätzung auch dazu geben, aber das ist für mich als als Anwender gefühlt so der wahre Siegeszug von Veed, ja? So diese echt starke Integration halt mit allen Frameworks da draußen gefühlt. Also ich hab, glaub ich, meinen Erstkontakt mit Veat war über Remix damals, als Remix relativ neu war noch und wir das bei Shopify son bisschen ausgebaut haben. Aber wie Garant schon sagt, ne, am Ende nimmst Du halt das, was dein Framework empfiehlt und viele Frameworks empfehlen dir halt einfach oder supporten halt Veat out of the Box und denkst halt, na gut, dann ist das schon mal eine Technologie weniger, die ich lernen muss, weil Veat hab ich schon bei, weißte, ne, bei Remix mal genutzt und jetzt will ich irgendwie View machen und dann ist irgendwie Remix auch wieder so eine Komponente, die schon kennen. Und das ist natürlich eine coole Stärke, so.
Dominik Göpel: Ja. Also ich ich bin 'n bisschen schlecht da drin, uns selbst zu loben, aber das Veed es sehr einfach macht, damit zu integrieren, ist tatsächlich 1 der wichtigen Faktoren, warum Veed so populär geworden ist. Es wurde jetzt 'n bisschen was Negatives über Webpack gesagt. Das kann ich teilweise so unterschreiben. Ich selber hab lange 'n Angela entwickelt und dort Webpack zwar mit 1 Abstraktionsschicht dazwischen, aber teilweise dann auch wirklich hautnah selbst erlebt. Das ist schon 'n echt schwieriges Ding, grad für Plug in Entwickler mit Webpack zu integrieren, ist eine andere Hausnummer als ein ein Lead Plug in zu schreiben. Und das hat eine einen ganz einfachen Grund. Eine der wichtigsten Entscheidungen, die Lead am Anfang getroffen hat, ist, dass sie sich der Plug in API von Rollup bedienen und diese erweitern. Und die Rollup Plug in API ist sehr anwender- und entwicklerfreundlich, weil sie auf 'nem einfachen Hooksystem basiert. Und wirklich jeder kann sein eigenes Weed Plug in in 'n paar Zeilen Code in seinen Weed Config reinschreiben. Du musst noch nicht mal eine eigene Datei dafür aufmachen. Wenn Du irgendwas an Weed anpassen willst, kannst Du mit 10 Zeilen Code, kannst Du 'n eigenes virtuelles Modul erschaffen und das war's. Und ich erinner mich noch dran, dass ich mal irgendwie total geflasht war, als es ein Webpack Plug in gab, was ein eigenes Plug in Ökosystem hatte. Also Plug ins mit Plug ins, Mhm. Die auch anders geschrieben wurden als die eigentlichen Webpack Plug ins. Und wie macht er einen Schritt zurück von der Komplexität her? Und das hilft halt enorm, weil wir den den Frameworkautoren es halt dann auch leichter machen, ihr Framework zu unterstützen. Also es ist wirklich eine Menge Integrationsarbeit, die wir machen. Und wir arbeiten auch mit den Frameworks zusammen. Die Weat Mainainer setzen sich teilweise auch aus den Mainainern anderer Frameworks mit zusammen. Ich arbeite unter anderem auch im Svelt Mainainer Team mit. Ein anderer Weat Mainainer ist bei Astro. Und View ist natürlich ganz stark vertreten durch Avenue, Anthony Fuu und da kommt Veat auch ursprünglich her. Sollen wir jetzt mal 'n kurzen Abriss über die die Geschichte machen, wieso kam Veat daher? Avenew wollte eigentlich eine Viewspezifische Tool Change schaffen und er war unzufrieden mit den der Developer Experience und wollte besseres Hot Modul Reloading vor allem. Also schnelleres Austauschen von geändertem Code direkt in der Anwendung, sodass man eben kürzere Feedbackzyklen hat. Und das basierte zu 'ner Zeit, die eigentlich ziemlich ungünstig war. Da war grad Corona fing an und die Developer Landscape war eher son bisschen in Aufruhr. Alle gingen irgendwie nach remote und ich hatte auch meinen Auftrag verloren grad und dann bin ich an, so mich umzuschauen, was kann man denn sonst noch machen außer Engva. Und da hab ich dann gesehen, der Evan macht das, aber das ist für View. Und dann hab ich angefangen, ja gut, Svelt ist cool, kann man da nicht auch irgendwie Svelt reinhacken? Und dann hab ich da sone kleine Miniintegration gebaut damals. Und irgendwann hat Evan dann aber auch gesehen, dass, wenn er das jetzt nur für für View macht, dass ihm das zum einen 'n Haufen Arbeit macht, das langfristig selber zu entennen und zum anderen, dass es halt auch wirklich nützlich für andere ist. Ich war nicht der Einzige, der wie dann auch für andere Sachen ausprobiert hat. Und dann haben sie irgendwann gesagt, okay, Cut, wir rebooten das ganze Framework agnostisch und wir ändern die API auch 'n bisschen. Und dann kam eben diese roll up basierte API und dann ging das am Anfang noch relativ gemächlich, aber schon nach kurzer Zeit ist das tierisch explodiert. Und heute gibt's eigentlich kaum ein Framework, was nicht von BEIT unterstützt wird. So die großen Frontendlibraries und Frameworks unterstützen's eigentlich alle.
Jan: Jetzt hat Googelt und Du, ihr habt ja im Prinzip 'n ähnlichen Punkt gemacht, ne? So Developer Experience ist irgendwie superwichtig für Wild. Egal, ob Du jetzt 'n 'n Plug in baust, ob Du 'n Framework Mainainer bist oder ob Du halt am Ende der der Anwender, der Entwickler bist, der es einfach nur in seinem Projekt irgendwie benutzt. Ja, das soll für alle irgendwie supergut funktionieren und das ist quasi eine bewusste Entscheidung auch gewesen. Wie schlägt sich denn das in der Architektur von Wiet durch, ne? Weil natürlich so sagen, dass sonst das wichtig ist, das kann ja irgendwie erst mal jeder. Aber irgendwann trifft man ja dann doch auf irgendwie ernstere Konsequenzen. Man muss überlegen, okay, wenn wir's den Leuten da draußen möglichst einfach machen wollen, heißt das ja ganz oft, dass wir's uns intern 'n bisschen schwieriger machen müssen. So. Was sind denn so Beispiele in der in der Wied Architektur, wo ihr echte Brocken aus dem Weg schaffen musstet, es da für allen anderen sehr einfach zu machen?
Dominik Göpel: Ein Beispiel, wo WIT intern im Moment noch ein bisschen schwieriger und komplexer ist, ist der Optimizer. Da muss ich vielleicht noch mal einen kurzen Schritt zurückmachen. Ich hab ja schon Hot Modul Reloading erwähnt. Das, warum das in Veat so schnell und gut funktioniert ist, weil Veat einfach anbandelt, ECMaskript Modul Loading macht. Das heißt, der Browser kriegt ganz viele kleine JavaScript Dateien, der kriegt kein großes Bundle während der Entwicklungszeit. Das funktioniert so lange gut, solange Du nicht eine library lädst, die 10000 hat. Weil da müssen 10000 kombin Files kompiliert werden und 10000 als zum Browser geschickt werden. Und 10000, die stoßen dann an Limits, weil der Browser nur 10 oder 100 gleichzeitig kann. Und dann kriegst Du son Wasserfall rein und alles dauert ewig. Das zu verhindern, geht hin und macht für Dependencies. Das heißt, deine wird von einem IS Bild Plug in, IS Bild ist nicht Rollup, unter der Haube zu einem einzigen Javaskript Bundle verpackt und dann deiner Anwendung wieder untergeschoben, sodass eben nicht 10000 requests passieren, sondern nur 1. Und dass Du's auch nicht ständig neu bauen musst, obwohl sich die Dateien nie ändern. Und das ist schon komplex. Und das ist auch etwas, wo sich die Entwicklungsumgebung im Dev Mode von deinem Production Bundle unterscheidet. Weil in deinem Production Bundle hat Rollup die Icon library wiedergebandelt. Das heißt, Du hast einmal den IS Bild Bundling und einmal einen Rollup Bundling. Und die funktionieren zwar in den Schritten ähnlich oder gleich, wie wir es wollen, aber es wäre natürlich besser, wenn Du nur eine Toolchain hättest. Und da arbeiten wir im Moment dran, dieses Ziel möglich zu machen. Aber im Moment ist das noch nicht so und das ist son bisschen, sag ich mal, versteckte Komplexität. Aber der Anwender kriegt davon relativ wenig mit, so Leute wie ich, die dann Lead Plugins Welt bauen, was dann im Hintergrund noch 'n IS Bild Plug in mitbringen muss, damit das mit dem Prebunting auch funktioniert, die haben wir dann eher mit zu tun. Aber das ist das ist wirklich schon, das ist advanced, da kommt ein Anwender nicht mit in Berührung und das ist letzten Endes auch der der Punkt, wo's dann wieder für für die Anwender mit funktioniert. Das minimale Projekt sind 2 Dateien. Eine package dot JSON und eine Index html. Und dann kannst Du und machen und das funktioniert. Du könntest sogar die Index HTML weglassen, dann machst Du eine Veed dot config dot j s und lieferst alles irgendwie virtuell aus 'ner Datenbank oder so. Aber das ist wirklich alles, was Du brauchst. Mehr, also Veed ist viel einfacher geht's nicht.
Jan: Mhm.
Garrelt: Das find ich total spannend, was Du erzählst, was diese Optimizer angeht. Und da hab ich direkt eine Frage, was unser Projekt betrifft. Weil wir haben ein ziemlich großes Projekt und ich merke, dass das initiale Laden immer superlange dauert, genau aus dem Grund, was Du eben genannt hast. Das ist halt, wir haben irgendwie, haben denn schon, 300 Komponenten oder so und der erste dauert 10 Sekunden. Denkt dir auch darüber nach, dass man das so konfigurieren kann, dass man auch Teile seines eigenen Projektes dann so optimiert, indem er das wandelt, wo Du sagst, okay, ich entwickel grade in dem Package und der Rest ist mir eigentlich egal beziehungsweise in dem Ordner in meinem Projekt. Und der Rest könnte auch optimiert werden? Glaubst Du, so was wäre möglich mit dem, was ihr grad macht?
Dominik Göpel: Ja und nein. Ich hatte's ja eben schon kurz angeklungen. Wir arbeiten daran, dass wir die diesen Optimizer, der auch erst bildbasiert ablösen. Dazu wird grad Roll-up quasi in Rust neu implementiert. Das Projekt nennt sich Rolldown. Da sitzt 'n Team dran, das aufgebaut hat. Und wenn das so weit ist, dann können wir erst Bild im Optimizer austauschen durch Rolldown und dann funktioniert Bild und Dev gleich. Mhm. Und ein oder 2 Schritte danach kann man dann drüber nachdenken, dass auch Dev nicht mehr anbandelt, funktioniert, sondern dass auch während dem Development ein Bundling stattfindet. Mhm. Und dann könnte man sich tatsächlich so was ausdenken wie, wir wandeln jetzt einen Teil und dann lassen wir nur den anderen Teil anbandelt. Da kommst Du aber auch wieder in Probleme, weil sobald Du anfängst, eine Datei zu bearbeiten, müssten wir die quasi aus dem Bundle dann oder jedes Mal das ganze Bundle neu bauen. Mhm. Das heißt, das ist 'n 'n Trade off. Wenn Du jetzt 10000 Files in deiner Anwendung hast, die alle für den initialen request wichtig sind, ist halt dann an der Stelle von mir auch die Frage, ob man die Anwendung vielleicht 'n bisschen anders strukturieren könnte. Ja. Sachen in auslagern, muss man mal schauen. Aber ja, in Zukunft wird da auch 'n Beat mehr möglich sein. Aber 10 Sekunden klingt jetzt erst mal nach viel. Ich kann mich noch sehr gut dran erinnern, wie ich vor 4, 5 Jahren irgendwie erst mal Kaffee holen gegangen bin, als ich den Angwähler Dev Server gestartet hab. Weil der muss erst mal alles bauen und dann hat das 2 Minuten gedauert, weil der Kunde eine sehr große Plattform betreut hat. Ja. Ja. Also 10 Sekunden ist schon Längen besser als vorher und
Garrelt: Keine Frage. Aber da das Submasche Reloading dann so schnell geht, ist da halt der Unterschied so bemerkbar.
Dominik Göpel: Ja, das stimmt.
Jan: Habt ihr da so Erfahrungswerte, was so eigentlich der durchschnittliche User an an Projektgröße hat? Weil jetzt, wenn Garrit sagt, na ja, Sie warten hier 10 Sekunden, bis son 'n Wortblitzbild mal durch ist, dann klingt das ja, ne, Du sagst schon erst mal viel. Aber wenn Du jetzt sagst, na ja, die die meisten unserer großen Projekte da draußen, die haben 2 Minuten und ihr könnt euch über eure 10 Sekunden eigentlich noch glücklich schätzen, dann rückt es das ja auch irgendwie in Perspektive.
Dominik Göpel: Also da bin ich son bisschen tatsächlich auf Kriegsfuß mit all diesen Leuten, die ganz große Projekte als den Treiber für den Bedarf angehen. Also diese ganzen Benchmarks, die 10000 Module in 1 Anwendung haben. Wir haben bei Webseiten, wenn man da mitm Chrome Web Dev Tools Profiler draufgeht, sagt er dir, hey, deine initiale Seite hat mehr als 1000 Doneds. Bist Du dir sicher, dass das so gewollt ist? 10000 Module für 1000 Doneds klingt jetzt erst mal, ne, für jedes, irgendwie 10 Module ist 'n bisschen viel. Also meiner Meinung nach sollte man in Standardanwendungen längst nicht in diese Größenordnung kommen. Und ich bin mir ziemlich sicher, wenn man einen Durchschnitt über alle Beat Anwendungen bildet, dass man unter 100 rauskommt. Weil die meisten Anwendungen sind einfach klein. Das sind kleine Blogs, Privatanwender, die schnell mal eben was hochgezogen haben. Neuerdings AI generierte Dinge, die wahrscheinlich die zehntausendste To do Liste ever sind, aber die haben alle halt 10, 15, 20 Module. Da stecken son paar ganz große Apps wie riesige Nadeln aus dem Chart raus und die ziehen den Durchschnitt dann vielleicht 'n bisschen nach oben. Aber im Endeffekt für den Normalanwender ist es wie auf der Straße auch der normale Familienkombi oder der Kleinwagen, der tut's. Du brauchst keinen Ferrari und keinen Formel 1 Rennwagen. Die Tatsache, dass das mit wie trotzdem möglich ist oder möglich sein wird, ist fantastisch. Aber das sollte nicht unser Maßstab sein. Da ist es viel wichtiger, dass es einfach ist und nicht in deinem Weg ist.
Jan: Wenn wir schon in der Richtung unterwegs sind, gibt es auch Use Cases, also wie, so wie ich das historisch verstanden hab, kommt ja aus dieser reinen Frontend Geschichte, ne? Hast Du eben gesagt, so View und und so weiter, ja? Gibt es aber auch da mittlerweile Use Cases, wo sagst, boah, da wollen wir irgendwie gar nicht hin oder das ist was, was wir jetzt grade noch gar nicht können und da das wollen wir gerne irgendwie zeitnah noch abbilden, ja. Server Side Rendering wird grade wieder 'n bisschen populärer. Irgendwie fangen Leute jetzt auch an, ihre ganzen Applikationen in son War Zoom Binary irgendwie reinzukompilieren so, ja? Das sind ja auch alles Edge Cases, wo man sich mit Viel Fantasie auch Veed vorstellen kann, ja? Ist so ist das was, was euch beschäftigt? Oder sagt ihr, na, wir haben hier so unsere Nische und wir sind eigentlich ganz glücklich damit, wo wir jetzt grade sind?
Dominik Göpel: Also Veed ist ein Community Project. Das heißt, die Entscheidungen, die wir treffen, Veed besser zu machen, kommen daher, dass wir mit vielen Frameworkautoren zusammensprechen. Und wenn die Bedürfnisse haben, dann versuchen wir das abzubilden. Und das machen wir nicht aus Selbstzweck, weil wenn wir nicht das machen, was die Leute brauchen, dann braucht am Ende niemand mehr Viet. Und was wir mit 6 gemacht haben, ist, wir haben eine neue API eingeführt, die nennt sich die Environment API. Da beschreibt man quasi Laufzeitumgebungen als separate Entität. Das heißt, genau das, was Du jetzt gesagt hast, eine Serversite Branding Umgebung, die ja in Node. Js oder einem Edgeworker funktioniert, kann man in in Veed beschreiben. Und das führt jetzt zum Beispiel dazu, dass Cloudflare ein Cloudflare Environment für Veed entwickelt, was dann Frameworks wiederum benutzen können, damit Anwendungen auf Cloudflare zu deployen. Und der Nutzer hat dann aber, wenn man Veed dev aufruft, eine Developer Experience, die sehr nah an seinem ist, wie's in Cloudflair funktioniert. Also im Cloudflair, das ist jetzt nur 'n Beispiel, weil dies die Ersten sind, die's gemacht haben und das geht mit Valerie, Netylfin und allen anderen auch. Die haben einen Programm, das nennt sich Miniflare. Das ist letzten Endes eine Simulationsumgebung für das Cloudflare Production Environment, die auf deinem Rechner läuft. Und früher war's in Wied so, dass Du quasi Miniflare ausführen musstest neben Wied. Und dann hast Du über Umwege son Proxy Hintertürchen in diese Miniflare Umgebung gemacht, sodass dann deine Anwendung eben Miniflare benutzen konnte, auf die Dev Ressourcen von Miniflare zuzugreifen. Und jetzt mit der Environment API ist es genau umgekehrt. Wied läuft jetzt ins innerhalb von Miniflare und hat quasi genau dasselbe Environment wie später in Production auch, sofern Cloudflare und Miniflare so hinkriegt, dass es das tut. Aber das heißt, diesen diesen Tunnelhintergrundweg, den Du früher selber programmieren musstest und der ziemlich blöd und anfällig war, den brauchst Du jetzt nicht mehr. Du kannst also solche Umgebungen einfach in in vat API beschreiben jetzt. Und das bezieht sich jetzt nicht nur auf Edge Umgebungen. Du kannst das Ganze auch auf eine Browser Extension runterbrechen oder native Anwendungen, also 'n Tauri Environment oder 'n oder was auch immer, kannst Du machen. Und Du brauchst auch nicht nur 2 Environments. Also es gibt ja auch 'n Browser Environment natürlich. Du kannst auch mehrere Environments haben. Da gab's von Suffy Red 'n ziemlich coolen Talk da, der mit Hono 4 Environments gebaut. Das war einmal 'n Serviceworker, dann eine Edge Run Time und noch was. Und das hat alles zusammen funktioniert. Und es war einfach sehr straight forward in in in Veep Config beschrieben. Und Du konntest das alles separat testen. Und da kommen wir auch grad noch zu 'nem Thema, der bei Veep sehr wichtig ist. Testing ist quasi in einem sehr großen Schwesterprojekt auch supereinfach geworden. Das nennt sich V-Test und integriert sich quasi 1 zu 1 mit 1 Veedconfig. Ich weiß nicht, wer von euch früher mal just konfigurieren musste.
Jan: Aber vielleicht bevor wir bevor wir da hinspringen, lass uns noch ganz kurz über Environment sprechen, weil das find ich super superspannend eigentlich, ja. Gerhard bestimmt auch, weil wir haben ja auch so verschiedene Environments, auf denen wir unterwegs sind. Aber vielleicht für mich als Laien da so an der Stelle, wie muss ich mir das vorstellen? Beschreibt ein Environment in Veed einfach nur Capabilities und Limitationen von 'nem Environment, quasi diesen Bildprozess son bisschen anzupassen? Oder bring ich da als Environment wirklich sone Art mit? So klang es ja grade bei dir mit Flair, ja? Oder oder auch mit Tauri, wo ich son son son kleines Tauri Package vielleicht schon hab, wo ich meine Anwendung einfach reininjekten kann. Was was bringt son Environment alles mit? Was macht das aus?
Dominik Göpel: Also die dieses Environment ist
Jan: letzten Endes, ist das eine
Dominik Göpel: letzten Endes, ist das eine eine Laufzeitumgebung wirklich. Okay. Und das hilft dir dann für diese Laufzeitumgebung spezifische Dinge zu machen. Das heißt, bestimmte Globals, die es gibt oder nicht gibt, Bestimmtes Verhalten wie Modul Resolution. Das ist in Veed 5, bevor es diese Environments gab, gab es einen Modul Graph, der aber 2 Arten von Modulen kannte. Der kannte Server Side Rendering Module und der kannte Client Module. Insbesondere bei View und Svelt werden die mit derselben Datei beschrieben, aber die werden dann unterschiedlich kompiliert, je nachdem, ob das SSR Flag gesetzt ist oder nicht. Und das führt aber dazu, dass Du dann im Hintergrund, wenn dich interessiert, wie sieht denn dieses Modul jetzt in der SSR Umgebung auf, dann musstest Du moduel Graph get SSA Load Modul aufrufen. Das heißt, Du hattest jedes Mal einen anderen Function Call, den Du machen musstest, wenn Du jetzt ein Modul der spezifischen Umgebung haben wolltest. Das hat zu 'ner Menge Branching innerhalb von Plug ins geführt. Und jetzt, wo Du dem Plug in ein Environment mitgibst, für das es grade zuständig ist, kannst Du halt einfach machen und bist fertig an der Stelle und musst diese Entscheidung nicht mehr treffen. Und das heißt, wir haben jetzt eine eine klarere Separierung und es gibt nicht mehr nur SSA und Client, sondern eben beliebig viele Environments. Du kannst auch mehr als ein Client Environment haben, eine native App und eine Web App. Wir wissen noch nicht genau, was man damit wirklich alles machen kann. Ich hoffe, die Community wird sehr viel kreativer sein, als wir das hier könnten.
Jan: Das freut natürlich den Deno User in mir. Aber Garald hat, glaub ich, auch noch eine Frage.
Garrelt: Irgendwie, ich weiß, ich stell's mir grad 'n bisschen so vor, als wär das wie son Container. Weil diese Konfiguration, von der Du sprichst, dass Du sagst, okay, Du hast eine eine, kannst genau definieren, was sind da für globale Variablen. Klingt für mich sehr ähnlich zu soner sonem. Ist das son bisschen vergleichbar, dass Du einfach sagst, okay, Du definierst ja, so diesen Container, in dem dann einfach läuft und musst dich halt nicht mit Docker oder so beschäftigen?
Dominik Göpel: Nicht nicht ganz. Das ist quasi eher eine Stufe dadrunter. Du beschreibst quasi das Deployment Target und sorgst mit den Environments zur Entwicklungszeit dafür, dass diese Umgebung eben auch in der Entwicklungsumgebung genauso verfügbar ist. Aber der Outputs sind weiterhin Bundles, das heißt, JavaScript, HTML, CSS und so weiter. Das heißt, Veed ist an der Stelle einfach ein ein Webapplication Bundler. Du kannst damit jetzt dann auch andere Sachen wandeln.
Jan: Mhm.
Dominik Göpel: Aber das ist quasi dann Aufgabe der Plug ins, das zu tun. Und die Bereitstellung der tatsächlichen Laufzeitumgebung, also am Ende, wie Du's in Cloudflare reinkriegst, in die Production Umgebung, das ist jetzt nicht mehr Teil von selbst. Das heißt, die meisten Frameworks haben dann 'n Konzept, das nennt sich Adapter. Da gibt's dann einen Adapter Versell oder einen Adapter Netlify und den kannst Du dann in deine Konfiguration mit einhängen.
Jan: Mhm.
Dominik Göpel: Und dann kommt dann am Ende eben ein für die Plattform angepasstes Output Format raus und das schiebst Du dann hoch mit Okay. Der, CLI oder mit Rangler oder was auch immer.
Jan: Jetzt hast Du ja auch wieder gesagt, eben auch, dass Vita mit supervielen Frameworks auch zusammenarbeitet und auch, dass ihr selbst ja auch in anderen Frameworks mitarbeitet sozusagen, ja? Aber wie muss ich mir das technisch vorstellen? Weil das klingt schon nach soner sehr großen Herausforderung bei jedem Veed Release irgendwie sicherzustellen, dass man keine von diesen ganzen Integrationen bricht und dass auch die die Roadmap, die Veed ja intern oder öffentlich, keine Ahnung, ne, dass die auch mit den anderen Frameworks son bisschen zusammengeht und dann nicht coole Ideen, die ihr habt, wenn ihr jetzt Rolldown bauen wollt, ja, dass das irgendwie, weiß ich nicht, die ganze Remixintegration kaputtmacht oder so was. Wie wie wie wie stellt dir das sicher?
Dominik Göpel: Da gibt es ein Skript oder ein kleines Tool, das nennt sich Weed Ecosystem CI. Das führt letzten Endes ein Bild aus und baut den aktuellen Branch oder irgendeinen Branch, den Du als Parameter übergibst. Und dann nimmt es dieses Bild und lingt es quasi in den Main Branch von Svelt Kit und führt dann die Svelt Kit Testsuit damit aus. Und wenn dann jetzt die Testsuit von Saltkitit auf einmal einen Fehler wirft, dann müssen wir das untersuchen, gucken, ob jetzt die Änderung ein Beat für diesen Fehler verantwortlich ist oder nicht. Und das machen wir nicht nur mit einem Framework, sondern mit ungefähr 30.
Garrelt: Ist aber viel.
Dominik Göpel: Ja. Und das läuft einmal zeitgesteuert, das heißt, jeden Montag, Mittwoch und Freitag morgens früh 5, einfach Änderungen auf dem Mainbrunch abzufangen. Wir können das aber auch in jedem PR mit 'nem Kommentar triggern. Das heißt, wenn wir jetzt eine experimentelle Änderung haben und wissen wollen, ob die was kaputtmacht, dann kriegen wir das darüber mit. Und das hatte ich damals angefangen, weil ich eben die Integration von Beat und Saltkit immer aufm aktuellsten Stand halten wollte und dann fing da aber wie die Leute an zu sagen, hey Dominik, wie bist Du immer so schnell damit? Und dann ja, ich mach das hier manuell bei mir lokal und ich link das dann immer und dann hab ich das halt 'n bisschen automatisiert und seitdem kriegen wir da ziemlich gutes Feedback. Wir fangen manchmal auch Fehler ab, bevor sie dann tatsächlich in in einen Lead Release reingehen. Das heißt letztens erst in der Web 6 2 Beta gab's 'n 'n Change, der eigentlich intern war, aber der durch einen Seiteneffekt auch UNO CSS und DAX betroffen hat. Und da haben wir dann gesehen, oh, die Testcases sind fehlgeschlagen und dann konnten wir einen Check in einbauen, sodass die Nutzer davon am Ende nichts nichts mitbekommen haben. Das ist werden diesen Check irgendwann auch wieder ausbauen, weil der technisch nicht notwendig ist, aber es macht jetzt für uns keinen Sinn an der Stelle irgendwie auf, das war aber intern und Samware und ihr hättet besser aufpassen müssen, rumzureiten, wenn Millionen von Nutzern dann am Ende eine schlechte Experience haben und das rund den Globus halt viel, viel Arbeit verursacht. Und dieses Projekt, das trägt zu 'nem großen Teil zu der Stabilität von Deep Buy. Und das wird auch benutzt, jetzt Rolldown zu testen. Das heißt, es gibt schon eine Alpha von Rolldown BEAT. Das heißt, BEAT mit einem Rolldown Unterbau. Und das führt genau die gleichen Tests aus. Und mein letzter Stand ist, dass alle bis auf 2 aktuell schon grün sind. Das heißt, ich würd mal davon ausgehen, dass es relativ bald zu 'ner Beta von Rolldown Meet kommen wird.
Jan: Siehst Du grad? Dann kannst Du mal gucken, ob dein Bild immer noch 10 Sekunden dann braucht. Aber wie oft triggert denn dieses hier einfach? Also gar nicht gar nicht als Vorwurf, dass ihr schlechte Software bauen würdet oder so, ne, sondern ich stell mir einfach vor, wenn Du so viele Integrationen hast, also bei irgendeiner ist ja andauernd wahrscheinlich irgendwas, ne. Wie viel beschäftigt euch das?
Dominik Göpel: Das sind schon viele Trigger. Manche sind auch länger rot. Wir analysieren das dann und wenn sich aber rausstellt, dass das an der von dem jeweiligen Projekt liegt, dann pingen wir dort. Und wenn das dann ein, 2 Wochen dauert, dann ist das so. Aber grad vor major Releases von wep legen wir sehr großen Wert drauf, dass eigentlich alle Tests in 'nem grünen Zustand sind, damit wir selber halt auch wissen, wenn wir jetzt was Großes ändern, dass die Fails dann eben für uns 'n guter Indikator sind. Es ist schwer, das mit Zeit zu beziffern. Ich will's lieber nicht tun, weil die Zeit krieg ich leider nicht bezahlt. Aber das ist meine Contribution an die Open Source Community und an Weed und warum ich auch bei Weed bin, dass ich da manchmal reingucke. Und es geht von 5 Minuten, bei komplexeren Sachen sind das dann auch schnell mal irgendwie 30 oder eine Stunde. Und wie gesagt, es läuft mindestens dreimal die Woche, aber teilweise auch häufiger.
Garrelt: Versteh ich das richtig, dass so deine Aufgabe dann auch oft ist, das zu überblicken, zu gucken, okay, ist kommt das jetzt durch uns? Woran könnte das liegen? Oder bist Du dann auch aktiv dabei, diese Bugs zu fixen? Also wie viel entwickelst Du und wie viel machst Du so Organisationen für Veat?
Dominik Göpel: Also jetzt bei Veat Ecosystems c I ist es hauptsächlich Analyse, zu gucken, liegt das jetzt an Veat oder liegt das an dem Test? Und dann das Fixen übernehmen die Frameworks selber. Ich schicke kaum PRs an andere Frameworks mit der Ausnahme von Svelt, weil ich da selber auch Mainainer bin. Und das passiert zum Glück nicht mehr so häufig, also es ist stabiler geworden als früher. Aber es ist immer noch besser, wir machen die Arbeit einmal, als dass sie dann irgendwie zu zu großen Wellen an jetzt ist alles kaputt führt.
Garrelt: Wieso ist es stabiler geworden?
Dominik Göpel: Weil wir ein bisschen besser geworden sind in der Zusammenarbeit vielleicht, weil auch die die großen Änderungen in in, also die Entwicklungsgeschwindigkeit hat sich 'n bisschen wieder verlangsamt. Mit der Ausnahme der Environment API sind so die großen, passiert, sag ich mal. Aber jetzt mit Rolldown wird wieder was kommen. Aber VIET ist 'n ist 'n bisschen stabiler geworden. Mhm. Was nicht heißt, dass es vorher kaputt war oder so, sondern einfach nur, dass die Entwicklungsgeschwindigkeit 'n bisschen abgenommen hat. Jetzt haben
Jan: wir viel darüber gesprochen, was ihr tut, das für die Frameworks irgendwie möglichst angenehm zu machen. Wir haben über eure interne Architektur gesprochen. Lass uns noch mal darüber sprechen, was es für uns als Entwickler Schrägstrich Endanwender irgendwie einfach macht, ja. Also natürlich ist es schon mal für uns einfach, weil viele Frameworks das einfach out of the box nutzen, so. Und ich muss gar nichts bewusst tun eigentlich irgendwie zu nutzen, ja? Wenn ich irgendwie meinen meinen Remix hier installier, dann ist das irgendwie schon so so mit drin, ob ich ob ich will oder nicht und ich muss mich nicht drum kümmern. Aber Du hast ja auch angesprochen, wie einfach es ist, da irgendwie Plug ins für zu bauen, auch selbst, ja? Manchmal auch ohne eigene Files, einfach nur eine eine kleine Funktion da irgendwie noch rein. Was sind denn so Use Cases, wo ich mir selbst mit Veed das Leben 'n bisschen leichter machen kann, indem ich da eben mein eigenes Plug in, meine eigene Extension für bau?
Dominik Göpel: Ein Beispiel kennt ihr vielleicht auch, wenn ihr Anwendungen baut, die auch für Mobile Devices ausgerichtet sind, muss man sich manchmal mit dem Dev Server auch mit seinem Smartphone verbinden. Und dann bist Du immer dabei und guckst, grad wenn Du irgendwie in 'ner DHCP Umgebung bist, was ist jetzt grad meine IP? Und dann tippst Du mit der 102 neunzehnhundertachtundsechzig 0 1 Doppelpunkt 5 1, bist Du ewig zugange. Und Vloged lockt am Anfang, wenn es hochkommt, immer die localhost IP auf die Konsole. Jetzt wär's ja schön, wenn das mitm Smartphone einfach auszulesen wär und Du könntest es müsstest es nicht abtippen. Da gibt's QR Codes für und son QR Code kann man auch auf die Konsole locken. Und da gibt's auch eine schon, die das macht. Das heißt, vor 'n paar Jahren haben Björn Du und ich einfach uns hingesetzt und haben 'n kleines Plug in gebaut, das nennt sich Veplug in QR Code. Und jetzt kannst Du, wenn Du das in deine Veat Config reinsteckst, jedes Mal, wenn dir der Server hochkommt, den QR Code abscannen und dann klappt das, solange dann hier in jedem selben Netz ist.
Jan: Wie einfach muss ich mir das vorstellen?
Dominik Göpel: Ich glaub, das waren so 20 Zeilen. Also es ist, das ist tatsächlich 'n kleines bisschen tricky, weil man den Punkt rausfinden muss, wann der Server diese URL lockt, damit man genau zum gleichen Zeitpunkt lockt, damit das untereinander steht. Aber ansonsten, die die Hookdokumentation von Rollup ist super und die von Veep ist fast noch 'n Tick besser. Also Dokumentation ist wirklich toll. Sie wird auch auf mehrere Sprachen übersetzt. Ich persönlich les immer alles auf Englisch, deswegen weiß ich jetzt grad gar nicht, ob die Dokumentation in Deutsch immer auf dem aktuellsten Stand ist. Aber ich würd jetzt mal davon ausgehen, dass es da auch ein paar sehr fleißige Menschen gibt, die das regelmäßig aktuell halten. Und das hilft einem wirklich sehr. Und auch wenn man verstehen will, was Lead Plugins machen, gibt es wieder ein Lead Plug in, was da sehr hilfreich ist. Das nennt sich Lead Plug in Inspect. Das ist von Anthony Fu. Und wenn man das in seine Plug in Chain reinpackt und dann auf dem Server underscore underscore underscoreInpect aufruft, dann bekommt man eine Übersicht und kann nachverfolgen, wie jedes einzelne Plug in, jede einzelne Datei transformiert und kann sich auch dann in einem Divviewer die Änderungen anschauen und kann sich den Modul Graph anschauen und alles. Das heißt, Du kannst in die von weit von Viet einfach reinschauen, oh mein Gott. Ich habe zum ersten Mal seit ungefähr 5 Jahren diesen Sprachfehler begangen. Für jeden, der fragt, es wird Viet ausgesprochen, es kommt von dem Französischen, es kommt nicht aus dem Englischen.
Jan: Mhm.
Dominik Göpel: Ja, aber jedenfalls die diese Offenheit von von Wied, dass man eben das Ganze nicht als geschlossenes System betrachtet, wo der Anwender nichts zu suchen hat, die ist ist sehr, sehr hilfreich an der Stelle.
Jan: Ich hatte, also während Du gesprochen hast, das waren jetzt, weiß ich nicht, 'n paar Minuten, hatte ich eine Idee fürn Weed Plug in. Ich hab nämlich so was Ähnliches, was Du mit diesem QR Code gebaut hast, hab ich dir schon in unzählige Projekte bei mir so rein gehackt, nämlich son Tunnel aufzubauen, ne, damit das auch mal 'n Projekt lokal mit Leuten scheren kann, die nicht bei mir im selben Netzwerk sind, sondern einfach son eine Proxy Tunnel dann bekommen über Angrock oder über Talescale, was man da halt so benutzen will, dacht ich mir, boah, das wär ja voll cool, wenn ich das als Plug in bauen würde. So. Ich snippet hab ich schon aus meinen anderen Projekten, ne, kann ich irgendwie da reinholen. Und dann dachte ich, na gut, ich bin wahrscheinlich nicht der Erste, vielleicht gibt's ja schon son Plug in, hab jetzt eben mal Echtzeitrecherche hier betrieben, während Du gesprochen hast. Und es gibt so ein Plug in, was eben genau dieses macht. Wenn dein Server hochgefahren wird, wird 'n NGRAK Tunnel dafür aufgemacht und der die öffentliche Domain wird dann ausgespuckt, so wie dein QR Code Beispiel, ja. Und das Ganze sind 39 Zeilen Code. So. Und also wirklich, ich hab grad diese diesen Plug in Fatix aufgemacht, da ist außer eine und eine Packages ist halt nichts drin, außer diesen 39 Zeilen Code und damit ist dieses ganze Plug in schon gebaut. Also es ist echt banal einfach. Und es sind auch nur 2 Callback Funktionen, die man braucht, das Ganze zu bauen, so wie das das hier für mich aussieht.
Garrelt: Ja. Aber vielleicht noch mal zum Verständnis so, Du hast ja von Hooks gesprochen. Also kann ich mir Plug ins so vorstellen, dass Du, sag ich mal, in dem Bildprozess von einfach 6 verschiedene Stellen hast, wo Du sagen kannst, okay, hier möcht ich jetzt noch Custom Logik hinzufügen? Und dann listest Du einfach deine Plug ins auf und die werden dann nach der Reihe so während diesen Hooks ausgeführt?
Dominik Göpel: So so in etwa. Veat intern ist auch als Roll up Plug ins implementiert. Also wenn man's ganz, ganz pedantisch nimmt, ist Veat eigentlich nur eine abgefahren komplexe Roll up Konfiguration. Und der Vorteil davon ist, dass Du deine eigenen Plugins einmal vor oder auch hinter dem eigenen Plugins in diese Plug in Chain injizieren kannst. Dafür gibt es Konfigurationsoptionen, die Du den Plug in mitgeben kannst. Du kannst sagen oder post. Und dementsprechend wird das vor ausgeführt, was sehr hilfreich sein kann, wenn Du einen eigenen Resolver mitbringst, weil Du dann zuerst dran bist und nicht der Weed Resolver. Oder aber auch Post, wenn Du irgendwelchen Output von Weed haben willst, den noch weiter zu manipulieren. Und das geht auch noch komplexer. Also man kann mit verschiedenen Optionen sehr genau kontrollieren, vor und nach welchen Plug ins dein eigenes Plug in dran ist. Und dementsprechend kann man dann den den Output entsprechend in die gewünschte Richtung lenken.
Garrelt: Mhm. Ist meine Annahme korrekt, dass das sone Handvoll Hooks sind, die wahrscheinlich auch sehr gut dokumentiert sind? Wo ich jetzt, weil wenn ich mich jetzt frage so, okay, ich will 'n Plug in bauen, woher weiß ich denn, wo ich mich reinhocken muss, so?
Dominik Göpel: Genau. Also es gibt auf der Roll up Seite einen einen sehr coolen Graphen, der zeigt, wie die Hooks in welcher Reihenfolge ausgeführt werden. Bei Weep gibt's noch 2, 3 mehr Hooks, die zum einen für das Hotmodell Reloading wichtig sind und zum anderen 1 der eigentlich spektakulärsten Hooks für für Endanwender ist der Config Hook.
Garrelt: Mhm.
Jan: Das
Dominik Göpel: heißt, viele Plugins bringen eigene Konfigurationen mit oder wollen die Konfiguration aktualisieren. Jetzt kann ich wieder aus meinem Nähkästchen plaudern. Wie Plugins Welt generiert eine ziemlich ausführliche Konfiguration, sicherzustellen, dass Weltlibraries richtig optimiert werden und die Anwendung gut funktioniert. Und das alles für den Anwender zu Fuß zu schreiben in seiner eigenen Datei wär viel Arbeit. Und deswegen gibt es diesen Config Hook in Plugins, sodass ein Plug in quasi für dich in deine extra Sachen reinschreiben kann. Mhm. Und das ist sehr hilfreich, wenn Du bestimmte Dinge konfigurieren willst und diese Konfiguration mit anderen teilen willst. Mhm. Du kannst auch die Konfiguration inspizieren. Also es gibt dann auch noch 'n, wo die Konfiguration, nachdem alle Plug ins ihre eigene mitgebracht haben, noch mal ausgespuckt wird, sodass Du dann genau weißt, ist jetzt der Bild Minify Flag gesetzt oder nicht. Und dementsprechend kannst Du in deinem Output Plug in dann sicherstellen, was Du machen möchtest oder nicht. Mhm. Und die für die Transformation wichtigsten Hooks sind Load, wo der Code aus der Datei geladen wird oder auch aus einem virtuellen Modul. Und transform, wo Du dann eben eingegebenen Code hast und ihn transformieren kannst und dann Code wieder.
Garrelt: Krass. Ja, okay, das zeigt ja irgendwie auch schon, dass das so superflexibel ist, wenn Du auch vor den Sachen schon Dinge tun kannst. Also im Prinzip lässt dir das ja alle Möglichkeiten offen. Ja.
Jan: Ja. Okay. Ich hätte noch 2 Punkte, über die ich gerne sprechen wollte. Wenn Gerald nicht noch eine technische Frage zu den Plug ins hat?
Garrelt: Ich weiß nicht, wie spannend es ist. Du hast es anfangs schon mal erwähnt, ob wir reingehen wollen, was virtuelle Module sind. Weil ich glaub, das ist ja son Konzept, was Veed hat, was ich auch eigentlich nur in Veed kennen oder durch Veed kennengelernt hab und das ja auch sehr 'n sehr mächtiges Tool sein kann.
Dominik Göpel: Ja. Da könnt ich als Beispiel wieder Uno CSS anführen. Das ist eine CSS Engine, so ähnlich wie Tailwind CSS, aber ein bisschen modularer und flexibler vielleicht. Mhm. Und in Weed importiert man CSS Dateien auch in ein JavaScript Modul und das wird dann in die Anwendung mit eingebaut. Und UNO CSS importiert man, indem man Import UNO CSS schreibt. Uno CSS ist jetzt aber natürlich keine Datei auf dem Dateisystem. Das heißt, ein normaler Resolver würde diese Datei nicht finden und dann einen Fehler schmeißen und sagen, das kannst Du jetzt nicht importieren. Und wenn Du jetzt aber in deinem Plug in einen Resolve ID Hook hast und diese ID uno CSS siehst, kannst Du sagen, die kenn ich. Und dann returnst Du diese ID. Und das signalisiert der Plug in Chain dann, dass dieses Plug in für diese ID verantwortlich ist und dann wird der Loadhook mit dieser ID aufgerufen. Und dann kannst Du tatsächlich aus dem Loadhook heraus Codes zurückliefern.
Jan: Mhm.
Dominik Göpel: Oder auch nur ein einen Anfang von Code. Und dann im Transformhook noch mehr Code hinzufügen. Das heißt, Du kannst quasi neue Module erschaffen, Mhm. Die es aber nicht physisch, physisch ist 'n blödes Wort, aber die es nicht als Datei im Datesystem gibt. Und diese Module können dann wiederum auf Code basieren, der in anderen Dateien steht. Uno CSS scannt alle Java Script Dateien nach CSS Klassennamen. Und wenn es eine Klassennamen findet, der in deinem Stylesystem Relevanz hat, dann wird der entsprechende CSS Code dafür generiert und mit der Anwendung mit ausgeliefert. Das heißt, jemand, der sich mit auskennt, früher haben die CSS benutzt, ungenutzte Klassen loszuwerden. Bei Uno CSS gab's nie eine ungenutzte Klasse, weil die immer nur genau das hinzugefügt haben, was in deinem Quellcode auch verwendet wurde. Mhm. Und dafür sind solche virtuellen Module eben sehr, sehr hilfreich.
Garrelt: Also vor allen Dingen für Optimierung jeglicher Art.
Dominik Göpel: Der der Kreativität sind da keine Grenzen gesetzt. Du kannst ganze Anwendungen aus virtuellen Modulen erzeugen. So theoretisch Code aus Datenbanken laden. In der KI fragen Code zu generieren. Das geht alles.
Jan: Macht das nicht die IDI von unbrauchbar, wenn dann alle meine Import Statements quasi nicht mehr ordentlich aufgelöst werden können?
Dominik Göpel: Jein. Dieses Import Statement, da kannst Du dann für Uni CAS erste Leute könntest Du 'n Plug in installieren. Das erklärt der IDE dann, dass dieser Import funktioniert. Und die die meisten Language Protokoll Server, die die können mit mit resolvern umgehen. Also das klappt schon.
Garrelt: Okay. Das heißt, das heißt, die Server, die führen dann im Prinzip diesen aus von irgend 'nem Plug in und bekommen dadurch Informationen, was eigentlich hinter dem Import steckt?
Dominik Göpel: Da bin ich jetzt tatsächlich auch 'n bisschen überfragt. Das ist so 1, 2 Schritte von von meiner Expertise entfernt. Aber ja, in in der Regel haben die eine Möglichkeit zu wissen und die populären virtuellen Module haben statische IDs, die sind dann vielleicht auch als Ausnahme einfach hart codiert irgendwo drin. Mhm. Cool.
Jan: Also ich hab mir, also für UNO CSS, genau gibt's die Plug ins, für Viers Code, für Jetbrands und für 'n paar andere so. Mhm. Aber es ist natürlich trotzdem noch mal so eine Dimension mehr, die man dann immer mitbedenken muss. Also natürlich kannst Du supereinfach son Plug in schreiben, was dir das ermöglicht. Aber was es halt für den Endanwender im Alltag bedeutet, muss man halt auch irgendwie dann mitdenken
Dominik Göpel: so, ne. Ja. Also das ist virtuelle Module sind jetzt nicht der erste Schritt der Plug in Entwicklung, aber die sind ein sehr mächtiges Feature, was superviel erlaubt, was wir früher so nicht so einfach konnten.
Jan: Ja. Das auf jeden Fall. Das auf jeden Fall.
Garrelt: Ich frag mich, wie stabil das ist oder wie viel Quatsch man damit anstellen kann oder wie schnell so was auch 'n Projekt zerschießen kann, wenn man jetzt irgendwie das falsche Plug in installiert?
Dominik Göpel: Kann man mit Sicherheit auch. Wenn Du jetzt 'n Plug in installierst, was alle Javascript Dateien irgendwie untersuchst und da eine ineffiziente mit Backtracking drin hast oder so was, dann wird das Bild halt sehr, sehr langsam.
Garrelt: Mhm.
Dominik Göpel: Aber das merkt man in der Regel recht schnell. Und dann hoff ich, dass Du eine saubere Hygiene hast und dann mit 'n bisschen Weißact rausfinden kannst, seit wann es so langsam ist.
Garrelt: Da vermisst Du's ja erst mal Performancetracking haben.
Dominik Göpel: Obwohl Ja,
Jan: aber trotzdem, also zerschießen kannst Du's ja nicht, weil ich mein, am Ende baut halt wieder irgendwas neben deinem Projekt, so. Ja, und also ist jetzt nicht so, als dass dir dein Projekt kaputtmacht. Das kann deinen Output verschlechtern oder unbrauchbarer machen, aber dein dein Projekt bleibt ja unberührt.
Garrelt: Aber es könnte ja schon Code reinkommen, ohne dass ich's merke, der jetzt schlecht für mein Projekt ist, irgendwelcher schädlicher Code oder so. Ich mein, das ist alles Open Source. Man kann das herausfinden, aber als jemand, der vielleicht dann nicht unbedingt reinguckt, ja, könnte da auch Dinge passieren. Weil wenn man sagt, okay, es kann 'n Code aus dem Server geladen werden, Du weißt ja nicht, was auf dem Server steckt so. Und da kommt 'n
Dominik Göpel: muss ja
Jan: nicht mal ausm Server geladen werden. Kann ja einfach als Teil von dem Bildprozess schon passieren. So, ja? Wenn Du halt irgendwie, stell dir sone Supply Chain Attacke halt vor, Du hast halt irgendwie son bösartiges Plug in installiert und der holt dann aus seinem Git Repository oder aus irgend 'nem s 3 Bucket halt, weiß ich nicht, jubelt er dir 'n 'n 'n Miner unter oder so in dein fertig gebautes Bundle und dann ist halt so. Oder das ist ja kein eigenes Problem. So, das ist halt 'n Bundler Problem. Ja. Du musst halt deinem Bundler vertrauen, dass der Output, den er schreibt, halt schon auch das ist, was Du haben willst. Ja, das stimmt.
Dominik Göpel: Das das ist richtig. Es gibt tatsächlich aber auch durch den Dev Server, weil der ja bei dir lokal läuft, Probleme manchmal. Wir hatten schon 1, 2 Security Advisoryys, die gegen den Dev Server liefen. Und bei dem letzten war's zum Beispiel so, dass über ein Websocket man technisch in der Lage war, wenn Du jetzt auf eine böse Seite Punkt d e gegangen bist, konnte die über Localhosts 5 1 7 3, also den standardmäßigen, die Standard URL von dem Web Dev Server testen, ob bei dir lokal in 'nem anderen Tab grad der Dev Server läuft und dem dann Crafted requests schicken, deinen ganzen Source Code runterzuladen. Was besonders bei internen Projekten, die nicht auf GitHub Open Source sind, 'n bisschen unschön sein kann. Mhm. Wir haben diese Lücke gefixt und das Ganze auch entsprechend kommuniziert. Aber ja, ein Dev Server hat eine große Verantwortung und ein Bundler hat viel Macht, solche Supply Chain Attacken, ja. Und wenn Du jetzt irgend einen Plug in installierst und dann eine neue Version runterziehst, ohne zu gucken, was die vielleicht macht, dann kann's dir tatsächlich passieren, dass jede Code in deiner Anwendung injiziert und dann deine Webseite, wenn Du's deployst, damit angreifbar macht.
Garrelt: Mhm. Das Da
Jan: kann ich noch was dazuwerfen. Es gab mal eine Zeit, wo das so gängige Praxis war, auf den großen Konferenzen dieser Welt rumzusitzen und einfach das WLAN mal abzugrasen nach Leuten, die halt ihre Devserver public haben, ne. Wie eben schon gesagt, das sind halt gängige Ports. Von daher hier noch mal der Hinweis, auf Konferenzen sollte man kein Devanvironment am Laufen haben, ja. Weil also Quelljex ist das eine, ja? Aber manche Leute haben ja auch so was wie Datenbankdumps aus ihrem Protzystem irgendwie mal lokal so in Verwendung, was zu debuggen oder bla und zack, ist dein ganzer Datenbankdump da schon abhandengekommen. Mhm. Das hab ich auch schon mitgekriegt. Das sollte man vermeiden.
Dominik Göpel: Ja. Ja, IT Sicherheit ist ist sehr wichtig. Seid da bitte vorsichtig. Aktualisiert Pakete, aber schaut euch die Change Logs an und im Zweifelsfall schaut auch tatsächlich mal in die Indigit Historie rein und installiert nicht irgendwie Veat Plugins, nur weil sie 'n cooles Logo animieren, sondern installiert sie, weil sie gebraucht werden.
Jan: Ja. Penency Management. Da könnt man eine eigene Folge drüber machen, glaub ich.
Dominik Göpel: Ja. Voll.
Jan: Gut. Die andere Frage, auf die ich noch rauswollte, ist so, wer macht denn dieses Veed eigentlich? Weil grade, ne, wenn Du sagst, das ist halt schon in so vielen Frameworks integriert und an so vielen Stellen wird es wahrscheinlich auch von so vielen Leuten benutzt, die es gar nicht so bewusst wahrnehmen als das, was es ist. Aber es ist ja schon son essentieller Bestandteil von ganz viele Leute Arbeit eigentlich. Und ich frag mich da immer bei Open Source generell so, auf auf was für Schuld entsteht das halt eigentlich und wie belastbar sind die so über kurz oder lang? Weil ja die allermeisten Open Source Projekte eben keine solide Finanzierung hinten dran haben, sondern eigentlich auf Goodwill und freiwillige Arbeit aufbauen. Wie sieht das bei euch im Team so aus?
Dominik Göpel: Also das ist 'n Mix. Wir sind einmal sind wir ein ein global verteiltes Team aus zwischen 8 und 10 Leuten im Moment, würde ich sagen, die mehr oder minder aktiv daran entwickeln, die auch unterschiedliche Schwerpunkte haben. Das ist der nächste geheime Erfolgsfaktor von Lead. Dieses Team ist letzten Endes gewachsen, weil Matthias Kapaletto oder Patak sehr gut darin ist, zu kommunizieren und uns alle son bisschen an die Hand zu nehmen und dass wir einfach gut zusammenarbeiten. Also ohne ihnen wird's VID heute so nicht geben. Ohne viele andere auch nicht. Ohne superviele Dependencies, die groß gemacht haben. Roll-up und IS Bild sind nur die die populärsten, aber das geht wirklich runter bis zu kleinen Plug ins und. Ist ein Riesensystem, was auf ganz vielen kleinen Open Source Projekten fußt und ohne die es nicht möglich wär. Das heißt, letzten Endes ist es die die Kombination von einem riesigen Open Source Effort, den wir alle zusammen schaffen. Veed bekommt Spenden und die werden teilweise auch an die Maintainer verteilt. Ich persönlich profitier da jetzt nicht von. Das heißt, ich spende meine Arbeitszeit dort. Ich hab 20 Jahre lang bei der Entwicklung gut von Open Source profitiert und geborene jetzt 'n bisschen was zurück. Es hilft mir natürlich auch bei der Projektsuche ab und zu, weil ich dadurch 'n bisschen öffentlichkeitswirksamer, präsent bin, zu Podcasts eingeladen werde und manchmal auf Konferenzen auch Talks gebe. Und aber es ist schon so, wenn man's vergleicht mit dem Nutzen, den erzeugt, sind die Einnahmen, die durch die Spenden reinkommen, viel, viel, viel zu klein und eigentlich bräuchten wir 'n bisschen mehr. Weed wird im Moment 22000000 Mal jede Woche runtergeladen und noch viel, viel häufiger ausgeführt. Spotify zahlt, glaub ich, pro 1000 Downloads einen Cent oder so. Könnten wir das auch für Weed haben, wär toll.
Jan: Mhm.
Dominik Göpel: Ja, aber ich will ich will mich nicht beschweren. Es ist hauptsächlich eine sehr gute Zusammenarbeit zwischen vielen Menschen unterschiedlicher Disziplinen und Alters. Also ich bin jetzt, glaub ich, sogar schon 1 der Älteren oder Ältesten dort. Aber wir haben halt auch, Björn zum Beispiel ist grad Anfang 20 und könnte tatsächlich mein Sohn sein. Aber wir arbeiten halt einfach nur super zusammen und das macht sehr viel Spaß. Und es ist einfach nur toll zu sehen, wie vielen Leuten man damit helfen kann. Und ich nutz es auch immer wieder selber gerne in meiner meiner Arbeit dann.
Garrelt: Und macht ihr das alles asynchron oder setzt ihr euch auch manchmal zusammen?
Dominik Göpel: Wir haben tatsächlich alle 2 Wochen 'n Call. Der findet 9 Uhr morgens statt, was für mich ganz gut ist. Für die Leute aus Asien geht's auch noch.
Jan: Mhm.
Dominik Göpel: Und das passt dann so. Wir haben letztes Jahr ein kleines Offside gemacht, wo wir uns eine Woche lang in Kroatien in eine kleine Hütte zurückgezogen haben. Da hätten wir besser vorher nach dem WLAN geguckt. Das war 'n bisschen schrägy, aber wir haben eine Woche lang ziemlich gut an der Environment API zusammengearbeitet. Und ja, wir wir wachsen auch als als Menschen einfach zusammen. Also wir machen das jetzt nicht nur, Codes zu machen, sondern wir sind auch gute Freunde geworden. Und man sieht sich auch auf Konferenzen immer mal wieder dann. Jetzt im im Mai ist in Barcelona das Welt Summit, da freu ich mich schon drauf.
Garrelt: Ja, der Krisja fährt auch und hat schon versucht, uns zu mobilisieren. Aber der Gabriel
Jan: ist auf der Enter JS und kann leider nicht.
Dominik Göpel: Mhm. Tja, das ist, ja, die die Enter JS, da war ich letztes Jahr auch, aber dieses Jahr überschneiden sich die Termine. Mhm. Und da muss ich als Salt Mainainer dann leider
Jan: Ja, bei der Donau Barcelona Entscheidung.
Garrelt: Warst Du nur noch Mannheim ist auch irgendwie, glaub glaub ich, eine leichte Entscheidung.
Jan: Ja, für also für Mannheim, für dich auf jeden Fall, oder, Gareth?
Garrelt: Safe. Echt, das war klar jetzt.
Jan: Wir werden alle in Mannheim sein außer Dominik, der wird in Barcelona sein mit Krischer.
Dominik Göpel: Ja. Und Simon und Rich Harris und Patak und noch 'n paar anderen und so.
Jan: Vielleicht schaffen wir's ja nächstes Jahr, das andersrum zu machen.
Dominik Göpel: Ja.
Jan: Ja. Cool, cool. Mhm. Dann waren das, glaub ich, alle meine Fragen, die ich so auf der Liste hatte. Garet, hast Du noch was?
Garrelt: Nee, ich fand's cool, dass wir jetzt noch mal über die Organisation, also wie ihr so zusammenarbeitet gesprochen habt habt. Das find ich nämlich auch immer sehr spannend. Und Viet ist ja auch son Riesenprojekt. Das ja, ist nicht ganz einfach zu stemmen. Aber ja, so Leute, die dann kommunizieren, gut kommunizieren, sind echt wichtig auch.
Dominik Göpel: Ja, das auf jeden Fall. Es ist auch relativ einfach, Contributer zu sein in Wied. Also wir haben eine sehr aktive Community. Das ist auch das, ich hab eben die Downloadzahl genannt, weil's immer das ist, was die Leute am meisten irgendwie interessiert. Aber das, was eigentlich der der Hammer an Beat ist, ist, dass wir über 1000 Contributer auf GitHub haben, die in Beat Core committet haben. Das ist innerhalb von 4 Jahren sind das jetzt mehr als bei Webpack in 8 Jahren zusammengekommen sind. Ja.
Jan: Das ist fast 1 jeden Tag, wenn man jetzt nur so Werktagen erzählt, ne. Ist schon krass.
Dominik Göpel: Ja, ja. Und das ist auch nur der Call. Wenn man dann die nahen Projekte nimmt, ist es noch viel mehr. Und wenn man jetzt sagt, das klingt jetzt aber superkomplex und schwierig und ich trau mich da nicht zu contributen, das kostet mich zu viel Zeit und alles. Es gibt wirklich auch kleinere Plugins und Dinge, die für eure Projekte wichtig sind. Und wenn ihr da Antrieb habt, schaut euch einfach und sucht euch 1 raus. Ich hab noch kein Open Source Projekt erlebt, was gesagt hat, Contribueter wollen wir nicht.
Jan: Mhm. Das ist doch ein schönes Schlusswort. Na gut. Ich hab Oder, Garet, wenn wenn Du noch was was Gutes hast.
Garrelt: Ja, ich mein, ich hab schon noch eine Frage. Ich weiß halt nicht so genau, wie gut Du die beantworten kannst, Dominik. Aber Du hast eben den Matthias Capilletto erwähnt, dass es so unfassbar wichtig ist, wie dass er da ist. Und ich frag mich halt, was macht er denn so gut? Also was was sind so seine Eigenschaften oder die Dinge, die er macht, die das Ganze so zusammenhalten und vorantreiben?
Dominik Göpel: Das ist tatsächlich schwer in in Worte zu fassen. Man muss es einfach erleben. Aber er er ist einfach ein ein unfassbar guter Kommunikator. Er er bringt die Frameworks zusammen und er findet auch dann die Leute, die miteinander reden sollten, ein Problem zu lösen. Mhm. Und wenn Du nicht aufpasst bist, Du Weed Contributer, bevor Du fertig bist, mit ihm zu sprechen. Es ist einfach ein ein ein unglaublich feiner Mensch und hat gleichzeitig auch 'n sehr tiefes technisches Verständnis. Da können wir vielleicht kurz noch mal wieder zurückkommen zu dem, wie finanziert sich Wied? Matthias ist bei Stackblitz angestellt. Mhm. Und Stackblitz bezahlt ihn quasi Vollzeit dafür, für Wied da zu sein. Und das ist natürlich auch sehr cool. Stackblitz als Firma profitiert natürlich auch wiederum von Beat. Also Sie machen das nicht nur aus Eigennutz, aus
Jan: Aus Selbstlosigkeit.
Dominik Göpel: Aus Selbstlosigkeit. Aber es ist natürlich trotzdem ein ein sehr großes Investment und da sind wir auch sehr dankbar. Und das ist etwas, was eine gegenseitig nützliche Beziehung ist. Wenn wir Issue Reports bekommen, wo eine Stack Blitz Reproduction dran ist, hilft uns das sehr viel schneller zu verstehen. Und dementsprechend schafft es Matthias dann auch immer wieder, Leute zu motivieren und das ist sehr gut so. Cool, cool.
Jan: Vielleicht wie immer die letzte Frage an dich, Dominik. Was war eine Frage, die wir dir nicht gestellt haben? Worüber wolltest Du unbedingt noch reden und denkst jetzt so, wieso hat mich keiner danach gefragt?
Dominik Göpel: Was ich vielleicht noch 'n bisschen ausführen wollen würde, ist, wie wichtig wie Test ist für für Feed und für euch alle da draußen. Testing kann gar nicht hoch genug gewichtet werden. Alles, was man vor der Produktion abfängt, ist gespartes Geld am Ende. Das heißt, jeder Euro, den ihr in Testing investiert, der zahlt sich aus.
Jan: Ich
Dominik Göpel: weiß, es ist manchmal schwierig, weil er sich in den Büchern nicht sofort wiederfindet. Aber V-Test macht es supereinfach, Tests eurem V-Projekt hinzuzufügen. Ihr müsst keine Extrakonfiguration schreiben und shamedless Plug an der Stelle. Mein Talk offen Svelt Summit wird über Svelt testen mit V-Test sein. Und V-Test wird auch mittlerweile von anderen Projekten noch genutzt. Das heißt, Storybook zum Beispiel hat einen einen Testing Mode, der auch auf V-Test basiert. Das heißt, ihr könnt eure Storybook Stories nehmen und die einfach in Tests verwandeln und dann schlagt ihr 2 Fliegen mit 1 Klappe und das funktioniert, weil Viet und Vietsts so gut zusammenarbeiten. Also testet euren Code und nehmt wie die und wie Test dafür. Dankt mich später. Mhm.
Jan: Sehr guter Hinweis. Da könnten wir auch ja ganz eigene Folge, glaub ich, drüber machen über Testing und Testingstrategien und was ist wann wo wie wichtig und so. Aber die Care Message bleibt, Hauptsache ihr testet irgendwie, so. Alles andere ist zweitrangig. Cool, cool. Dann bleiben uns nur noch einmal über die zu sprechen.
Garrelt: So. Und
Jan: bevor wir zu den Picks kommen, die heute alle fleißig ins Gepäck gepackt haben, haben wir noch einen ganz besonderen Hinweis beziehungsweise der Dominik hat den mitgebracht für euch. Dominik, was warst Du dabei?
Dominik Göpel: Ja, ihr habt ja jetzt son bisschen gehört, was Viet aktuell macht und was in Zukunft so ansteht. Aber wenn euch interessiert, wie wir entstanden sind und was so die Geschichte hinter Viet ist und die Menschen, die daran arbeiten, dann wird's bald eine Dokumentation dazu geben. Grad ganz aktuell läuft dazu 'n Trailer, den könnt ihr euch auf Youtube anschauen. In den Notes ist 'n Link. Und ich würd mich freuen, wenn's viele tun. Die Leute, die das machen, sind echt super.
Jan: Genau. Die Leute, die das machen, sind die Leute von Culture Repo. Das sagt jetzt wahrscheinlich dem einen oder anderen hier noch genau nichts, weil ich glaube, Culture Repo hat seit seinem Rebranding noch nicht groß von sich hören lassen. Culture Repo war aber früher Honeypot und sind die Macher hinter den Dokumentationen von Angular, No JS, Dino, Ruby, alles Dokumentationen, Filme, Kunstwerke, über die wir hier schon in der programmier.bar gesprochen haben, vollkommen zurecht. Aber ich glaub, Honeyport hatte ganz früher am Anfang mal so den den Titel oder den Slogan Netflix for Developers. Das fand ich immer superpassend. Da kann man nämlich stundenlang Content sich sich reinziehen. Und ich hab keinen Zweifel, dass die VIT Doku genauso interessant und lehrreich und Einblicke mitgeben wird wie die ganzen anderen Filme auch.
Dominik Göpel: Auf jeden Fall.
Jan: Cool. Danke, dass Du das exklusiv für uns hier im Gepäck hast.
Dominik Göpel: Freut mich. Und jetzt lass uns die Picks hören.
Jan: So. Und normalerweise würde ich Dominik anfangen lassen als unser Gast, aber Gareth kam eben so breit durch die Tür hier rein und meinte, der hat einen megageilen Pick für heute im Gepäck, dass Garnit anfangen muss.
Garrelt: Ja. Ich mein, für mich ist er megageil. Ich bin gespannt, was ihr dazu sagt. Du hast jetzt schon gleich wieder tiefer gestapelt. Ja, dann schneiden wir das raus. Kennt ihr das Buch Clean Code? Ja. Kennt ihr auch das Buch Philosophie of Softwaredesign?
Jan: Vielleicht. Ich googel's und guck
Garrelt: mir das Cover an. Okay, auf jeden Fall die, das sind beides Bücher, über wie man 'n Code schreiben soll, also eine Hilfe, besseren Code zu schreiben. Und die haben teilweise sehr, sehr unterschiedliche Ansichten, was bestimmte Prinzipien angeht. Und diese beiden Leute, Cleancode wurde Robert Martin, dem Onkel Bob geschrieben. Der ist sehr bekannt und Philosophie auf Softwaredesign von einem, ich glaub, Professor von Stanford, der John Osterhood. Und es ist sehr spannend, weil sie sich teilweise auch in den Büchern, zumindest John aus sood, referenziert Uncle Bob. Und was ich heute gefunden hab, ist eine ein Zusammenschnitt von 'ner Konversation, die sie gehalten haben über diese Punkte. Das ist im Prinzip 'n GitHub Repository, wo einfach diese Konversation aufgelistet ist. Und sie diskutieren da diese Kritikpunkte, die sie gegenseitig haben. Und es liest sich son bisschen wie, als wär das AI generated, aber das ist auf der GitHub, auf dem GitHubprofil von John Osterhoot gehostet, deswegen scheint es echt zu sein. Und ich find's einfach supercool, dass sie da in den Austausch gehen und das einfach ja, so beleuchten und man da noch 'n besseres Verständnis von diesen beiden Seiten bekommt. Und ich find, das ist einfach Gold wert, weil diese Bücher sind schon gut, aber sone Diskussion darüber, ja, da kann man noch mal richtig in die Tiefe gehen.
Jan: Nice. Nice. Okay. Wir hatten das begeistert.
Dominik Göpel: Nein, nein, nein, nein.
Jan: Also ich ich muss sagen, erst mal nicht das, womit ich gerechnet habe, aber ich glaube, es ist viel wertvoller als alles, was ich mir hätte vorstellen können. Na, okay.
Garrelt: Dann ist gut.
Dominik Göpel: Ich muss zu meiner Schande gestehen, ich lese keine Bücher über Softwareentwicklung mehr. Das hab ich eine lange Zeit getan, aber im Moment lese ich so viel Quellcode und andere technische Dinge, dass ich froh bin, wenn ich dann am Ende auch abschalten kann. Und da fehlt mir im Moment son bisschen die Zeit. Aber vielleicht schau ich die mir ja mal an. Und sone textbasierte Zusammenfassung und Diskussion find ich an der Stelle immer toll.
Garrelt: Mhm.
Dominik Göpel: Das ist was, was ich nicht so mag. Ich find diesen ganzen videobasierten Content, den man immer zuhören muss und dann auf 1 Komma fünffacher Geschwindigkeit stellt, weil sonst was ist nicht so toll. Ich bin ein sehr textbasierter Mensch und ich mag Dinge mit Steuerung f suchen und finden und
Jan: Ist denn für so Leute wie Dominik haben wir die Volltext Transkripte auf die Webseite gebaut? Du musst den Podcast nicht hören, Dominik kannst Du ja einfach lesen.
Dominik Göpel: Danke dafür. Da musst Du dir nächstes Mal eine eigene Stimme nicht mehr hören. Das ist
Jan: tatsächlich schon 'n super unangenehmes Ding. Ich fand das auch, als ich angefangen hatte, so Talks zu machen und und Videos und so. Wenn man sich das erste Mal selber hört und sieht, das ist ultragrausam. Also mir tut die Hörerinnen auch eigentlich jede Woche leid, die mich dann so hören müssen.
Garrelt: Okay. Musst Du nicht.
Jan: Dominik, was hast Du dabei?
Dominik Göpel: Ja, ich hab Storybook dabei aus 'nem relativ einfachen Grund, weil sie etwas geschafft haben, was sehr wenige Projekte wirklich schaffen. Und zwar haben sie erkannt, dass sie selber sehr viel Komplexität mit sich rumtragen und haben quasi eine 180 Grad Kehrtwende gemacht. Und wenn Du mich vor 3 Jahren gefragt hättest, wo steht Storybook heute, hätt ich gesagt, irgendein basiertes Framework hat sie abgelöst. Und die Leute verwenden jetzt Feed Stories oder wie auch immer das gießen hätte, so ähnlich wie wie TestJest langsam den Rang abläuft. In der Tat ist es aber so, dass dieses Framework Storybook heißt. Storybook hat unter der Haube es selber geschafft, die Anzahl ihrer Dependencies drastisch zu reduzieren, auf umzubauen und liefert jetzt coole neue Features wie das, was ich eben erwähnt hab mit dem Testing über Stories. Im Bereich Welt bieten sie tatsächlich die Möglichkeit, in nativem Weltformat Stories zu schreiben. Was früher mal funktioniert hat, aber dann in Storybook 7 oder 8 irgendwann nicht mehr. Da musste man dann son natives Format von Storybook benutzen, was in type Skript Dateien war und das war für S Weltentwickler furchtbar. Aber jetzt geht das wieder mit richtigem Säldent Code und also die haben tatsächlich auf ihre Community gehört. Und obwohl sie so ein großes, fast monströses Projekt sind, haben sie sehr viel Refacturing und sehr viel Verschlankung hinbekommen. Und da da zieh ich meinen Hut.
Jan: Ich glaube, wir müssen einmal für alle da draußen erklären, so a, was Storybook ist für die Leute, die's nicht kennen und was Du meinst, wenn Du über Storys redest. Weil die meisten Leute denken wahrscheinlich eher so an die User Stories, die sie so in ihrer Produktsession irgendwie machen und dass er nicht ganz das, was Storybook und deine Story versteht.
Dominik Göpel: Ja, eine Story ist letzten Endes eine eine Preview von 1 Komponente oder ein Modul deiner Webanwendung, die Du zur Entwicklungszeit benutzen kannst, sie zu demonstrieren oder auch auf 1 Preview Umgebung deployen kannst, damit ein Designer schauen kann, ob das alles so aussieht. Du kannst unterschiedliche Farbpaletten ausprobieren, Buttons in unterschiedlichsten Zuständen, Größen und Formen und Du kannst Interaktionen damit zusammenstellen. Es ist in vielen größeren Projekten gehört das zum zum Standard mit dazu, so ähnlich wie's auch mit Testsuiten ist, dass man eben ein ein Storybook hat, was das Designsystem und die einzelnen Komponenten vorstellt.
Jan: Wunderbar. Cooler Pick. 'N cooler Pick auf jeden Fall. Ich glaube, viel zu wenig Leute nutzen so was. Also angefangen bei viel zu wenig Leute nutzen überhaupt Designsysteme, egal in welcher Form und noch viel weniger nutzen so interaktive Designsysteme, deshalb Power to Storybook an der Stelle. Ja, ich hab einen weniger sinnvollen Pick mit dabei, nachdem ihr alle schon so was Praktisches und Nutzbares irgendwie dabeihat, hab ich mir gedacht, ich mach was Lustiges heute. Und zwar hab ich mit dabei. Und zwar ist das eine kleine Webseite mit der einfachen URL, Und wenn man die aufmacht, macht sie jetzt nicht auf, wir machen das gleich zusammen hier. Ja. Wenn man die aufmacht, kriegt man ein paar Fragen gefragt aus 1 Kategorie und man muss einfach entscheiden, ist das ein echtes oder ist das ein Fake? Und jeden Tag gibt es quasi eine neue Kategorie. Ich drück jetzt hier mal live auf Play und wir machen das zusammen. So, die Kategorie des Tages heißt Stanley Cup Gewinner. So Stanley Cup, ne, amerikanische Eishockey, wie sagt man, Trophäe hier Meister. So und jetzt gibt es eine Liste an Teamenamen und man muss sagen, so ist es ein echtes Team? Haben die schon mal einen Standlay Cup gewonnen oder sind die fake autogeneriert, ausgedacht, wie auch immer? So, ich les jetzt 'n paar Namen vor und ihr sagt jetzt Fake oder oder real oder oder echt oder so. So, erster Name, Seattle c monsters.
Dominik Göpel: Reel. Fake.
Jan: So, jetzt weiß ich natürlich nicht, was ich drücken muss. Ich drück jetzt mal auf Fake und Fake ist richtig. Zweiter Name, Vegas Golden Knights.
Dominik Göpel: Reel.
Jan: Real. Real? Real ist richtig. So. Und so geht das jetzt quasi, ich glaub, es sind immer 10 oder so pro Tag, wo man sich durchklicken muss. Und man lernt halt einfach auch son bisschen. Was sind immer so Kategorien, das hat halt angefangen mit echten Tieren oder also, ne, ne, echter Vogel oder kein echter Vogel Name, aber ist halt jeden Tag was anderes. Und das sind so immer so ultra krass nischige Sachen auch irgendwie, die das dann ganz lustig machen. So. Das wäre eigentlich mein Pick gewesen, wenn ich vorhin nicht beim googeln danach, weil ich die URL vergessen hatte, auf was ganz anderes noch gekommen bin. Und Du verschimmelt. Du musst Ja, ja, ja. Das andere können wir jetzt aber nicht zusammen spielen, aber ich ermutige alle da draußen, das mal zu spielen. Das ist nämlich ähnliches Prinzip. Man kriegt wieder etwas vorgelegt und man muss entscheiden, a oder b. Und zwar heißt das Ganze oder Serial Killer. Und ihr kriegt ein Schwarz Weiß Foto von 1 Person vorgelegt und ihr müsst entscheiden, hat dieser Mensch eine Programmiersprache erfunden oder ist er ein Serienmörder? Und das sind einfach, also Leute, diese Fotos, das ist in 'nem Podcast nicht zu beschreiben, ja? Ich hab schon so krass daneben gelegen, wo ich dachte, der sieht aus, als hätte er irgendwie, weiß ich nicht, Delphi erfunden. Aber nein, er hat halt in den Siebzigern in Ost England irgendwie reihenweise Leute abgeschlachtet, so, ja? Also der der der Grad zwischen Genie und Wahnsinn liegt nahe beieinander irgendwie in unserer Branche und das ist 'n sehr lustiges Quiz dazu. Verlinken wir beides. So.
Dominik Göpel: Das ist
Garrelt: schön Desaster.
Jan: Das war mein Pick. Ja. Aber wie gesagt, Realbird oder Fakebird ist bei mir jetzt Teil von meinem Set an Seiten, die jeden Tag aufgeht, wenn irgendwie mein mein Browser neu startet und dann kann man sich einmal kurz da durchklicken. Das ist super, super lustig.
Dominik Göpel: Ja, sowas macht immer dann mal kurz irgendwie eine Kurzweile und Freude und
Jan: ich ich Ja, also Du bist auch in 30 Sekunden so durch, weißt Du? Und dann dann kannst Du's auch wegschmeißen, weil es gibt halt nur eine Kategorie am Tag. Du kannst es nicht länger spielen als eine Kategorie und Du kannst auch nicht die alten von gestern spielen. Das ist einfach nur einmal aufgemacht, durchgeklickt, fertig. Erzähl ich. Wunderbar. Dann Dominik, danke für deine Zeit. Danke, dass Du uns Viet ausführlich erklärt hast. Danke, dass Du an Viet mitarbeitest und wir alle davon profitieren können, insbesondere Garrit, auch wenn er manchmal 10 Sekunden warten muss. Danke, Garrit für die Zeit. Danke, dass Du im Studio warst, auch wenn Du alleine im im echten Studio warst und alle virtuell hier zugeschaltet waren. Und wie immer danke an alle Hörerinnen da draußen. Wenn ihr Fragen, Anregungen, Kritik, Feedback, Sonstiges habt, dann immer gerne an Podcast at Programmier Punkt bar oder als Kommentar bei Youtube, Spotify, LinkedIn, Instagram, Masterdown und Bluesguay. Ich glaub, das waren sie alle. Irgendeinen vergess ich immer. Wir lesen alles fleißig mit. Wir freuen uns immer über Nachrichten und wenn ihr uns nicht schreibt, hören wir uns spätestens nächste Woche wieder. Dann war's es für heute und tschau, bis bald. Vielen Dank.
Dominik Göpel: Dankeschön.

Vite mit Dominik Göpel

Shownotes

Picks of the Day

Programming Language Inventor or Serial Killer?

Real Bird Fake Bird

Robert „Uncle Bob“ Martin vs. John Ousterhout

Vitest

Speaker Info

Dominik Göpel