Deep Dive 184 – Rolldown mit Alexander Lichter

In dieser Folge sprechen wir mit Alexander Lichter über neue Tools, die in der Community gerade für Aufsehen sorgen: Rolldown ist ein neuer Bundler auf Rust-Basis, der Rollup und esbuild langfristig ablösen könnte. Alex arbeitet seit Jahren mit JavaScript-Tooling und ist früh zum Rolldown-Team gestoßen. Er erzählt uns, warum er sich dem Projekt angeschlossen hat, wie es zur rasanten Entwicklung kam – und was es mit der engen Verbindung zu Vite auf sich hat.

Außerdem geht es um void(0), ein ambitioniertes Developer-Tooling-Projekt, bei dem Alexander für Developer Relations verantwortlich ist. Wir sprechen über große Visionen, Funding-Strategien für Open Source und die Herausforderungen, Community und Professionalität in Einklang zu bringen.

Nicht zuletzt schauen wir auf oxc, ein auf Geschwindigkeit optimierter Compiler, der tief in die Architektur von Rolldown hinein wirkt. Eine Folge für alle, die sich für moderne Toolchains, Open-Source-Engagement und die Zukunft des Frontend-Ökosystems interessieren.

Schreibt uns!
Schickt uns eure Themenwünsche und euer Feedback: podcast@programmier.bar

Folgt uns!
Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen.

Bluesky
Instagram
LinkedIn
Meetup
YouTube

Musik: Hanimo

Transcript

SPEAKER_03: 0:00

Hallo

SPEAKER_01: 0:09

und herzlich willkommen zu einem neuen Deep Dive bei der Programmierbar. Ich bin hier im hybriden Studio und habe zwei Leute mit mir hier sitzen, auf die ich mich beide sehr freue. Und zwar nämlich einmal sitzt endlich mal wieder der Sebi neben mir. Hi Gareth, ich freue mich auch. Hallo Sebi. Ja, ist ein cooles Thema auch heute. Und für dieses Thema haben wir uns den Alexander Lichter eingeladen. Hallo Alex. Hallo Sebi, hallo Garel. Schön, dass ich wieder dabei sein kann zum dritten Mal jetzt, ne? Die dritte Episode. Richtig, die dritte Episode. Die letzten zwei waren über Naxt. Heute geht's nicht um Naxx, sondern um was anderes. Nicht hauptsächlich zumindest, ne? So ein bisschen reingesneakt wird es

SPEAKER_02: 0:46

vielleicht

SPEAKER_01: 0:46

hier und da. Aber genau, richtig. Das stimmt. Das ist ja auch alles ein bisschen miteinander verbunden. So ist es. Genau. Du warst schon zweimal da. Viele kennen dich bestimmt, aber für die Leute, die dich nicht kennen, stelle ich dich noch einmal ganz kurz vor. Alex ist eine bekannte Stimme und Gesicht in der Web- und vor allen Dingen der View-Welt. Und das liegt unter anderem daran, dass er als Commentainer schon viel bei Naxx beigetragen hat, aber auch gerne generell viel zu Open-Source-Software contribute, unter anderem eben auch Vue. Aber du bist auch Host von DejaVu, ein Podcast, der sich um alle möglichen Vue-Themen dreht. Und auch auf vielen Konferenzen weltweit sprichst du über Nuxt, über Webthemen, über Vue. Da sieht man dich auch häufiger. Und seit kurzem bist du auch als Developer Relations bei Void Zero aktiv. Da bin ich auch sehr gespannt, was du heute erzählst. Und neben diesen ganzen Dingen, die ich jetzt schon genannt habe, bist du auch noch irgendwie Consultant und machst Workshops. Wie

SPEAKER_02: 1:48

viel Zeit hast du dafür überhaupt noch? Ja, genau. Es klingt also recht viel, ist doch alles absolut richtig. Natürlich, seitdem ich bei Void Zero bin, also jetzt ungefähr so zweieinhalb, wahrscheinlich mit der Episode rauskommt, so drei Monate. Weniger Zeit für Consultancy auf jeden Fall, weniger Zeit für Beratung. Dadurch, dass, wie du schon gesagt hast, so okay, viel Zeit geht natürlich für meinen Teilzeit-Default-Job bei Void Zero, sind drei Tage die Woche drauf. Und die anderen zwei Tage ist dann, ja, Open Source will man trotzdem noch contributen. Man ist mal auf Konferenzen, wobei es zum Teil natürlich auch Arbeitszeit ist. YouTube-Channel habe auch noch, wo ich jede Woche ein Video über Vue Nux und auch Webthemen mitrelease. Genau, der Podcast. Ja, da bleibt dann nicht mehr so viel Zeit, aber es geht noch alles. Es passt noch. Auch Gott sei Dank, weil ich meine Videos nicht selber editieren muss, genauso mit dem Podcast. Das ist ganz hilfreich, wenn man jemanden hat, der es einem abnimmt und man dann Zeit hat, weiter Content zu katen oder zu contributen oder, oder, oder. Macht

SPEAKER_01: 2:37

das dein Co-Host, der Michael Thiessen? Nee,

SPEAKER_02: 2:39

tatsächlich nicht. Wir haben einen dedicated Editor, genau, Niki macht das für uns und macht es aber auch gleich alles in der Hand, sowohl mein YouTube-Channel als auch die Podcasts, also auch ein bisschen was für Void Zero. Mhm. Da haben wir jemanden, der mit dem technischen Verständnis ganz gut dabei ist und ist sonst so ein bisschen als Editor. Jeder kann ja theoretisch Podcasts so über Allgemeines editieren, aber manchmal ist dann ganz gut, okay, man versteht zumindest den Zusammenhang im Gespräch oder bei einem Tutorial so, ja, okay, wo muss ich jetzt reinzoomen, wo ist der Fokus? Da haben wir auf jeden Fall jemanden guten mit am

SPEAKER_01: 3:09

Start. Ja, sehr wertvoll. Bei uns ist das der Carlo, auch Shoutout an

SPEAKER_02: 3:14

Carlo. Grüße gehen raus,

SPEAKER_01: 3:15

genau. Die Leute machen viel und hören viel und sind aber sehr im Hintergrund.

SPEAKER_02: 3:19

Das ist so die, ich sag mal, der undankbarste Job, so eine harte Weise. Wenn alles klappt, ist so, ja, alles cool. Und wenn was nicht klappt, ist so, ah, ja, hätte man ja besser machen können. Das ist so ein bisschen wie der MC auf Konferenzen, ist halt ähnlich. Ja, fühle ich auf jeden Fall. Großen Shoutout an alle Leute, die hinter den Podcasts und Channels und Co. sitzen und das Ganze editieren und produzieren. Absolut.

SPEAKER_01: 3:39

Ja, wir haben jetzt schon viele irgendwie Buzzwords gehört mit Nuxt, Vue und Void Zero, aber es geht heute um was anderes und zwar möchten wir über Rolldown sprechen. Und vielleicht erstmal, Alex kannst du uns mal sagen, was ist über Rolldown und wie bist du da beteiligt? Genau. Wir fangen am besten

SPEAKER_02: 3:59

mal ganz, also ich zoome mal ein bisschen raus, so Big Picture mäßig, dann können wir in die Details reingehen. Und zwar, wenn man jetzt in einer modernen Webentwicklungswelt anfängt, sagt, okay, ich lerne ein bisschen JavaScript, HTML, CSS. Klar, man startet vielleicht, okay, ich habe ein HTML-Dokument, ich kann da ein bisschen JavaScript reinschreiben, aber sobald man irgendein Framework benutzt, ähm, tatsächlich bis auf Vue, weil das kann man auch genauso noch benutzen, sagen, ich lade das über so ein Script-Tag rein, einfach als CDN und kann dann rein starten, wie man es früher mit jQuery gemacht hat und natürlich weniger Kilobyte und mehr Component orientiert. Aber ansonsten natürlich, wenn man irgendwas baut, auch in Vue geht das mit Single-File-Components, React, Angular, Svelte, man hat eigentlich immer eine Art Build-Step, weil natürlich man will dann das JSX oder die Komponenten oder das TypeScript ja dann irgendwie in JavaScript kommentieren. Und Da wird das natürlich, man durchläuft einige Schritte, man will vielleicht so Sachen machen wie, welche Browser möchte ich supporten, möchte ich Sachen umtransformieren und da ist eigentlich alles der Bundler für zuständig. Oder in anderen Sprachen ist so, ja, der Compiler, so ein Rust oder C oder so, sage ich, okay, ich transformiere das von der eigentlichen Sprache in Machine Code und hier ist halt von der eigentlichen Sprache wie TypeScript, View Single File Components, Svelte und so weiter und so weiter insgesamt zu JavaScript, weil der Browser kann ja kein TypeScript. Genau. Und ich glaube, da kann man ganz gut einsteigen, so der Bundler hat irgendwie ganz viele Aufgaben und in der Regel, im besten Fall nehmen es die Leute gar nicht so wahr, die haben dann ihr Tool, in der Regel Vite oder früher noch Webpack, einige nutzen vielleicht auch RS-Packs, sind so die beliebten Tools, vielleicht auch Parcel hier und da, die Build-Tools, die dann im Hintergrund einen Bundler laufen haben, der das Ganze dann macht, sowohl zur Dev- als auch zur Produktionszeit.

SPEAKER_01: 5:37

Und Du hast ja gerade schon gesagt, okay, es gibt schon viele Bundler. Was macht jetzt, oder was unterscheidet Rolldown? Also warum habt ihr den

SPEAKER_02: 5:44

entwickelt? Genau, auch da, ich versuche mal ein bisschen raus zu zoomen, weil wenn man sich so die moderne Web-Entwicklungslandschaft anguckt, dann hat man eigentlich für jedes moderne Framework, außer für Next.js, das ist so ein bisschen der Outlier, ein Build-Tool, nämlich Vite. Es hat sich in den letzten Jahren, so in den letzten Jahren, das ist schon ein paar mehr Jahre her, eigentlich sehr populär gesteigert, eigentlich nutzt Jeder wie, die sind außerhalb Leute von Next.js, weil bei Vercel, die setzen auf Webpack und TurboPack. Ähm, wenn das dann auch endlich production-ready ist, in dev läuft das mittlerweile, aber, äh, ich glaub, drei, vier Tests fehlen noch, es gibt so eine Seite, rbturbojet.com, äh, die das ganz gut anzeigt, äh, aber... Ist das der, ist das

SPEAKER_01: 6:23

der Successor

SPEAKER_02: 6:25

von Webpack? Genau, ist auch von Tobias, äh, so von dem eigentlichen Trainer von, von Webpack gebaut, da war die Idee so ein bisschen das, was, ähm, ich sag mal, Rodan, aber auch sowas wie ein RS-Pack ist, ist zu sagen, okay, wir bauen das in einer anderen Sprache, weil schneller, äh, und es soll halt ganz viele Sachen können und im Idealfall auch eine öffentliche API haben, äh, Die öffentliche API gibt es noch nicht und wie gesagt, es fehlen halt auch noch Tests für Next.js selber. Das ist aber nochmal eine andere Geschichte. Letztendlich kommen wir zu dem Punkt zurück, eigentlich nutzt fast jeder Veed, das ist so ein bisschen die Infrastruktur der modernen Webentwicklung und Veed an sich nutzt im Hintergrund zwei unterschiedliche Bundler. Das liegt daran, dass wenn man das noch kennt, irgendwie früher von Webpack, es hat alles ein bisschen gedauert, der Dev-Server wird gestartet, dann wartet man vielleicht im besten Fall 30 Sekunden, ansonsten ein paar Minuten, bis alles läuft. Das liegt daran, dass Webpack selber erstmal sagt, okay, für Dev-Mode, ich muss keine Optimierung machen, keine Minification aber ich muss trotzdem alles bundeln, um zu sagen, okay, sowas wie TypeScript zu JavaScript oder CoffeeScript war es ja damals noch oder Park zu HTML und so weiter. Und Vite, Evan, der auch Ersteller von Vue, hat Vite entwickelt, weil er gedacht hat, okay, so die Developer Experience von Vue CLI und von allem für Vue Entwickler ist ja okay, aber könnte besser gehen und hat dann gemerkt, okay, der Ansatz zu sagen, ich mache das andersrum. Ich habe so ein Entry-File und alles weitere regle ich mit dynamischen Imports. Also ich sage effektiv, ich lade nicht alles vorab, sondern ich mache das alles komplett dynamisch. Geht schnell. Die Browser hatten mittlerweile Kompatibilität dafür. Das ist auch immer so eine Frage. Warum hat man es früher nicht gemacht? Weil Kompatibilität den Browsern zum Beispiel gefehlt hat. Und es gab auch andere Tools, WMR, Snowpack, die so in die Richtung gingen. Ja, und Vita hat sich da so ein bisschen durchgesetzt. Und damit ist der Dev-Server halt super schnell, weil es eben kein gebundelter Dev-Server ist, sondern es ist mehr oder weniger unbundelt. Und dafür wird ES-Build genutzt, basiert auf Go, um zum Beispiel gewisse Dependencies zu pre-bundlen oder Types zu strippen, also das Nötigste zu machen, um die Dependencies bereitzustellen. Aber dann ist halt wirklich ein Request pro Dependency im Dev-Server und das geht halt recht schnell, weil gut, man muss halt keine großen CPU-Cycling drauf verwenden, man lädt es einfach nur runter, da es alles lokal ist, geht das ganz gut. Und dann in Produktion, wenn man das Ganze wirklich bauen möchte, wird Rollup genutzt. Ja, bisschen Verwirrung, Rollup, Rolldown. Sieht auch, wo der Name so ein bisschen herkommt. Hat auch den einfachen Grund, also ES-Build ist, ich sag mal zum Teil opinionated, aber zum Teil auch einfach einen sehr kleinen Scope. Rollup kann ein bisschen besser sagen, okay, ich möchte zum Beispiel meine Chunks etwas anders anlegen, ist aber auch sehr limitiert, hat aber auch ein großes Plugin-Ecosystem. So ES-Build hat nur sehr begrenzt Plugins, aber Rollup für alles mögliche Plugins. Die API ist sehr schön, ist ein sehr freundliches Ökosystem, auch im Vergleich zu anderen Bundler wie Webhack. Deswegen wurde das Ganze da für Production genutzt, um Sachen einfach zu vereinfachen. Und ist auch sehr gut, was so Optimierung angeht, der Code Elimination.

SPEAKER_01: 9:10

und so weiter. Das VEED-Plugin-System ist auch davon inspiriert, oder?

SPEAKER_02: 9:16

Genau, richtig. Yes, richtig, richtig. Und du musst ja im Endeffekt, wenn du ein VEED-Plugin schreibst, im Hintergrund ja auch Rollup und die S-Bild so ein bisschen beides nutzen, je nachdem, ob du was für Dev brauchst oder nicht. Aber genau, ist auf jeden Fall davon inspiriert und die API. Und da gibt es noch Unplugin, das ist eigentlich auch eine ganz schöne Sache, wo die Idee ist, so ein bisschen das jQuery für die Bundler. Also ich schreibe ein Plugin und das läuft dann von irgendwie Webpack bis Rolldown Das ist eigentlich auch ein ganz netter Approach. Gibt es natürlich einige Sachen, wo man sagt, es gibt eine Hook, die gibt es nur in VEED zum Beispiel. Aber das ist eine Möglichkeit, um Plugins zu schreiben, die halt überall laufen. Das nur als Einschub. Kann man auf jeden Fall, wenn man als Plugin-Autor sich das Ganze anschauen möchte, ist recht nützlich. Genau, und VEED nutzt eben diese zwei Bundler. Ja, und dann gibt es natürlich so ein Problem oder mehrere Probleme, weil es ist erstmal sehr cool, wie das irgendwann im Enterprise angekommen, das dauert ja immer so ein kleines bisschen und dann hat man aber gemerkt, dass zum einen, ja gut, die Builds dauern natürlich recht lang dann irgendwann, gerade wenn irgendwie so ein Shopify dann mal Sachen baut und auf der anderen Seite der Dev-Server, der Unbundled-Mode sozusagen, Der hat ein bisschen Probleme, wenn du halt nicht nur irgendwie 10 oder 100, sondern vielleicht so 1000 bis 10.000 Komponenten und Dependencies hast, weil dann hast du wirklich ein Request-Profile und das ist halt bei Enterprise schon, ja, dann doch einiges. Plus, wenn du noch sagst, du hast wie ein Proxy, so Corporate World, selbst wenn es wie lokal läuft, dann geht jeder Request da durch und dann ist der Dev-Server-Startup einfach, ja, es dauert. Produktionsbild, kein Problem, aber du willst

SPEAKER_01: 10:48

ja auch Features schieben und was bauen. Wir sind bei, ich glaube, 360 Files ungefähr. Wir haben schon so 10 Sekunden am ersten Start-up-Line. Am ersten natürlich super schnell, aber so einmal Refresh. Genau, richtig.

SPEAKER_02: 11:00

Und das ist halt ein Problem. Und dann natürlich das andere, die Inkonsistenz zwischen Dev und Prod. Wenn du natürlich zwei unterschiedliche Tools benutzt, ist das schwierig. Und genau, eine Möglichkeit, das zu vermeiden, ist natürlich zu sagen, man nutzt einen Bundler. Und jetzt könnte man sagen, okay, warum kontribuiert man nicht einfach zu Rollup oder zu S-Build und macht das Ganze? Weil ist ja alles Open Source und das ist auf jeden Fall eine Möglichkeit. Ist auch ein guter Punkt, dass Rollup eben genau das nicht ist. Es ist nicht einfach, wir nehmen, sorry, Rolldown das nicht ist. Wir nehmen nämlich einfach Rollup und Rustify das, Rolldown in Rust geschrieben und nimmt aber so ein bisschen das Beste der vorherigen Tools mit. Also sowohl von ES-Build, was so Verhalten und Co. angeht, auch natürlich die Schnelligkeit von Rollup, also da die API, das Plugin-Ökosystem und sogar Webpack, was so Chunk-Optimierung angeht. Weil Webpack kann das richtig, richtig gut. Da gibt es dieses Split-Chunk-Feature, um zu sagen, okay, ich möchte meine Chunks in bestimmten Gruppen haben, ich kann da Limits festsetzen. Das ist eigentlich recht schön. Genau, und deswegen war dann die Idee zu sagen, gut, okay, roll down, wir schreiben das Ganze in Rust, damit ist das sehr schnell. Und das Ziel ist zu sagen, wir haben einen Bundler, wie gesagt, der das Beste aus allen Welten der vorherigen existierenden Bundler verbindet. schneller ist als alles auf dem Markt. Das ist auch ein RS-Pack, was zum Beispiel in Rust geschrieben ist. Da ist Roll dann so dreimal schneller ungefähr. Zwei bis vier, je nachdem welche Benchmarks. Deswegen so ungefähr drei. Kann auch gerne nochmal die Benchmarks verlinken, wenn es jemanden interessiert. Die developer freuen sich immer über, oh, so schnell. Ja, gibt's für alles eine GitHub-Repo. Ist alles öffentlich. Kann man auch gerne selber laufen lassen. Ja, und dann war die Idee, okay, man unified den Bundler. ES-Build hat halt verschiedene Verhaltensweisen, die übernommen werden und verschiedene Features, sowas wie ich kann Sachen injecten und define. Rollup, wie gesagt, alle Plugins sollen idealerweise supported werden oder man braucht sie vielleicht nicht mehr, weil sie schon in Rolldown mit drin sind. Das ist aber das Ziel, wenn man irgendwann sagt, okay, da kommen wir so zum übergeordneten Ziel, Rolldown soll irgendwann der Standard-Bundler von Vite werden. Die Leute wollen ja nicht alle ihre Vite-Projekte migrieren, sondern idealerweise irgendwann die Vite-Major-Version wird gebammt und fertig, es geht. Das wäre halt so ganz schön. Und ja, da ist man entsprechend dran, das zu entwickeln. Rolldown ist aktuell in Beta 11, sowas in Richtung 1.0, 1.0, Beta 11 und es gibt sogar schon, das ist jetzt die große Neuerung vor ein paar Tagen zum Zeitpunkt der Aufnahme gewesen, eine Technical Preview von VEED mit Rolldown. Nennt sich Rolldown VEED, ist ein Paket, es gibt ein sehr einfaches Migration Guide, effektiv einfach nur Aliassen oder über Package Override, wenn man dann noch untergeordnete Dependencies hat, die VEED mit nutzen und dann kann man es austesten und tatsächlich die Build Speed Improvements, die sind so im Faktor 3 bis 16-fach, nicht Prozent. Also das ist schon recht schnell. Wir hatten einige Tests mit Early Adoptern, also beispielsweise GitLab hat, also Open Source gibt es ein Merge Request, das Ganze mal ausprobiert. Die haben jetzt keine riesigen Speed Improvements, weil die recht kleine Builds haben, aber bis zu 100 Mal weniger Memory Consumption. Das ist halt auch echt eine Nummer. Wir sagen, ja, okay, Speed ist ganz nett, aber auf einmal so CI-Kosten, wir brauchen kleinere Maschinen und ansonsten so Excalidraw als bekannte Open Source Applikation auf React basiert ist, so 16-fach schnellere Builds. Das ist halt ganz

SPEAKER_01: 14:15

nett. Und diese Memory Optimization, die kam einfach durch Rust. Also Rust ist da so viel effizienter als

SPEAKER_02: 14:23

Go oder was? Das ist ja effizienter als JavaScript. Rollup ist ja JavaScript-basieren und da geht es wirklich um den Build. Also gerade aktuell, der aktuelle Stand von Rollup, das ist nochmal ganz gut, dass du das ansprichst, da ist wirklich Optimierung für den Build-Server, also wirklich für, ich bilde für Production. Der Dev-Server ist weiterhin erstmal unbundled, aber später, können wir nachher noch ein bisschen ausführen, möchten wir natürlich auch so einen Full-Bundled-Mode wieder einführen, um eben diese Probleme, die Enterprise und größere Applikationen hat, mit einzuschränken.

SPEAKER_01: 14:50

Man kann das dann einstellen, was man im Dev-Server haben will, ob man es bundlen will oder

SPEAKER_02: 14:53

Jein, also erstmal wird das so sein, genau. Effektiv, wir sind aktuell so in der Phase 1, wo wir sagen, es gibt dieses Technical Preview von Roll Down Beat, Leute können das austesten, idealerweise ist es einfach nur ein Drop-In Replacement und it just works. Wenn es Probleme gibt, raised gerne ein Issue, also wir haben schon einiges an Feedback erhalten und Leute sind echt schnell, was das Fixen angeht. Das ist auch ganz schön, wenn man dann Leute hat, die da Vollzeit dran sitzen. Das ist halt ein großer Vorteil, dass wir das bei Void Zero ermöglichen können, dass halt Leute Vollzeit an dem Bundler und auch den darunterliegenden Tools sitzen. Und dann gibt es so Phase 2, das ist eigentlich so Phase 1.5 und 2. Der Full-Bundle-Mode soll als Opt-in erstmal verfügbar sein, auch da, um das zu stabilisieren, zu testen, zu gucken. Da kann man dann auch wählen. Und dann irgendwann, wenn Rolldown-Veed an sich stabil ist, ohne den Full-Bundle-Mode erstmal, oder auch wenn der stabil ist zuerst, aber wahrscheinlich erstmal ohne, dann wird das Ganze in Veed selber reingegeben. Zu sagen, okay, Veed 7 steht aktuell in Startlöchern, in Veed 8 wird das dann zumindest das Ziel, oder irgendeiner weiteren Major-Version, nicht 7 auf jeden Fall, das ist ein bisschen zu kurz. Wenn das alles gut getestet ist, keine Probleme, und weitere Features implementiert sind, dann... kann das losgehen. Vor allem Optimierung. Feature-complete ist es noch nicht komplett, aber es ist immer dabei. Es gibt so ein, zwei Sachen, gerade so für Framework- und Plugin-Autoren, die vielleicht noch nicht implementiert sind. Das hält in der Regel keinen vom Testen ab. Genau, und dann irgendwann Phase 3 wird dann der Punkt sein, wo auch der Full Bundle Mode als Default ist und man gar keinen Unbundled Mode mehr hat. Das liegt daran, dass so ein bisschen auch da wieder das Ziel ist, Best of Both Worlds für kleine und mittlere Applikationen soll es trotzdem super schnell sein, weil Rust basiert und optimiert. Heißt, wenn ich nur, keine Ahnung, ein paar Files habe, dann lässt sich das ganz gut durchlaufen, dann ist es egal, ob ich das unbundled habe oder nicht. Die Start Time soll richtig, richtig schnell sein. Und wenn ich das Ganze aber in größeren Applikationen habe, dann hilft es halt, der Full Bundled Mode einfach zu sagen, ich habe einen deutlich schnelleren Server. Sehr

SPEAKER_01: 16:53

cool. Ja, viele Informationen jetzt. Ja, es ist aber auch ein großes Ding, was ihr macht. Also ihr habt euch ja auch echt ein großes Ziel gesetzt, das Beste aus verschiedenen Welten einzubringen. Und ich frage mich auch so in der Entwicklung von Rolldown, war das schwer, das alles mit reinzubringen oder ist es dadurch, dass es schon irgendwo existiert, relativ straightforward, das dann in ein Produkt, in eine Library zu gießen?

SPEAKER_02: 17:16

Ja, also es ist recht schwierig. Auch da Disclaimer, ich schreibe selber jetzt nicht wirklich viel Raster. Ich contribute nicht zu Rolldown oder den Tools darunter im Sinne von Hardcore-Optimierung. Da gibt es viele Leute in unserem Team, die da richtig gut drin sind. Ich bleibe dann eher vielleicht Contributions zu den VEED-Plugins, um die noch performancemäßig zu verbessern im Zusammenhang mit Rolldown. Können wir auch noch nachher drüber quatschen. Oder sowas wie in Rolldown VEED ein paar kleine Änderungen, Verbesserungen, Integration. Aber ja, es ist natürlich super schwierig, wenn man sagt, ich möchte so das Beste aus allen Welten und dann gibt es vielleicht Vielleicht Tools, die dann unterschiedliche Meinungen und Auffassungen haben. An welchen Tools orientiert man sich dann letztendlich? dann ist natürlich auch der Punkt so, den Overhead zwischen, ich habe jetzt eine Sprache, Rust, da muss ich dann ganz viele Code-Manipulationen machen, ich muss aus dem Code einen Abstract Syntax Tree erstellen, also die technische oder die schematische Aufarbeitung des Codes, nicht einfach als String, sondern wirklich als Baum entsprechend, mit welchen Nodes gibt es, wie sehen die aus. Ja, das ist natürlich nicht ohne, deswegen ist es auch super, wenn Leute das aktuell testen, sagen, hey, vielleicht gibt es ja Probleme oder irgendwas klappt nicht und natürlich versuchen wir auch da nicht nur Performance aktuell ist natürlich super, so 16-fach ist super schön, da kommen natürlich noch deutlich mehr, sowohl Build-Time-mäßig als auch einige Sachen, wo zum Beispiel Roll-Up richtig gut drin ist, ist Dead-Code-Elimination, also Tree-Shaking, zu sagen, ich habe Funktionen, Variablen, die sind ungenutzt, die möchte ich nicht wieder ins Bundle reingeben. Da arbeiten wir auch noch dran. Da gibt es ganz viele Verbesserungen, wo wir noch das Bundle deutlich kleiner machen können. Aber ja, insgesamt ist es auf jeden Fall keine einfache Leistung. Es hilft natürlich, dass man sagt, wir müssen nicht von Null anfangen. Und sowohl Rollup als auch ES-Build haben natürlich Testsuiten. Es ist also auch da ganz gut zu sagen, man weiß, welches Verhalten man möchte. Dann kann man sich das entsprechend reinladen und dagegen implementieren. Aber genau, es gibt halt durchaus Situationen, wo man sagt, okay, wie soll man bestimmte Sachen handeln? Dann natürlich auch das ganze Thema ESM versus CGS, die zwei Formate in JavaScript, das ist eher mehr Legacy-Format, was man eigentlich nicht mehr braucht, aber was da trotzdem noch ganz viel gibt, CGS und ESM, was eigentlich so die Zukunft ist. Ja,

SPEAKER_01: 19:21

Spezifikationen. Ihr unterstützt

SPEAKER_02: 19:24

beides noch. Genau. Liegt auch daran, so Kompatibilität first. Idealerweise so, meiner Meinung nach, ESM ist die Zukunft. Es gibt eigentlich keinen guten Grund mehr, CGS zu nutzen, außer man hat halt noch eine Miner-Version und sagt, okay, hier in der nächsten Major, dann ist nur ESM only. Liegt daran, dass in Node selber man mittlerweile auch ECMAScript-Modules über Require nutzen kann. Node 18 ist ja mittlerweile End of Life und ab Node 20 wurde das Ganze gebackportet. heißt, da sollte es ganz gut klappen, aber wie immer, dann gibt es Leute, die sagen, ja, was ist mit Electron, was ist mit VSCode Extensions, also es ist halt leider nicht so einfach zu sagen, wir machen es nur ESM-only und fertig. Ich hoffe, wir kommen dahin irgendwann, es kann sich nur noch um Jahrzehnte handeln, aber ja, und das sind auch alles so Themen und ja, es ist tatsächlich sehr kompliziert und dann geht es auch weiter, wenn man sich nochmal dieses Thema Abstract Syntax Tree anschaut, es gibt viele Tools, die das machen, die sagen, ich nehme Code und packt das entsprechend zu einem Syntax-Tree, dafür gibt es auch eine Spezifikation, nennt sich ES-Tree, da halten sich die größten Parser und Co. dran und auch die Leute, also zum Beispiel Linter, erwarten dann ein bestimmtes Format, das halt ES-Tree-kompatibel ist. Da sind wir auch ganz gut dabei, JavaScript ist komplett ES-Tree-kompatibel. TypeScripts, tatsächlich, gestern die Meldung erhalten, dass das auch kompatibel ist. Das ist tatsächlich echt challenging, da sich einfach komplett zu alignen. Und dann gibt es trotzdem noch Edge-Cases und Probleme, wo wir dann wiederum zu den anderen Tools gehen und sagen, hier, guck mal, wir haben das spezifikationstreu implementiert, aber hier gibt es einen Bug. Gab es auch so einen Case, wo man das entsprechend rausgefunden hat und dann reportet hat, ich glaube, Babel und auch andere Tools, sagt hier, das ist nicht ganz korrekt.

UNKNOWN: 21:00

Ja.

SPEAKER_01: 21:01

Was ich auch sehr herausfordernd, aber auch irgendwie beeindruckend fand, war, dass beim ersten Release von Rolldown, der ja im April 2024 war, schon um die 50 Contributor beteiligt waren. Also das fand ich relativ viel für den ersten Release und hab mich erstens gefragt, also woher kamen die ganzen Leute? Das waren... Also irgendwie denke ich mir, vielleicht kommen sie aus VEED, aber das ist ja eine JavaScript-Welt, woher kommen die Rust-Leute? Und auch wie strukturiert man das dann, wenn so viele Leute am Anfang, wo ja noch vieles offen ist, dabei sind? Also wer hat dann da so die Flagge in der

SPEAKER_02: 21:34

Hand? Ja. Ich war tatsächlich, also ich habe das damals auch verfolgt, war da aber auch nicht dabei, in dem Sinne, dass ich es ganz von der Programmiersicht betrachtet, aber woher die Leute kommen, ist eigentlich ganz spannend. Können wir auch noch drüber reden, das Thema Unified Toolchain in JavaScript. Es gibt ja einige Projekte, die sagen, ja, lass mal ein paar Sachen rustifyen, lass mal eine Toolchain für alles bauen, dass wir eigentlich nur am besten Fall ein Kommando haben, es ist überall integriert. Das ist so ein bisschen das Ziel von Void Zero als Firma, zu sagen, ja, wir brauchen uns nicht mehr überlegen, welchen Formatter, welchen Linter, welchen Bundler, welches Build-Tool, welche Dokumentationsseite, welche Monorapper-Support, so einfach dieses Problem zu sagen, jetzt habe ich die Tools, jetzt picke ich mir die irgendwie zusammen und dann gibt es doch wieder Probleme, weil die mit dem Framework nicht funktionieren, das zu lösen. Da gab es vorher natürlich auch Projekte, Roam ist glaube ich mit das bekannteste, wo ja ein bisschen Geld verunreinigt wurde und dann gab es den Fork, ein Open-Source-Projekt, das war voll Open-Source, aber VC-backed und jetzt ist es Biome. Da kommen zum Beispiel einige Contributor her, unser VP of Engineering, Boshan, der für OXC den Oxidation Compiler, kommen wir auch noch drauf zurück, verantwortlich ist und da sehr, sehr viel macht. Der ist zum Beispiel ursprünglich, hat ja viel zu BIOM Contributed. Es gab viele Leute, die so aus der Turbo-Pack und auch aus der RS-Pack-Richtung kamen. Also einfach Leute, die schon in dem Umfeld so ein bisschen kollaboriert haben und da eine gute Möglichkeit haben zu sagen, okay, hier können wir entsprechend Impact verursachen, was machen, was ausrichten.

SPEAKER_01: 22:59

Ja, okay, das klingt schon cool und ich präsentiere auch für das Projekt, dass so viele Leute, die Ahnung haben, da zusammenkommen und versuchen, was Einheitliches zu bauen. Aber ja, du hast es eben schon erwähnt, ich glaube, man kann über Rolldown fast nicht ohne OXC sprechen, oder? Es hängt sehr stark zusammen.

SPEAKER_02: 23:15

Ja, absolut. Also da gehen wir jetzt nochmal eine Abstraktions-Ebene runter. Wir haben schon gesagt, okay, jetzt der Average Web Dev nutzt irgendwie Veed. So, Vite nutzt irgendwann Rodown, oder jetzt mit Rodown Vite, okay, alles klar, Leute kümmern sich in der Regel wenig um den Bundler, aber um einen Bundler zu brauchen, braucht man natürlich auch irgendwie eine Art Foundation, also Tools, so wenn man überlegt, was macht ein Compiler, der hat irgendwie noch einen Lexer und einen Parser und so weiter im JavaScript-Universum, was braucht man? Naja, zum einen auch einen Parser, man möchte ganz gerne eben diese Files, diesen Codestrings in AST überführen, wir brauchen einen Transformer, dass man eben sagt, okay, man kann zum Beispiel sagen, ich möchte meinen JSX transformieren, das können Plugins machen, kann man aber auch der Bundler direkt, wenn man möchte, oder der Compiler in dem Fall. Dann geht es aber auch weiter, so ein Resolver, weil wir zeigen auf unterschiedliche Dateien, wir möchten die gerne finden, gibt es auch wieder sehr viele unterschiedliche Spezifikationen. Und dann guckt man und sieht, okay, Minification wäre auch noch ganz schön, gibt also auch ein Minifier. Und was, denke ich, ganz interessant ist, dann für die Web-Entwickler, die jetzt nicht so tief in Bundler und Compiler-Bau in Anführungsstrichen drin sind, Linter und Formatter. Tatsächlich in dieser Suite des Oxidation-Compilers, da steckt auch ein Linter namens OxLint, der ist so 50-100 Mal schneller als ESLint, das ist schon ganz nett. Und ein Formatter, der ist noch Work-in-Progress zum Zeitpunkt der Aufnahme, OxFormat, Der soll einfach Pythia-kompatibel sein. Ja, und wer das Logo kennt, das ist so ein Anker. Der ist braun, weil, ja, ist ja alles in Rust geschrieben, so die Tour. Also es ist ein rostiger Anker. Und wie entsteht Rost? Durch Oxidierung. Deswegen Oxidation Compiler. Daher der Name. Es ist immer noch nach wie vor eine coole Idee

SPEAKER_01: 24:52

gewesen. Silvio und ich dachten ja, dass der Anker dafür da ist, weil dann die ganzen Entwickler bei diesem Anker hängenbleiben

SPEAKER_02: 24:59

sozusagen.

UNKNOWN: 25:01

Auch gut, auch gut.

SPEAKER_02: 25:02

Ja, ich sag mal, hoffentlich ziehen die Tools dann eigentlich runter wie ein Anker, sondern wir

SPEAKER_01: 25:07

prüfen

SPEAKER_02: 25:08

ja die Developing

SPEAKER_01: 25:09

Experience. Sie stabilisieren einen, würde ich sagen. Genau, das ist auch gut. Weil die ganze JavaScript-Welt ist ja sehr wild und es geht in viele verschiedene Richtungen. Ja, sehr fragmentiert. Vielleicht kommt da noch ein bisschen Ruhe rein, das ist ja auch nicht schlecht.

SPEAKER_02: 25:20

Das ist das Ziel. Also auch da ist es halt recht spannend. Wir können gleich noch detailliert über die einzelnen Teile reden, aber ein großes Thema aktuell, der React-Compiler, ein großes Thema, weil der ist aktuell in Babel geschrieben. Es gab mal die Überlegung, zu sagen, wir machen Rust-Port, da wurde wieder verworfen und jetzt gibt es ein Issue in der OXC-Repository, wo dann Leute vom React-Team gesagt haben, hier, React-Compiler, wie sieht es denn aus? Einfach weil, haben wir letztens auch gesehen, es gab, Evan hat das geteilt von Sanity, dem CMS, die haben mal geguckt, wie schnell das mit Road-Unbeat ist und mit und ohne Babel-Compiler und es ist halt schon irgendwie ein vierfacher Slowdown einfach, weil es halt in Babel geschrieben ist. Und gut, dann, ja, JavaScript dauert halt. Und wenn du durch jedes React-File musst, jedes TSX, JSX-File, schwierig.

SPEAKER_01: 26:07

Also ihr wolltet, dass der React-Compiler OXY nutzt.

SPEAKER_02: 26:11

Also die Idee ist nicht mal zwingend, es geht eher darum zu sagen, okay, den React-Compiler in was schnelleres, also was Rust-basierteres zu legen und dann ist es, also man muss ja nicht OXY direkt nutzen, ich glaube, dann finden das die Leute von SWC, das ist auch ein anderes Rust-based Projekt, vielleicht nicht so cool, einfach zu sagen, okay, ich habe einen Kompatibilitätslayer, was einfach sagt, ich nutze... Abstract Syntax Tree. Und dann zu sagen, hier, ich setze nicht voraus, was damit genau gemacht wird. Hier könnt ihr eure Tools reinwerfen, euer kleines Layer drüber schreiben. Das sind alles so Optionen. Aber auf jeden Fall ist es auch spannend, wie sich so die Richtung entwickeln wird. Den Issue auf jeden Fall, falls ihr daran interessiert seid und React schreibt und den Compiler nutzt, folgt ihm gern mal. Ja, und ansonsten, es passieren einfach so viele Sachen. Aber wenn man OXC nimmt, wie es aktuell ist, ist ganz lustig, der Parser selber ist eigentlich der schnellste Parser da draußen, insgesamt im WebDev-Ecosystem für JavaScript und TypeScript. Wichtig ist da so Conformance, man möchte ja, dass das alles korrekt geparst wird. Es gibt vom TC39, es gibt so einen Conformance-Test-Suite, die testt, ich glaube, 242, sowas in der Richtung, 262, gerade nochmal kurz geguckt. Die sind alle ready und passen. Das ist immer wichtig, wenn man eine Sache implementiert, dass auch alles wirklich so hinhaut. Man möchte ja nicht so, okay, man passt was und auf einmal kommt was Falsches bei raus. Man möchte ganz gerne die Nutzer da nicht enttäuschen. Und so als Benchmark, SWC, gerade wieder Direct-Nutzer nutzen das viel, was halt einfach schneller ist für das ganze Thema passen, transformen. Ja, OEC ist dreimal schneller als das und ist auch schon ein Rust-Tool, also auch ganz ordentlich. Genau, da kann man wie gesagt so Transformer, Resolver und so auch weiter gucken, ist aber auch recht schnell. Der Minifier aktuell noch in Alpha, könnte aber trotzdem schon recht gut nutzen, da geht es einfach darum, wir wollen das nochmal stabilisieren, es gibt noch einige Optimierungen, die wir verbessern können, aber von der, ich sag mal, Geschwindigkeit zur Output, also zur Compressed Output Ratio ist damit der beste. Es gibt natürlich Minifier, die sind schneller, die geben dann größere Bundles am Ende, weil klar, man muss irgendwo Tradeoffs machen, andersrum genauso. Ich kann sagen, ich möchte ein ganz kleines Bundle, dann dauert das aber länger. Wir ziehen natürlich darauf ab, dass wir im Idealfall beides machen können. Mal gucken, wie gut das wird. Aber auf jeden Fall, wir sind da auch benchmarkstechnisch irgendwie, sagen wir, wir bundlen TypeScript als Datei oder verschiedene andere Sachen ganz gut dabei. Je nachdem, welche Metrik man geht, eigentlich immer in den Top 3.

SPEAKER_00: 28:37

Also ich hab's so verstanden, dass ihr euch bei dem Plugin-System von Roll-Down an Roll-Up orientiert habt, dass ihr euch bei dem Ox-Lint an Air-Slint orientiert habt und Ox-Format an

SPEAKER_02: 28:52

Prettier? Jein, also es ist fast richtig. Ox-Format auf jeden Fall Prettier-kompatibel, genau. Tatsächlich als Fun-Fact dazu, Teile von OXY gab es im PR, der OXY-Parser kann schon in Prettier genutzt werden, es gibt dadurch schon Speed-Up. Ist natürlich nicht ganz so schnell wie alles in Rust entsprechend zu bauen. Liegt einfach daran, dass man sagt, okay, Prettier ist so der de facto Standard, das ist slightly opinionated, aber it just works. Man will sich in der Regel wenig Gedanken machen, zu sagen, welches Tool nehme ich dann und so weiter. Und die gleiche Idee gilt eigentlich auch für den Rest der Toolchain. Bei Oxlint ist so ein bisschen das Problem, in Anführungsstrichen. Ja, ESLint ist halt der Platzhirsch, jeder nutzt ESLint. Ein paar Leute nutzen BIOM und einige nutzen Oxlint natürlich. Jetzt ist so ein bisschen der Punkt, was macht man da? Und was wir gemacht haben ist, wir haben mehr als 500 Regeln portiert von ESLint in Rust. Das heißt, die laufen da von den beliebtesten Paketen mit. Einzige Ausnahmen, die es aktuell nicht gibt, sind stilistische Regeln, weil das soll der Vormitter machen, also sowas wie Sortieren von Imports, dies, das. Und Type-Aware-Linting, weil das einfach recht schwierig ist, dann muss halt TypeScript involviert sein eigentlich. Muss man also gucken, wie man das sinnvoll und Performance hinbekommt. Heißt, die gibt es noch nicht. Der Rest ist eigentlich, wie gesagt, die populärsten Sachen implementiert. Oxlent reagiert auch auf sowas wie ESLint Disable, einfach nur Kompatibilität mit so dem Platzhirsch. Das Schwierigste und Spannendste ist eigentlich das Thema Custom Rules. Also sowas wie Firmen haben ihre eigenen Lynch Rules. Wie schreibe ich die? Weil die will man ja nicht zwingend alle in Rust schreiben. Und Da gibt es auch einen langen Issue mit Diskussionen und Informationen, so ein bisschen das Problem der Trade-Off mit Kompatibilität, also ein bisschen wie, na, machen wir jetzt alles ESLint-kompatibel, dann verzichten wir aber auf Performance, wir haben sehr viele Legacy-Probleme, weil die ganzen Probleme der ESLint-API, das sind jetzt nicht tausende, nehme ich mal an, aber es sind genug, ja, sind dann auch bei uns, man müsste das in Zynk halten und so weiter. Dann gibt es Dino zum Beispiel, haben das gemacht, die haben eine komplett neue API für so Linting bereitgestellt. Hast du das Problem, okay, wie ist das mit Adoption, als ob jetzt alle Leute, die ein ESLint-Plugin maintainen, das auch als Dino-Lint-Plugin bereitstellen, das ist halt auch schwierig. Was wir versuchen, wir versuchen halt, was die API angeht, so ESLint-kompatibel wie möglich zu sein, ohne auf so viel Performance zu verzichten. Da wird aktuell noch viel experimentiert, deswegen gibt es auch aktuell noch keinen JavaScript-Plugin-Support. Aber der wird auf jeden Fall kommen. Nicht zu 1.0 tatsächlich, aber weitergehend. Wir haben da einen Blogpost in der Pipeline, weil die stabile Oxnard 1.0 Version steht, so ein bisschen vor der Tür. Und das ist halt einer der Fokusse, die wir eigentlich ganz gerne legen wollen. So zu sagen, okay, ihr könnt eure Custom-Lint-Rules schreiben, weil auch da wieder, wenn man Richtung Enterprise guckt, es gibt Firmen, die haben über hunderte, teilweise tausende Custom-Lint-Rules. Und da will man jetzt nicht sagen, ja, könntest du nicht benutzen, tschüss.

SPEAKER_00: 31:47

Meine Frage zielt eigentlich so ein bisschen in Richtung Vision, dadurch, dass die, also ich hatte es zum Beispiel gerade ein bisschen angerissen, also die Konfigurationssachen, die, also gibt es da? Seht ihr da irgendwo noch Verbesserungsbedarf? Also mir dreht sich immer der Magen, wenn ich dran denke, oh nein, ich muss jetzt in meine ESLint-Config irgendwas reinschreiben. Wie geht das nochmal? Und dann, wie war nochmal die Prettier-Config? Wie heißt das alles?

SPEAKER_02: 32:17

Also idealerweise, so die Idee wäre, und das läuft eigentlich jetzt schon ganz gut, ähm, Es ist halt slightly opinionated und it just works. Also im besten Fall brauchst du nichts konfigurieren. Du kannst einfach zum Beispiel jetzt schon sagen, du lässt einfach AuxLint laufen. Da sind alle Regeln, die Correctness, also wirklich sagen, der Code soll nicht falsch sein, an und dann ist gut. Jetzt ist natürlich die Frage, okay, es gibt immer Cases, wo man sagt, ich möchte Lintregel ausstellen, ich möchte was Custom hinzufügen, dies, das, klar. Aber die Idee ist, auch da wieder Unified Toolchain als Big Picture darzustellen, It just works. Linting ist immer so ein bisschen eine Ausnahme, wie gesagt, da gibt es verschiedenste Präferenzen, dies, das, aber ich glaube so für das Allgemeine wirklich die Idee zu sagen, du lässt ein Kommando laufen und es funktioniert und Caching ist eingebaut im besten Fall. Es ist alles performant und du musst dir darüber keine Sorgen machen. Also das ist das große, große Ziel.

SPEAKER_00: 33:14

Schön. Ich hätte noch eine andere Frage und zwar zu dem Punkt, dass wir im Dev Server den Bundled-Mode haben. Ja. Und ich wollte eigentlich nur nochmal ein Beispiel von dir haben für, es ist mir auf die Füße gefallen, dass es unbundled und bundled gibt.

SPEAKER_02: 33:36

Also aktuell in wie, genau, hast du den Dev-Server, der ist nur unbundled? Bedeutet also sowas wie Performance-Checks kannst du sehr schwierig machen oder gucken, welche Dependencies werden wann wie importiert. Das geht halt alles nicht. Also du kannst halt schlecht sagen, welches JavaScript-File, welcher Chunk, der dann auch in Production so wäre mit Minification und so weiter, importiert dann welchen Chunk. Warum wird was geladen? Also ein bisschen Performance-Optimierung zum Beispiel oder auch so das Thema Execution-Order. Da wäre es halt ganz gut, wenn man das einfach in Dev ähnlich wie in Production hätte. Jetzt natürlich nicht Minified, da kann man sagen, okay, performance-technisch Messung wäre eigentlich ganz gut, wenn man es auf Staging macht, aber zumindest, dass der Dev halt nachvollziehen kann, das funktioniert halt genauso. Und auf der anderen Seite, aus Veed-Entwickler-Sicht oder aus Veed-Team-Sicht auch, es ist halt Komplexität. Also, sobald ich halt ES-Bild und Roll-Up beides bedenken muss, bei allen Featuren, weil die sollen ja in Dev und auch in Produktion funktionieren, ist es recht schwierig. Genauso wie Baud zum Beispiel hat einen eigenen HMR-Mechanismus, also Hot Module Reload oder Hot Module Replacement. Das wird so in Zukunft auch von Role dann übernommen, sodass halt da auch Komplexität wegfällt, weil das kann der Bande dann direkt Da brauchst du dich wenig drum kümmern, da kannst du das Ganze einfach adaptieren und fertig. Also auf Entwicklerseite fällt halt Komplexität weg, zu sagen, jetzt wie werden meine Dependencies geladen, ich sehe jetzt nicht, keine Ahnung, 1000 Requests im Network, sondern ich sehe halt, okay, hier ist der Entry Chunk, hier ist dies, das, versus, auch wie gesagt, von der Maintainer-Sicht, weniger Komplexität, was ja auch nicht schlecht ist, bedeutet auch weniger Bugs.

SPEAKER_00: 35:09

Cool, ja, das verstehe ich. Das wäre dann wirklich Langzeit-Langzeit, weil ihr wolltet doch beide Modes noch weiter supporten, oder?

SPEAKER_02: 35:19

Langzeit-Langzeit ist immer so schwierig. Die Phasen, die ich vorhin erwähnt hatte, da geht es halt um Monate, nicht um Jahre. Das heißt also, solange der Full-Bundle-Mode opt-in wird, sobald er dann kommt, opt-in. Wird der getestet, genauso wie jetzt halt Rolldown-Weed getestet wird und sobald das stabilisiert ist, es keine Probleme damit gibt, alle Kinderkrankheiten ausgebügelt ist, ist das Ziel, das dann irgendwann als Default zu machen. Das wird aber dann, gehe ich stark von aus, auch irgendwann in einer Major-Version passieren, die jetzt nicht Weed 8 ist, weil da kommt ja erst Weed mit Rolldown, da wird es noch mit Opt-In bleiben, sondern 9, 10, wie auch immer. Genau, aber am Ende, das Maintain von beiden ist halt so ein bisschen schwierig, wenn man sagt, okay, es gibt halt einen Modus, der hat keine Trade-Offs, egal, ob du eine kleine oder eine große Applikation hast. Dann ist die Frage, warum behält man so die Komplexität, wenn es auch anders geht? Ich glaube, der Unbundled-Mode ist super hilfreich gewesen, um zum einen erstmal Entwicklern zu zeigen, hey, es geht auch schneller als ein Webpack und hat sehr viel so zu Wiens Popularitäten, auch so ein bisschen Identität mit beigetragen. Aber ich glaube, ab einem gewissen Punkt ist halt dann zu sagen, gut, warum, wenn es auch mit einem anderen Modus, der halt für alle Cases funktioniert, besser geht und eigentlich keine Nachteile hat, wenn es halt auch speedtechnisch ähnlich ist.

SPEAKER_01: 36:29

Und die Speed-Improvements kommen dann, weil es eben in Rust geschrieben ist, dann ist der Bundled-Mode ähnlich schnell, wie der Unbundled?

SPEAKER_02: 36:37

Genau, also die Idee wäre zu sagen, Webpack hat ja dann ewig gedauert, genau, da das Ganze dann in Rust geschrieben ist, deutlich optimierter läuft und ja, wir entsprechend auch aus den Lehren da gelernt haben und auch natürlich einige Optimierungen nicht brauchen für den Dev-Mode, dann würde das entsprechend schneller funktionieren, korrekt. Als nur so kleiner Hinweis oder als Randnotiz, wenn man sagt, wie schnell, man kennt das ja bei TS und TS Go, als Types gesagt haben, wir porten nach Go, es wird alles zehnmal schneller, das ist halt recht cool, aber ich habe so eine Statistik mal mitgebracht, die größte Repository, wo man mal Oxlend drüber gelaufen hat, ist jetzt kein Bundler, aber Linting ist trotzdem recht aufwendig, Ähm, das ist recht cool. Da haben wir, äh, ne Pfeilanzahl von fast, äh, also 264.925 Pfeils, also sagen wir 265.000 Pfeils. 101 Rules, also 101 Regeln. Äh, 10 Threads wurden genutzt, auch wieder das Vorteil, ne, Multithreading. Ähm, so, könnt ihr mal schätzen, wie lang hat es denn gedauert, über diese 265.000 Pfeils mit Oxland und den 100, äh, und einer Regel drüber laufen zu lassen?

SPEAKER_00: 37:41

Können

SPEAKER_02: 37:41

wir

SPEAKER_00: 37:41

raten.

UNKNOWN: 37:44

Ähm...

SPEAKER_00: 37:44

15 Sekunden.

SPEAKER_02: 37:46

15 Sekunden? Okay. 265.000 Pfeile für 15 Sekunden, das wäre schon...

SPEAKER_00: 37:49

Okay, ich habe gar keine Referenz.

SPEAKER_02: 37:50

Also ich sage mal so, in ES-Lint braucht man dafür ziemlich sicher Stunden.

SPEAKER_01: 37:57

Stunden. Ah, okay, da sind wir. Da sind wir. Ich wollte jetzt 30 Sekunden ansetzen, aber jetzt würde es höher gehen. Keine Ahnung, sagen wir mal eine

SPEAKER_02: 38:05

Minute. Eine Minute, eine halbe Minute, ja. 22,5 Sekunden. Ah, let's go. Ja, okay. War gar nicht so schlecht tatsächlich. Ja, ich habe mich vielleicht ein kleines bisschen irre gefühlt, aber das sind so die Szenarien, wo man auch merkt, okay, diese Tools, die in nativer Sprache geschrieben sind und das ist einfach, also auch bei so einem Minifier, wenn du sagst, Tursa zum Beispiel ist ja auch sehr populär oder ähnliches, wenn man das wirklich vergleicht, dann gibt es halt irgendwann einfach Time-Outs oder sagt man, okay, es ist nicht. Deswegen zum Beispiel Shopify nutzt Oxygen schon bei sich für verschiedene Regeln. Müssen ja nicht mal alle sein, einfach zu sagen, die teuren Regeln, sowas wie, guck bitte, dass es keine zyklischen Dependencies gibt. Ja, da brauchst du halt auch alle Files, weil, naja, du willst ja gucken, ob es irgendwelche Kreise darin gibt. Und dann zu sagen, okay, wir haben das halt in einer riesigen Monorepo, klar, dann... geht es halt nicht anders, als auf solches Tooling zu setzen. Und es ist eigentlich auch ganz schön zu sehen, dass genau das passiert, dass halt genau die großen Cases, für die funktioniert es auf einmal und auf einmal braucht man nicht mehr Stunden, selbst wenn es eine halbe Stunde ist, dass man das Ganze im CI hat, das ist doch alles Zeit. Es hat übrigens letztens jemand geschrieben, so allein, dass die Leute auf Rodon Beat migriert sind, kein Linter geändert oder gar nichts, 50.000 Dollar im Jahr CI-Kosten gespart, einfach durch die Zeit. Was macht die Firma jetzt mit

SPEAKER_00: 39:23

dem Geld? Ja, das wird doch gespendet an euch,

SPEAKER_02: 39:26

oder? Ich wollte gerade sagen, vielleicht springt eine Open-Source-Contribution bei rum. Mercedes-Benz zum Beispiel, wir hatten auch einen Post gemacht, Mercedes-Benz.io, die sagen hier, modernes Tooling und Co. und wie viel man so an Zeit sparen würde. Da hat auch jemand auf, ich glaube, BlueSky geschrieben, so, hey, ist ja voll cool. Ich hoffe, dein Sprechen wird ein bisschen des Geldes reinvestiert, um das auch weiter zu ermöglichen. Deswegen, das ist eigentlich auch mal ein ganz cooler Punkt. Man upgradet auf die Tools, ist halt for free. in dem Sinne und wenn dann, keine Ahnung, Zehntausende, Hunderttausende, wie auch immer, Dollar, Euro gespart werden, uns die Möglichkeit gibt, in der Firma das zurückzugeben, das ist immer eine gute Option, dann Open-Source-Projekte, da gibt es eine ganz große Auswahl, natürlich von VEED, von den Projekten, die wir haben, aber auch einfach, was ihr benutzt, das kann ja ein kleines Modul sein, das kann ein Framework sein, was zurückzugeben. Bin ich immer ein großer Fan von.

SPEAKER_01: 40:14

Ich find's halt einfach krass, was das dann für Auswirkungen hat, vor allem im Enterprise-Bereich. Vor allem, also auch mit der Geldgeschichte, also die Zeit, die man sich spart, ist ja schon immer cool. Und das

SPEAKER_02: 40:23

ist ja auch noch mal Geld, wenn man sagt, okay, bei mir Produktivität, aber wirklich auch so CI-Kosten noch dazu, das ist halt echt krass.

SPEAKER_01: 40:31

Ja. Aber reizt es dich als Source-Kontributor ein bisschen, in Rust einzusteigen, weil du hast ja schon gesagt, das passiert gerade an vielen Stellen und es hat halt auch sehr viel Sinn, das zu machen. Reizt dich das irgendwie?

SPEAKER_02: 40:44

An sich ja, also ich würde auch ganz gerne ein paar kleine Contributions, was weiß ich, vielleicht mal eine Regel oder sowas, so ein paar Good First Issues bei zum Beispiel OXC oder so Oxland in dem Fall oder so mit reingeben, Ich hatte Rust mir schon mal vor Jahren, so vor fünf Jahren oder so was mal angeschaut, einfach weil da war es schon die neue, trendige Sprache. Ich bin jetzt nicht so der, ich sag mal, low-level Mensch, in Anführungsstrichen. So C, C++ ist nicht so persönlich meins. Ich war lange Zeit der Freund von, ich baue coole Sachen und hier, seht mal, und nicht, jetzt kann ich das krass optimieren. Auf der anderen Seite natürlich, wenn man die Tools hat und so ein bisschen die Kombinationen, ja, reizt mich schon. Aktuell sehe ich natürlich, meine Zeit ist da ganz gut investiert, zu sagen, ich erkläre das und das, was die Leute Team mitarbeiten, ich gucke, dass das aus DX-Sicht irgendwie passt, ich gebe Feedback und kann so, ich denke mal, zeitlich besser kontributen, aber bestimmt gucke ich mal hobbymäßig rein, weil das ist super spannend, definitiv.

SPEAKER_01: 41:40

Ich finde es auf jeden Fall cool, auch wie es Communities zusammenbringt, so JavaScript und Rust werden da ja wahrscheinlich gerade sehr zusammen, also die finden sich zusammen und Auch das, was OXC überhaupt macht, so viele verschiedene Dinge zusammenbringen und das Beste aus allen Welten. Und wir haben ja auch schon ein paar Mal Void Zero angesprochen. Ist es richtig, dass ich das so verstehe, dass das auch das Ziel von Void Zero ist, das Ganze zusammenbringen und zu vereinheitlichen?

SPEAKER_02: 42:09

Genau, also bei Void Zero ist das Ziel in dieser, ich hatte es schon ein paar Mal gesagt, Unified JavaScript Toolchain. Ich glaube, auch wenn wir beim Thema Rust bleiben, ist es ganz gut. Evan hat dann gesagt, so das Cargo für JavaScript. Also einfach zu sagen, okay, ich habe effektiv ein Tool. Ich meine, wenn man jetzt sagt, das ist Vite oder Vite Plus, was gerade in der Mache ist, dann zu sagen, okay, alles klar, damit kann ich wirklich alles einstellen. abdenken, was das komplette Ökosystem braucht. Weil das geht, wie gesagt, das Thema, okay, ich kann irgendwas bauen, sei das eine Applikation, sei das eine Library, soll auch mit abgedeckt werden. Aktuell gibt's Tools on top of Rolldown, so als Library-Bundler. TS-Down ist damit das bekannteste. Es gibt dann noch O-Build. Heißt, wenn ihr ein Library habt und der nutzt da irgendwas zu bauen, guckt euch das mal an. Ist recht einfach. Gibt's auch ein schönes Video als Explainer, wenn euch das interessiert. Ähm, Und dann geht's halt weiter. Vielleicht auch irgendwann sagen, ich kann mein JavaScript Backend damit bauen, ne? Und eigentlich alle Jobs zu übernehmen. Linting, Formating, ich kann Docs erstellen, ich hab irgendwie DevTools zum Beispiel. Anthony Fu ist bestimmt vielen Namen, der abarbeitet seit geraumer Zeit an den Weed DevTools. Das ist auch Open Source. Jedes Weed-Projekt kann einfach direkt sehen, okay, nicht nur Bundle-Analysen kann man jetzt schon mit einem Visualizer, aber zum Beispiel, wie lange braucht denn mein Build? Welche Plugins dauern denn lange? Was gibt's da für Probleme? Ähm, Und noch weiteres, Frameworks können ihre eigenen Integrationen für die DevTools dann bereitstellen, um dann was Spezifisches zu haben und so weiter und so weiter. Also da ist echt viel in Arbeit. Und dann, ja, mit vPlus so die Idee zu haben, wir haben so das eine Ding und das covert eigentlich wirklich alles.

SPEAKER_01: 43:41

Wie

SPEAKER_02: 43:45

plus ist mir kein Begriff. Genau, das ist auch, wie gesagt, das ist in the making. Ich kann noch nicht so viel persönlich darüber berichten, außer eben, dass das so das Ziel ist. Das ist das, bei Void Zero, muss man auch dazu sagen, kann ich noch ein bisschen ausholen, wir haben ja Venture Capital, das erlaubt am Ende, dass Leute auch vollständig an Toolchains arbeiten können, weil aktuell machen wir de facto kein Geld. Das ist ja alles Open Source. Es gibt vielleicht hier und da Firmen, die sagen, ja, hier könnt ihr uns helfen, also ein bisschen klassisch Consulting oder in dem Sinne Verträge, aber das ist nichts, was skaliert oder womit man die Leute inklusive mir dann finanzieren kann. Deswegen, so Weed Plus wird das Produkt sein, Evan hat das auf der JS World schon mal vorgestellt, so heißt das Cargo für JavaScript, einfach zu sagen, Das ist eben das, was das Ganze komplett vereinheitlicht, was man dann entsprechend nutzen kann. Mehr dann im Herbst.

SPEAKER_01: 44:34

So viel kann ich schon mal spoilern. Wie Plus klingt ein bisschen dann wie ein Produkt, wie so ein Pro-Produkt, was dann bezahlt wird, aber das ist es nicht. Also es soll dann Open Source bleiben.

SPEAKER_02: 44:44

Das ist so ein bisschen der Punkt, wo man natürlich gucken muss. Monetarisierung ist ein wichtiger Punkt. Also Ich sag mal, wenn ich persönlich jetzt losgelöst... Es gibt viele unterschiedliche Möglichkeiten, Projekte zu finanzieren. Zum Beispiel... Wir haben überlegt, Direktos, das ist ein CMS, vielleicht kennt das einige, die haben zum Beispiel ein Dual Licensing, also die machen BSL, Business Source Licensing und sagen, hey, ihr könnt das nutzen, alles kein Problem, aber wenn ihr einen bestimmten Revenue Threshold übersteigt, also wenn ihr einen bestimmten jährlichen Umsatz habt, dann braucht ihr eine Lizenz. Und natürlich, das Ziel ist nicht zu sagen, wir gatekeepen jetzt die Community, sondern das Ziel ist eigentlich zu sagen, und das haben wir auch immer gesagt, auch als ich noch nicht in der Firma war und Evan im Herbst letzten Jahres darüber interviewt habe, das Ziel Ziel ist, Enterprise zu fokussieren, was die Monetarisierung angeht. Deswegen, es wird vieles sein, aber es wird nicht so sein, dass man sagt, okay, jetzt könnt ihr das Produkt benutzen, wenn ihr, keine Ahnung, 5er Monat zahlt oder ein 10er Monat. Deswegen, da keine Sorge. Und wichtig ist auch, das ist auch noch wichtig hinzuzufügen, alles, was aktuell unter MIT-License bleibt, wird auch, also was unter MIT-License ist, bleibt MIT-License. Wir machen also keine Rugpoles, das ist gar nicht geplant, ist auch Quatsch, weil gerade wir bauen alles rund um Veed, wenn wir jetzt sagen, Veed wird jetzt irgendwie freemium oder sowas, ja, das wird ein weiteres Web-Dev-Chaos auslösen und es bringt halt auch gar nichts.

SPEAKER_01: 46:11

Genau. Ich

SPEAKER_02: 46:11

sehe,

SPEAKER_00: 46:11

wie du denkst. Ne, ich habe, ja, also ich hatte auch nur vom Veed Plus erfahren, dass das halt irgendwann Ende des Jahres, und jetzt überlege ich gerade, wollte ich wegen der Wegen dem Timeframe, weil du sagtest ja, wir reden hier gar nicht von Jahren, wir reden von Monaten. Das heißt, die Sachen, die jetzt gerade noch in the Making sind, was meinst du, Minifier und Formatter?

SPEAKER_02: 46:34

Genau, Formatter ist so ein Prototyp, der wird ziemlich sicher bis Herbst verfügbar sein. Genau, Minifier ist halt ein Alpha, da geht es um Stabilisierung. Und ansonsten ist die Toolchain, sieht eigentlich schon ganz gut aus, würde ich sagen. Und dann eben Rolldown, wie schon gesagt, die Phasen, da geht es auch entsprechend um

SPEAKER_01: 46:51

Monate

SPEAKER_02: 46:51

ab.

SPEAKER_01: 46:53

Wow. Auf der OXC-Webseite ist noch die Nova JavaScript Engine aufgelistet. Genau. Ich

SPEAKER_02: 47:00

weiß, ja, tatsächlich muss ich ehrlich sagen, ist kein Projekt von uns, ist halt ein Projekt, auch Rust-basiert, was tatsächlich OXC nutzt. Also auch da OXC als eigenständiges Projekt zu sehen, ist natürlich auch ganz nett zu sagen. Es gibt verschiedene Sachen, die darauf bauen. Aber to be fair, die Webseite, ich hoffe, wenn ihr, liebe Hörer da draußen, das seht und auf oxc.is geht, ist die schon geupdatet, weil steht nämlich auch noch, dass der Prototyp komplett ist. Da ist noch einiges an Arbeit zu tun, aber wie immer, das gibt's hinten und vorne und an allen Enden. Ich update das, bis ihr das hört. Genau. Aber genau, JavaScript Engine, das ist ja, wenn man nochmal wieder runtergeht und sagt, okay, ich möchte dann ganz gerne mein JavaScript irgendwo laufen lassen. Aber das ist ein Work-in-Progress-Projekt. Ein weiteres spannendes ist Poffer. Die machen ja einen JavaScript-Engine basierend auf JavaScript, die das dann zu, ich glaube, irgendwie Wasm oder so kompliert. Das ist auch alles ganz wild. Hat aber alles nicht viel mit OXC zu tun, außer bei Nova, wie gesagt, die nutzen OXC als Projekt selber.

SPEAKER_01: 48:00

Wir springen zwar ein bisschen, aber ich will eigentlich auch nochmal zurückkommen auf Void Zero. Vor allen Dingen, ich stelle es mir halt schwer vor, wenn man so finanziert wird, die Interessen, beide Interessen irgendwie abzudecken. Also wie schafft man diesen Spagat Open Source und das, was die brauchen zu halten und was jetzt auch die Firmen von euch wollen. Also zum Beispiel, was wollen die Firmen denn von euch?

SPEAKER_02: 48:22

Genau, das ist ein guter Punkt. Wie gesagt, lustigerweise, ich denke immer zurück, so fast ein Jahr zurück in Japan, wo ich Evan, als er das publicly announced hat, auch gefragt hatte. Wir waren auf einer Konferenz, er hat gesagt, hey, lass ein Interview machen, eine Stunde. Und das ist auch erstmal der Punkt, als das Announcement kam mit, okay, es gab Seed Money von Void Zero, cool, 4.6 Millionen, dann denkst du erstmal, okay. Roam, oh, das lief gar nicht gut. Weitere Open-Source-Projekte mit Finanzierung, oh, was war's, Planet Scale, FreeTree gekürzt, dies, das. Da siehst du so ein bisschen die Horrormeldung. Und das ist voll fair. Das Problem ist, es gibt, also Open-Source und VC ist nicht zwingend problematisch. Es kommt halt auf viele Sachen drauf an. Zum einen, wer steht hinter dem Projekt? Evan mit einem Track-Record von Vue und Vite, der also wirklich sich für Open Source einsetzt, ist jetzt niemand, wo ich persönlich sage, ich würde dem Rugpull zutrauen. Der würde das nicht machen. Weil ich glaube, er hat sich so guten Namen gemacht, wenn er irgendwie schnell Geld braucht, gibt es da andere Methoden, als zu sagen, ich gründe eine Firma und dann mache ich hier, was weiß ich, kommerziell. Das ist auch das Ding. Schnelles Geld ist gar nicht das Ziel. Die Firma gibt es jetzt seit fast einem Jahr oder seit einem Jahr war es ja angekündigt offiziell, gibt es schon ein bisschen länger. Es ist noch kein Geld geflossen, wie gesagt, bis auf Consultancy-Contracts. Da sieht man aber auch, dass Evan sich die Investoren, denke ich, ganz gut ausgesucht hat, also zu sagen, okay, das Ziel ist erstmal, diese Toolchain zu bauen, erstmal die Fundamente für die Toolchain zu bauen, also Rolldown, das entsprechend wie zu integrieren, OXC, Formatter, Linter und so weiter. Und dann irgendwann zu sagen, es gibt ein Produkt, dann gibt es halt irgendwie zum Beispiel Enterprise, sowohl Support als auch irgendwie Monetarisierung. Es könnte sowas wie Hosted Solutions geben. Es gibt da ganz viele Möglichkeiten, was drumherum zu bauen. Wir sehen das in anderen Ökosystemen, auch Laravel zum Beispiel, allen vornheran mit Taylor Otwell. Taylor und Evan ja auch gut befreundet, die ja jetzt auch mit Laravel Cloud riesiges Investment haben, aber auch ganz viel drumherum haben, was aber dem Framework eigentlich gar nicht selber schadet. Heißt, da die Interessen zu vertreten, ist recht gut möglich, wenn man sich die richtigen Leute auszusammeln, die auch an die Vision glauben. Wenn man das vergleicht mit dem, ist vielleicht böse gesagt, aber dem Average Startup, sagt, okay, wir haben eine coole Idee, wir haben eigentlich nichts vorzuweisen, vielleicht ein MVP, hier ist eine Demo, wir brauchen Geld. Dann ist es natürlich eine ganz andere Reihe von Leuten, die vielleicht interessiert sind oder wo man entsprechend Investitionen und Funding bekommt, als, hey, ich bin der Ersteller von View&Vide, ich habe eine Vision für die JavaScript-Welt, guckt mal. So, dann sind die Investoren auch nicht so, die sagen, ich brauche meinen ROI jetzt nächsten Monat, sondern okay, wir geben Zeit, wir machen und wir glauben immer an diese Vision, zu sagen, man macht halt Web-Development an sich besser und natürlich, dabei soll am Ende auch Geld rumkommen, keine Frage. Eine Firma ist nun mal profitorientiert, aber das ist aktuell gar nicht der Fokus und wird dann, wie gesagt, spannend durch Produkte wie z.B. Weed Plus oder wie andere Sachen, die später kommen könnten, wie das Ganze dann wird.

SPEAKER_01: 51:28

Das heißt, im schlimmsten Fall, aber im Fall der Fälle, würdet ihr auch Investoren ablehnen, die nicht mit dieser Vision übereinstimmen? Die was anderes von euch wollen, als was ihr

SPEAKER_02: 51:39

wollt? Das ist definitiv in der Auswahl der Investoren passiert. Ich war nicht dabei, aber ich habe da genug Gespräche darüber gehabt, zu sagen, okay, es Man hat sich da schon ganz gut die Leute ausgesucht und angeschaut, die entsprechend eben da die Vision mit verfolgen, verstehen, tragen können und auch was zu beitragen können. Es geht jetzt nicht darum zu sagen, wer kann mir das meiste Geld geben, sondern es geht darum, wie können Investoren hilfreich sein, um diese Visionen letztendlich umzusetzen. Also sowohl Netzwerk, bestimmte Personen, wenn man jetzt sieht, okay, es sind Leute, Matt Beamer von Netlify ist zum Beispiel dabei, der investiert hat, einige wirklich bekannte Business Angel aus dem Web-Universum. Wenn man sagt, okay, die verstehen das Ganze aus der technischen Sicht, können aber auch helfen, das Ganze

SPEAKER_01: 52:25

voranzubringen. Ja, ich sehe die ganzen Vorteile daran und auch dieses Problem in der Open-Source-Welt, Geld generell als Problem vielleicht damit lösen zu können. Ich hoffe auf jeden Fall und ich wünsche euch viel Erfolg und auch irgendwie einen guten Weg, dass es für euch gut funktioniert und ihr da vielleicht auch Vorreiter für ein Positivbeispiel seid, weil eben hast du eigentlich nur Negativbeispiele aus der Vergangenheit genannt. Ich kenne jetzt auch selber kein Positives, aber ich habe irgendwie ein gutes Gefühl bei euch. Die Bedingungen wirken gut.

SPEAKER_02: 52:59

Vielen lieben Dank. Ich muss sagen, es gibt durchaus Positivbeispiele. Ich glaube, Superbase ist ein Positivbeispiel, wo man sagt, okay, hey, die haben ein Generous Free Tier, die machen coole Sachen. StackBlitz und irgendwie Bolt.new. Es gibt schon einige, wenn man jetzt nicht nur so auf die negativen, aber wie du es gerade gesagt hast, die negativen Sachen bleiben halt hängen, wie

SPEAKER_01: 53:18

es ganz oft so ist. Ja, das

SPEAKER_02: 53:19

stimmt. Spannenderweise das Thema Open Source und Geld, könnte man nochmal eine ganz eigene Episode mitfüllen, aber nur um das unterzubringen. Ich hatte nämlich auch immer gesagt, warum dann eine Firma, warum nicht was anderes und da ist der Punkt, das Ziel, man muss erstmal mit einer bestimmten Geschwindigkeit dran arbeiten, sonst passiert halt nicht viel. Du kannst ja nicht sagen, wir arbeiten da so ein paar Stunden nachmittags dran, ich muss ja die Rechnung zahlen, deswegen arbeite ich eigentlich woanders und so weiter und Gerade die Leute, die sich mit dem Thema auskennen, wie schon gesagt, es gab eine Leute, die vorher an RS-Pack gearbeitet haben, an Biome oder Rome gearbeitet haben und die dann mit dabei sind, aber auch einfach, weil es dann halt möglich ist, die Rechnung zu zahlen. Und das ist halt natürlich ein Punkt, wo man sagt, wenn man das Ganze realisieren will und da geht es dann nicht um Jahrzehnte, sondern um Monate und Jahre, also es ist auch in einer guten Geschwindigkeit. Und das, finde ich, sieht man eigentlich bei Void Zero ganz gut, dass das passiert. Nicht nur, dass irgendwie Issues superschnell beantwortet werden, aber auch einfach, dass es geht vorwärts. Und dann halt, ja, das geht eigentlich nur, wenn man entsprechend Geld zur Verfügung hat. Und man sieht das beim Vue-Team wiederum, das Vue-Team ist halt underfunded an sich. So, Evan sponsort oder gibt Geld zu Maintainern aus seiner eigenen Tasche, aber da ist ja keine Organisation in dem Sinne dahinter. Oder es gibt viele im Core-Team, die machen das halt, ja, nebenbei, im Freizeit. Was jetzt nicht zwingend schlecht ist, aber was halt zeigt, okay, das wäre halt bei Void Zero, was ja unabhängig vom Vue-Ökosystem ist und framework-gnostisch gedacht ist, so halt nicht ganz möglich. Ich glaube, von dem Punkt tatsächlich nochmal eine wichtige Bemerkung, nämlich das Thema Governance. Jetzt kann man sagen, okay, Void Zero wird jetzt viel mit Veed assoziiert, Rolldown, OXC und wenn man auf die Website guckt, man hat noch V-Test mit darunter, Testing haben wir gar nicht so viel besprochen, das gehört auch mit dazu. Und zwar, dass die Governance, was die Projekte angeht, Rolldown und OXC sind die zwei Kernprojekte, wo ähm, wo Void Zero eigentlich die Richtung steuert, sozusagen. Veed selber zum Beispiel ist, ähm, das ist immer ganz schön zu erwähnen, ein Projekt, wo Firmen, äh, also Leute beteiligt sind, die von, äh, unterschiedlichem Hintergrund firmentechnisch sind, also, äh, wie gesagt, klar, Evan, so seine Firma, äh, Safi, äh, ist auch bei uns, bei Void Zero mit dabei, äh, Hiroshi genauso, sind zwei Maintainer, dann haben wir aber viele, es gab zum Beispiel Maintainer, äh, Bjorn, der wurde von Astro für eine Zeit lang, äh, geheiert, äh, Patak, eigentlich der Hauptmaintainer mit, äh, der, äh, ist bei StackBlitz, Anthony Fu, der ist ja auch gefühlt überall mit dabei, der ist bei Nuxt Labs, also der Firma, die der Creator von Nuxt ins Leben gerufen hat und da ist es eigentlich ganz nett, dass man eben sieht, es geht nicht um die Interessen einer einzelnen Firma, das wäre auch in dem Sinne... gefährlich, sondern hier sieht man halt, okay, das ist ein Joint Effort. Plus natürlich im Ökosystem die ganzen Projekte, die dahinter stehen, die ganzen Frameworks, die ganzen Tools, sowas wie Playwright und Storybook und so weiter und so weiter. Also auch da ist es nochmal wichtig zu erwähnen, es geht halt nicht darum, dass jetzt Void Zero die ganze Welt kontrolliert oder die ganze Web der fällt, aber wir können halt, dadurch, dass wir zum Beispiel Safi und Hiroshi auf der Payroll haben, dass wir Wladimir, den Hauptmaintainer von V-Test, Vollzeit mit dabei haben und so weiter, haben wir die Möglichkeit, natürlich da Entwicklung voranzutreiben und auch sicherzustellen, dass das Ganze kontinuierlich gute Features bekommt, Bugfixes und auch da weitergeht. Das ist auch eine Art und Weise der Open-Source-Sustainability. Und dazu, das auch noch, wollte ich mir eigentlich für einen Pick aufheben, aber ich hatte zwei im Kopf. Es gibt ja von Century ein Open-Source-Pledge. Wer den noch nicht kennt, Firmen können also sagen, okay, für jeden Employee gebe ich im Jahr eine bestimmte Summe, ich glaube 2000 Dollar oder sowas an Open Source und dann kannst du entsprechend da gelistet werden, das Ganze kannst du reporten und da sind wir bei Word Studio auch mit dabei, das heißt unabhängig von Leuten, die wir auf der Payroll haben, sponsern wir also auch nochmal entsprechende Leute. Genau, pro Entwickler ist wichtig, nicht nur pro Employee, sondern pro Entwickler. Heißt, wenn ihr nur zwei Entwickler habt, ist das recht günstig. Da kann man damit gelistet werden. Ist nicht nur eine nette Möglichkeit, es für Open Source zurückzugeben, sondern auch zu zeigen, dass man in der Firma natürlich das Ganze in einer Art und Weise fördert. Genau. Und das Logo kommt dann auch auf den Times Square. Das kann ich auch nochmal senden. Das ist immer so in gewissen Abständen, ich glaube jedes halbe Jahr, die Leute, die im Open Source Pledge joinen. Da gibt es dann auf der NASDAQ welcomes all the people, oder all the companies joining Open Source Pledge und die Logos. Das war auch ganz cool, das zu sehen.

SPEAKER_00: 57:51

Ja. Sehr

SPEAKER_01: 57:51

cool.

UNKNOWN: 57:51

Dann...

SPEAKER_01: 57:51

Hast

SPEAKER_00: 57:54

du noch Fragen, Sebi? Ich habe keine

SPEAKER_01: 57:54

Fragen mehr. Dann mache ich jetzt mal den Jan und frage seine typische Frage. Alex, haben wir dich irgendwas gefragt oder nicht gefragt, wo du dachtest, oh, darüber möchte ich aber unbedingt sprechen. Das fehlt uns jetzt noch. Du hast eben schon Testing angesprochen. Vielleicht willst du da noch drüber sprechen. Aber ansonsten, was auch immer du noch loswerden willst,

SPEAKER_02: 58:12

gerne. Ja, erst mal eine gute Frage. Als Podcast-Host appreciate ich das immer sehr. Auch wenn es die meisten sagen, nö, eigentlich haben wir alles besprochen. Ich denke auch im Großen und Ganzen, passt das. Ich glaube, das Wichtigste, auch da nochmal, es geht, jedes Framework ist da mit drin, testet gerne mal Rodon Beat, oder wenn euch das weit, weit in der Zukunft anhört, testet die Full Bundle, wenn der schon raus ist. Und das Wichtigste, wenn ihr irgendwelche Fragen habt, dann scheut euch nicht zu posten, sei es irgendwie auf Socials, schickt mir was weiß ich, auch eine E-Mail, das ist auch in Ordnung. Also nur zu damit. Und eine letzte Bitte, Es gibt eine Repository, die nennt sich Rodan Perfwins, also Performance Wins. Da tragen Leute dann ein, so, okay, ich hab meine Applikation, entweder in die Open Source ist noch besser, aber wie schnell ist sie denn geworden? Wenn ihr das Ganze nutzt und euch da verewigen wollt, immer her damit, the more the merrier. Und ansonsten kommt gerne in die Discords, den Rodan Discord oder auch den Weed Discord, wenn ihr... irgendwie Feedback braucht, sagt, hey, das ist irgendwie nicht ganz so schnell wie erwartet, könnt ihr mir helfen? So, wir sind da eigentlich in der Regel immer mit dabei und stehen mit Rat und Tat zur Seite.

SPEAKER_01: 59:23

Cool. Die Links werden wir auf jeden Fall auch noch in die Shownotes packen und was für Links wir da auch reinpacken, sind die Pics of the Days und da lassen wir den Jingle laufen, dann geht's ab.

UNKNOWN: 59:36

Musik

SPEAKER_01: 59:51

Alex, du hast schon eben deine erste Möglichkeit für den Pick genannt. Willst du die zweite direkt auch nennen?

SPEAKER_02: 59:58

Ja, klar, gerne. Genau, ich habe so ein bisschen zwei reingesneakt. Das kann mal passieren, habe ich gehört. Mein zweiter Pick ist doch deutlich technischer fokussiert und zwar es ist Knip, K-N-I-P, knip.dev. Logo hat so eine Schere und genau darum geht's. Wir wollen was loswerden, wollen was abschneiden. Nämlich all die ungenutzten Dependencies, die ungenutzten Exports und Files. Das kann nämlich Knipp machen in, auch wieder, Framework-Agnostic-Plugins, die automatisch eingesetzt werden, egal was man nutzt von irgendwie, wenn ich ESLint nutze, dann wird natürlich die ESLint-Config ignoriert und dann wird geguckt, was nutzt denn da, was steht da drinnen, Framework-basiert und so weiter. Ist eine sehr gute Möglichkeit, um nicht nur einmalig, sondern auch gerne in CI sicherzustellen, dass ihr keine ungenutzten Nutzenden-Dependencies mehr habt. Und ja, ist ein sehr, sehr cooles Projekt. Wird fast überall mittlerweile genutzt. Tatsächlich auch in Repositories wie Rolldown und auch Nux selber. Deswegen, ja, Knipp. Eine sehr, sehr gute Option, denke ich. Guckt euch das gerne mal an. Und ansonsten, wenn irgendwas nicht klappt, Contributed. Die Plugins sind sehr einfach zu erstellen. Ich hatte vor einer Woche oder sowas auch erst Contributed. Das ist richtig

SPEAKER_01: 1:01:05

smooth. Sehr geil, Knipp. Kannte mir nix. Kannte ich auch nicht. Zebi, was hast du mitgebracht?

SPEAKER_00: 1:01:13

Mein Pick of the Day ist ein Proposal für Random Functions. Zuerst Stage 1, aber ich finde Random Function in JavaScript, das lohnt sich, dass man da mal ein bisschen das Game upsteppt. Irgendwie immer ständig so eine Shuffle-Function schreiben oder irgendwie Krempelskram. Ja, und vor allem auch, dass man es vielleicht irgendwann mal seeden kann für Tests

SPEAKER_02: 1:01:41

und so. Da gibt es auch ein Proposal

SPEAKER_00: 1:01:42

zu, ne? Ist das damit drin? Ne, das ist ein anderes, ja. Aber da bin ich auf jeden Fall Feuer und Flamme. Da freue ich mich sehr, wenn das endlich kommt.

SPEAKER_02: 1:01:50

Boah, da habe ich eine Anekdote zu tatsächlich. Die muss ich so ganz kurz loswerden. Tatsächlich, in 2015 ging mir das auch schon so sehr auf den Sack. Dann habe ich in die E-Mail-Liste vom TC49 da geschrieben, sagt, hier sieht es aus, wollen wir nicht mal irgendwie so eine random Shuffle-Funktion für Arrays erstellen? Kam leider nie eine Antwort. Aber

UNKNOWN: 0:00

...

SPEAKER_02: 1:02:08

Zehn Jahre später. Zehn Jahre später. Ich habe mich mit dem

UNKNOWN: 0:00

...

SPEAKER_02: 1:02:13

mit ein paar Leuten vom TC-Funnel unterhalten, die waren auch auf der Konferenz, und hab gemeint, hey, wie sieht's denn aus, Use Case, wie ist das? Und ja, Sachen passieren. Deswegen

UNKNOWN: 0:00

...

SPEAKER_02: 1:02:22

Es ist megaspannend. Und es gibt zwar die Array-Schärfe-Funktion immer noch nicht, auch in dem Proposal nicht, aber mal gucken. Es wurde auf jeden Fall angeraten, dann zu schauen, ob es da vielleicht noch neben dem Random-Function-Proposal und Seed-Function-Proposal Platz gibt, um mal zu schauen, was möglich ist.

SPEAKER_00: 1:02:37

Ja, ich hab mich jedenfalls sehr

SPEAKER_01: 1:02:39

gefreut. Ja, ich find's generell

UNKNOWN: 0:00

...

SPEAKER_01: 1:02:40

Also, es sind grad einige Proposals am Start, die ich spannend finde.

SPEAKER_00: 1:02:43

Passiert grad viel, find ich. In dem Proposal ist tatsächlich

SPEAKER_02: 1:02:48

eine Shuffle für

UNKNOWN: 0:00

...

SPEAKER_02: 1:02:48

Ich hab auch

UNKNOWN: 0:00

...

SPEAKER_02: 1:02:49

Ja, fair. Ist das nicht array.toShuffled? Nee,

SPEAKER_00: 1:02:51

ist das random.shuffle, und da gibt's das Array

SPEAKER_02: 1:02:53

rein. Ja, genau, das macht Sinn. Ja, geil, sehr schön. Endlich! Es hat nur zehn Jahre bis Stage 1, das ist übertrieben, gedauert. Aber ich stimme da Gareth und noch dir, Sebi, voll zu, es passiert super viel. Und das ist echt schön, dass nicht irgendwie früher so ist. Es passiert langsam und gemächlich was. Ja. Super zu sehen.

SPEAKER_00: 1:03:13

Finde ich auch. Erinnert mich grade, wenn du sagst, der Scope von zehn Jahren, so ein bisschen wie dieses Temporal. Temporal, wo man irgendwie schon seit 100 Jahren die Schmerzen spürt von der Date-API.

SPEAKER_02: 1:03:26

Da gibt's auch noch einen geilen Fun-Fact zu. Mozilla, also Firefox hat es ja geschippt mittlerweile als erster Browser. Und das Krasse war, die Implementierung kam nicht von einem Mozilla-Mitarbeiter, sondern von einem Random-Contributor, der es einfach alleine in Firefox da reingebracht hat. Oh, krass. Ich glaube, Andre heißt der mit Vornamen. Das war so eine Sache, glaubt

SPEAKER_01: 1:03:48

man manchmal nicht. Aber vielleicht stößt das jetzt was an. Ich hoffe

SPEAKER_00: 1:03:51

doch. Der war vielleicht maximal frustriert. Hat gesagt, ich mach's jetzt

SPEAKER_02: 1:03:55

einfach. Ja, Andre Barghuli. Das steht auch in dem Blog-Post dazu drin. Okay, ja. Ein einziger

SPEAKER_01: 1:04:05

Volunteer. Wild. Wild. Open Source ist was Schönes. Ist was Schönes. Ich habe auch noch was mitgebracht. Und zwar haben wir heute viel über Technologie gesprochen, die eher low-levelig ist. Und dazu habe ich mal ein sehr cooles GitHub-Repository gefunden. Das heißt Build Your Own X. Und da ist eine ganze Sammlung von Links, die zu irgendwelchen Tutorials oder Artikeln führen, wo man eben bestimmte Dinge selber nachbaut von null, von Scratch sozusagen. Also da ist zum Beispiel Git dabei. Ein großes Ding ist immer Build Your Own Redis. Und ich finde es gerade cool, auch jetzt in der Welt von AI, wo man, ich glaube, viele Endprodukte vielleicht nicht mehr selber baut oder mehr von der AI machen lässt, ist es trotzdem immer cool, auch mal selbst Hand anzulegen und Dinge von Grund auf zu verstehen. Und ich glaube, wenn man sowas mal baut, dann lernt man da sehr viel. Und ja, diese Liste ist Super lang, super spannend. Was noch fehlt, ist Build Your Own Bandler. Ja, da kommen

SPEAKER_02: 1:05:06

vielleicht noch Blogposts zu, auch generell, wie so ein Bandler funktioniert, was die Anatomie ist, warum, wieso, weshalb. Ja, alles auf der endlosen Liste.

SPEAKER_01: 1:05:13

Ja, es gibt viel zu tun. Und viele coole Ideen. Aber genau, da kann man mal reinschnuppern, mal was nachbauen. Ich glaube, das kann Spaß machen und man lernt halt

SPEAKER_02: 1:05:25

super viel. Mega wichtig. Ich finde so gerade das Foundational, also die Grundlagen oder sowas, wie funktioniert das unter der Haube? Ich glaube, es hat ganz viele zum Programmieren gebracht. So zum Beispiel, okay, ich nutze dieses Programm. Wie könnte ich sowas denn selber machen? Oder wie funktioniert das? Das ist halt mega cool. Und vor allem so dieser Spagat zwischen ich nutze etwas versus ich baue einfach selber. Bei Frameworks zum Beispiel, um nochmal auf die technische Ebene zurückzukommen, zu sagen, ich nutze ein React oder ein Vue oder ein Angular aus der Welt versus ich baue daran zwei verschiedene Welten. Deswegen sehr, sehr, sehr, sehr cooler Pick.

SPEAKER_01: 1:05:56

Ja, das ist auch das, was man macht, wenn man generell als Contributor einsteigt in Open Source Software. Man geht halt eine

SPEAKER_02: 1:06:04

Stufe tiefer. Ja, ich meine, wahrscheinlich, wenn man wirklich komplett anfängt zu sagen, okay, irgendwie Modul zu irgendwas, wo man sagt, ich habe Ich habe zumindest noch so ein bisschen Beziehung dazu und ist nicht, keine Ahnung, hier, ich debugge Reaktivität und da sind Proxys und da muss ich was tracken. Aber auch da, Step by Step. Und auch was ich da ganz gerne zu sagen, Contributions sind auch Dokumentation, Contributions ist Content genauso. Und Failing Tests sind auch immer super, Issue Triaging. Das ist halt alles richtig viel wert. Deswegen scheut euch da nicht und Contributed. Tut es.

SPEAKER_01: 1:06:37

Cooler Aufruf, das ist doch ein schönes Pluswort. Vielen Dank, Alex, dass du da warst, dass du so viele Einblicke gegeben hast in Roll Down, OXC, White Zero. Ich finde es super spannend, in welche Richtung ihr da geht. Auch Sebi, vielen Dank, dass du dabei warst und dieses Thema spannend fandest und deswegen Lust hattest, mal wieder im Podcast zu sein. Hat mir sehr viel Spaß

SPEAKER_00: 1:06:59

gemacht. Und danke dir, Gareth, auch.

SPEAKER_01: 1:07:01

Großartige Motivation. Vielen Dank an euch. Sehr gerne. Ankündigung, machen wir nicht in Deep Dives. Das habe ich schon gelernt. Deswegen sage ich einfach vielen Dank fürs Zuhören und bis zum nächsten Mal.

UNKNOWN: 1:07:20

Bis dann. Tschüss. Ciao, ciao.