00:00:00- Die finale öffentliche Version von V+ wird sich wahrscheinlich,
00:00:03sie wird sich irgendwie nach Spaß anfühlen.
00:00:06- Das ist Evan Yu.
00:00:07- Evan Yu.
00:00:09- Evan Yu.
00:00:10- Evan Yu!
00:00:10- Ich habe Vue gemacht, ich habe Vite gemacht.
00:00:14Jetzt leite ich eine Firma namens Voice Zero.
00:00:16- Wie unterscheidet sich Vite von Vite+?
00:00:19- Die Developer Experience wird genau so sein,
00:00:21wie Vite heute ist.
00:00:22Aber wenn man noch weiter gehen will,
00:00:24ist es den ganzen Weg über für dich da.
00:00:26- Wie nutzt das Team und du selbst KI?
00:00:28- Wir haben angefangen, verrückte Experimente zu machen,
00:00:30wie zum Beispiel den Angular-Compiler nach Rust zu portieren.
00:00:32- Was hältst du von React Server Components?
00:00:34- Ich war vom ersten Tag an skeptisch.
00:00:36- Normalerweise, wenn ich einen Podcast einleite,
00:00:39bitte ich die Gäste, sich selbst vorzustellen.
00:00:40Aber ich glaube, wenn jemand das hier sieht
00:00:42und nicht weiß, wer du bist, wäre ich extrem überrascht.
00:00:44Ich finde, du bist einfach so bekannt.
00:00:46Aber jeder sollte wissen,
00:00:48oder die meisten sollten wissen, wer du bist.
00:00:49- Von Vite oder Vue haben sie definitiv schon gehört.
00:00:53- Ja, also ich habe Vue und Vite erschaffen.
00:00:57Jetzt leite ich Voice Zero,
00:00:59wo wir an noch mehr Open-Source-Projekten arbeiten.
00:01:03Da gibt es Rolldown, Vitest, OXC.
00:01:07Und ja, Vue und Vite sind wahrscheinlich bekannter,
00:01:11aber einiges von dem, woran wir bei Voice Zero arbeiten,
00:01:14ist auch ziemlich cool.
00:01:15Denn Rolldown ist ein Rust-basierter Bundler.
00:01:18OXC ist diese komplette Rust-Toolchain, die alles abdeckt,
00:01:22vom Parser über den Resolver und Transformer
00:01:25bis hin zum Minifier und so weiter.
00:01:28Auf OXC aufbauend haben wir OXLint und OXFormat,
00:01:32was ein ESLint-kompatibler Linter
00:01:35und ein Prettier-kompatibler Formatter ist.
00:01:37Wir arbeiten noch an mehr Dingen, aber ja.
00:01:41Wir wollen uns erst mal auf Open Source konzentrieren.
00:01:45- Klar.
00:01:45Da du an so vielen Dingen arbeitest,
00:01:47wie teilst du dir deine Zeit ein?
00:01:50- Nun, ich schreibe nicht persönlich den Code
00:01:52für all diese Projekte.
00:01:53Tatsächlich schreibe ich heutzutage viel weniger Code,
00:01:56seit ich die Firma gegründet habe.
00:01:58Wir haben in der Firma viele Ingenieure,
00:02:01die in Rust viel besser sind als ich,
00:02:03und die sind jetzt alle voll auf KI.
00:02:05Es ist also quasi zur Hälfte sie und zur Hälfte Claude oder Cursor,
00:02:10die eine Menge Rust-Code schreiben.
00:02:12Ich muss mich entscheiden, was wir tun,
00:02:17viele DX-Entscheidungen treffen
00:02:22und festlegen, worauf wir uns als Nächstes konzentrieren.
00:02:25Und offensichtlich geht es auch um Produkte,
00:02:28also wie wir das in ein Produkt verwandeln,
00:02:31mit dem wir Geld verdienen können,
00:02:32woran wir immer noch arbeiten.
00:02:34Ja, es sind all die Dinge, die man tun muss,
00:02:39um heutzutage ein Unternehmen zu führen.
00:02:41- Woher kommen die Ideen
00:02:43für die neuen Open-Source-Projekte?
00:02:45Entstehen sie meist aus internen Bedürfnissen,
00:02:48bei denen ihr merkt, dass sie auch
00:02:49die Probleme anderer lösen könnten?
00:02:53- Es fängt eigentlich alles bei Vite an, oder?
00:02:56Als ich Vite erstellt habe, habe ich nur daran herumgebastelt.
00:03:01Es begann als Prototyp,
00:03:03und dann dachte ich: Wir brauchen einen Bundler.
00:03:07Wir fingen mit diesem komplett ungebündelten,
00:03:10nativen ESM-Dev-Server an, richtig?
00:03:13Die Idee funktionierte super für einfachen Code,
00:03:16aber dann fügten wir große Abhängigkeiten hinzu
00:03:18und merkten: Okay, das wird nicht gut skalieren,
00:03:21wenn man alle Dependencies ungebündelt lädt.
00:03:24Zum Beispiel, wenn man Lodash lädt,
00:03:26was etwa 700 Dateien sind.
00:03:28Also sagten wir uns: Okay,
00:03:30wir brauchen etwas, um die Dependencies zu bündeln.
00:03:34Damals gab es Rollup, esbuild und Webpack.
00:03:41Webpack gibt kein ESM aus, also fiel das weg.
00:03:47Ich sah mir Rollup an, und Rollup ist ziemlich langsam.
00:03:50Es ist sehr langsam im Vergleich zu esbuild, oder?
00:03:53Schneller als Webpack, aber langsam im Vergleich zu esbuild.
00:03:56Also nutzten wir esbuild zum Vorbündeln der Dependencies,
00:03:59was wahnsinnig schnell ist.
00:04:00Den Quellcode lieferten wir als ungebündeltes ESM aus,
00:04:02und das funktionierte hervorragend.
00:04:04Aber für die Produktion
00:04:06dachten wir ursprünglich:
00:04:08Lass uns einfach esbuild nehmen, um alles
00:04:10für die Produktion zu bündeln.
00:04:11Dann merkten wir, dass esbuild nur begrenzte Kontrolle darüber bietet,
00:04:14wie Chunks aufgeteilt werden.
00:04:17Das ist bei größeren Anwendungen aber extrem wichtig,
00:04:19weil man zum Beispiel sagen will:
00:04:21Ich möchte diese Bibliotheks-Abhängigkeiten
00:04:24in einen Vendor-Chunk packen, damit sie besser gecacht werden.
00:04:26Dieser Chunk soll sich nie ändern, oder?
00:04:28Er soll einen konsistenten Hash haben.
00:04:32Selbst wenn ich meinen Quellcode ändere,
00:04:33sollte der Chunk-Hash gleich bleiben.
00:04:35So haben die Nutzer diesen Chunk immer im Cache,
00:04:38wenn sie die Website besuchen.
00:04:39Es gibt viele solcher Optimierungen,
00:04:41die esbuild einfach überhaupt nicht zulässt.
00:04:44Es hat ein Standardverhalten für das Chunk-Splitting,
00:04:47und das war's.
00:04:49Das Plugin-System ist auch weniger flexibel.
00:04:53Wenn ein Plugin entscheidet,
00:04:56dass es diese Datei verarbeitet, dann ist es so.
00:04:59Kein anderes Plugin kann sie danach noch anfassen.
00:05:02Wir hatten aber schon viel mit Rollup gearbeitet
00:05:05und kannten dessen Plugin-System gut.
00:05:08Also landeten wir bei: Okay,
00:05:10wir nehmen Rollup für das Production-Bundling,
00:05:13aber esbuild für das Pre-Bundling in der Entwicklung.
00:05:15In dieser Kombi hat jedes Tool einfach das getan,
00:05:20was es am besten kann.
00:05:23Tatsächlich basiert Vite 6 heute immer noch
00:05:26auf dieser Kombination.
00:05:27Und das funktioniert für viele Leute ziemlich gut, oder?
00:05:31Aber natürlich gibt es Probleme, denn esbuild
00:05:35ist in Go geschrieben, Rollup in JavaScript.
00:05:40Das bedeutet, der Production-Build
00:05:41ist eigentlich immer noch recht langsam im Vergleich zu,
00:05:43sagen wir mal, reinen Rust-Bundlern wie Rspack.
00:05:47Und beim Dev-Server haben esbuild und Rollup
00:05:52unterschiedliche Plugin-Systeme, richtig?
00:05:55Wir können in der Entwicklung nicht dieselben Plugins
00:05:57auf die Dependencies anwenden,
00:05:59die aber beim Production-Build
00:06:01auf die Dependencies angewendet werden.
00:06:03Und dann gibt es subtile Unterschiede im Verhalten.
00:06:07Wenn man einen Mix aus ESM- und CJS-Graphen hat,
00:06:10handhaben esbuild und Rollup das leicht anders.
00:06:13Es gibt Unterschiede beim Tree-Shaking.
00:06:15Obwohl beide einen guten Job machen,
00:06:18patchen wir all diese Inkonsistenzen
00:06:22und so weiter irgendwie zurecht.
00:06:22Wir haben es zum Laufen gebracht, aber tief im Inneren wissen wir:
00:06:25Es sind zwei verschiedene Dinge, die wir irgendwie
00:06:29zusammengeschustert haben, oder?
00:06:31Um also A: den Production-Build schneller zu machen
00:06:35und B: Dev und Produktion konsistenter zu gestalten,
00:06:40ist es am besten, einen Bundler zu haben,
00:06:42die beides macht, richtig?
00:06:44Das Problem ist: esbuild ist schnell,
00:06:47aber nicht besonders erweiterbar.
00:06:50Die Codebasis ist komplett in Go.
00:06:54Evan Wallace, der Autor von esbuild,
00:06:57ist offensichtlich ein genialer Tüftler.
00:06:59Er hat esbuild extrem schnell gemacht,
00:07:02aber es ist für andere nicht gerade einfach," : "aber es ist für andere nicht gerade einfach,
00:07:05es zu erweitern, zu forken
00:07:07oder eine eigene Ebene darauf aufzubauen.
00:07:10Das ist nicht leicht, oder?
00:07:12Außerdem ist es schwer, Evan Wallace
00:07:15von Dingen zu überzeugen, die er nicht will,
00:07:17weil er kein Geld braucht und es ihm egal ist.
00:07:21Also dachten wir: Okay, und was ist mit Rollup?
00:07:27Können wir Rollup schneller machen?
00:07:28Es gab da einige Experimente,
00:07:30aber im Grunde ist Rollup in JavaScript geschrieben," : "aber im Grunde ist Rollup in JavaScript geschrieben,
00:07:33und JavaScript bedeutet Single-Threaded.
00:07:36Wir haben Dinge wie Worker-Pools und Plugins in Workern versucht.
00:07:41Der Maintainer von Rollup versuchte, einen Rust-Parser,
00:07:47den SWC-Parser, in Rollup einzubauen.
00:07:50Das hat die Performance nicht spürbar verbessert,
00:07:54denn wenn man ein gemischtes Rust- und JS-System hat,
00:07:57gibt es immer Kosten für die Datenübergabe.
00:07:59Man schiebt riesige Strings hin und her.
00:08:02Wenn man den Speicher klonen muss, wird es noch langsamer.
00:08:05Es stellte sich heraus, dass der reine Leistungsschub durch Rust,
00:08:09wenn man nur den Rust-Parser hat,
00:08:12aber alles andere in JavaScript bleibt,
00:08:13durch die Kosten der Datenübertragung wieder aufgefressen wird.
00:08:16Am Ende war die Performance fast identisch, oder?
00:08:19Wir erkannten also: Rollup drastisch schneller zu machen,
00:08:23ist technisch nicht wirklich machbar.
00:08:26Die einzige Option ist ein Rewrite,
00:08:30einen Bundler neu zu schreiben, der quasi
00:08:33perfekt für Vite designt ist und rasend schnell sein muss.
00:08:37Damit begann die Suche nach dem: Okay,
00:08:40was sollen wir tun?" : "was sollen wir tun?
00:08:42Wir beschlossen also im Wesentlichen,
00:08:44ursprünglich war die Idee, Rollup in Rust zu forken.
00:08:48Nicht forken, portieren, richtig?
00:08:49Wir wollten Rollup nach Rust portieren.
00:08:51Deshalb heißt das Projekt auch Rolldown." : "Deshalb heißt das Projekt auch Rolldown.
00:08:53Also Rollup, Rolldown.
00:08:54Es fing als direkte Portierung an,
00:08:58aber wir merkten schnell, dass in JavaScript geschriebener Code
00:09:02nicht so einfach direkt nach Rust zu übertragen ist,
00:09:06weil JavaScript sehr dynamisch ist.
00:09:08Es ist eine dynamische Sprache, oder?
00:09:11Selbst wenn man TypeScript nutzt,
00:09:13kann man Dinge immer noch nach Belieben verändern.
00:09:16Rust ist beim Speicher extrem streng.
00:09:19Es achtet strikt auf Lebenszyklen, Ownership usw.
00:09:23Man muss die Dinge also ganz anders strukturieren
00:09:25als in JavaScript.
00:09:27Es wird also nie ein einfacher Weg sein,
00:09:29vorhandenen JavaScript-Code einfach
00:09:31in eine Sprache wie Rust zu portieren.
00:09:33Es ist praktisch ein kompletter Rewrite.
00:09:35Und am Ende wollten wir tatsächlich
00:09:37das Beste aus beiden Welten haben, oder?
00:09:42Rollup an sich hat einen ziemlich schlanken Kern.
00:09:45Wenn man Rollup also
00:09:47in ein produktionsbereites Preset verwandeln will,
00:09:49ist das eigentlich ziemlich aufwendig,
00:09:51da man Dinge wie das Node-Resolver-Plugin braucht –
00:09:54das Auflösen von Node-Modulen ist kein eingebautes Feature.
00:09:56Das muss per Plugin hinzugefügt werden.
00:09:58Man braucht das CommonJS-Plugin für CommonJS-Module,
00:10:03weil der Rollup-Kern rein auf ESM basiert.
00:10:06Und dann muss man einen Haufen Plugins hinzufügen,
00:10:10wie Define, Inject, Replace.
00:10:14Viele dieser Features sind in esbuild eingebaut,
00:10:17erfordern in Rollup aber Plugins.
00:10:20Was noch schlimmer ist: Die meisten dieser Plugins in der JS-Welt
00:10:25sind als extra AST-Parse-Transform-Codegen-Schritt implementiert.
00:10:30Jedes Plugin macht also das komplette Programm:
00:10:33Code vom vorherigen Plugin nehmen,
00:10:36erneut parsen, transformieren,
00:10:38neuen Code und neue Source-Maps generieren.
00:10:41Und dann muss man all die Source-Maps wieder zusammenführen.
00:10:43Deshalb werden JavaScript-Buildsysteme immer langsamer,
00:10:46weil jedes Plugin diesen Vorgang immer wiederholt.
00:10:49Wir sagten uns: Okay, das muss alles fest eingebaut sein." : "Wir sagten uns: Okay, das muss alles fest eingebaut sein.
00:10:53So landeten wir beim Umfang von esbuild,
00:10:56aber der API-Struktur von Rollup – und das ist Rolldown.
00:11:01Aber um Rolldown zu bauen, dachten wir:
00:11:03Wir brauchen einen Parser, all die Transforms, richtig?
00:11:07Wir brauchen einen Minifier, einen Resolver.
00:11:10Wie bekommen wir das?
00:11:12Und genau hier kommt OXC ins Spiel.
00:11:14OXC ist eine Sammlung von Low-Level-Sprachtools,
00:11:17die einem all das bietet.
00:11:20Der Autor von OXC arbeitete damals bei ByteDance,
00:11:25und ich hatte das Projekt schon lange im Auge.
00:11:28Borshin, der Autor von OXC,
00:11:30ist jetzt unser VP of Engineering bei Voice Zero.
00:11:33Er kam nicht sofort zur Firma, als ich sie gründete.
00:11:36Ich versuchte, ihn zum Mitmachen zu bewegen, aber er meinte:
00:11:38Ich weiß nicht so recht...
00:11:39Aber wir fingen trotzdem an, Rolldown auf OXC aufzubauen.
00:11:44Wir dachten uns: Das ist einfach gutes Zeug.
00:11:45Denn ich war überzeugt,
00:11:47weil ich mir alle verfügbaren Optionen angesehen hatte.
00:11:51Ich wollte etwas Komponierbares.
00:11:54Ich wollte, dass jeder Teil der Toolchain
00:11:57einzeln als Crates nutzbar ist.
00:12:00Und es sollte extrem schnell sein, oder?
00:12:03Also verglichen wir OXC mit SWC.
00:12:06Der OXC-Parser ist etwa dreimal schneller
00:12:09als der SWC-Parser, obwohl beide in Rust geschrieben sind,
00:12:12weil es viele Design-Entscheidungen
00:12:15und technische Details auf niedriger Ebene gibt,
00:12:18die zu diesem Performance-Unterschied führen.
00:12:20Die Hauptsache ist, dass Borshin besessen davon war,
00:12:24Parser- und Linking-Performance zu optimieren,
00:12:27schon bevor er zur Firma kam.
00:12:30Zum Beispiel nutzt OXC
00:12:32etwas namens Arena Allocator,
00:12:34der die gesamte Speicherallokation für den AST
00:12:39in einem zusammenhängenden Speicherblock ablegt.
00:12:41Er reserviert einfach einen großen Block
00:12:43und packt den AST direkt dort hinein.
00:12:45Dadurch geht das Freigeben des Speichers viel schneller.
00:12:50Es ermöglichte uns auch interessante Dinge,
00:12:53wie die schnellen JS-Plugins in OXLint,
00:12:57da uns der konsistente Speicher erlaubt,
00:12:59den gesamten Block an JavaScript zu übergeben,
00:13:01ohne ihn zu klonen, und ihn dann auf der JS-Seite zu deserialisieren.
00:13:05Das bringt viele Vorteile.
00:13:06Als ich mir das Projekt damals ansah,
00:13:10war ich wirklich beeindruckt,
00:13:10und wir beschlossen, Rolldown darauf aufzubauen
00:13:13und schließlich Borshin zu überzeugen, beizutreten.
00:13:16Der Fokus der Firma ist jetzt im Grunde:
00:13:21Wir haben diesen vertikalen Rust-Stack,
00:13:24der ganz unten beim Parser anfängt.
00:13:26Er reicht vom Bundling für Vite
00:13:29bis hin zu Linter, Formatter und Test-Runner.
00:13:33Wir haben also eine komplette Toolchain.
00:13:34Und was wir als Nächstes tun –
00:13:37tatsächlich arbeiten wir schon eine Weile daran –
00:13:40ist, all diese Dinge in ein stimmiges Paket zu schnüren,
00:13:43damit man nicht fünf verschiedene Sachen installieren muss,
00:13:47nur um eine Basis-App zum Laufen zu bringen.
00:13:50Man braucht dann auch nicht mehr
00:13:51sechs oder sieben verschiedene Konfigurationsdateien.
00:13:55Wir packen alles in eine Config-Datei,
00:13:57und es ist garantiert, dass sie zusammenarbeiten,
00:13:59weil sie alle auf demselben Parser basieren,
00:14:02derselben Pipeline und demselben Resolver.
00:14:05Es wird also keine bösen Überraschungen geben.
00:14:07Wenn man zum Beispiel Webpack und Jest nutzt,
00:14:10muss man deren Resolution-Logik separat konfigurieren,
00:14:14weil sie einfach nicht dasselbe System nutzen.
00:14:16Die Vision ist also wirklich:
00:14:19Lass uns einen vertikalen Stack bauen,
00:14:22der überall konsistent funktioniert.
00:14:25Die Dev-Story und Experience so einfach
00:14:29und schnell wie möglich machen, oder?
00:14:30Performance ist ein riesiges Thema.
00:14:32Ich habe das fast als gegeben vorausgesetzt,
00:14:34aber ihr habt wahrscheinlich Tweets gesehen, dass Rolldown
00:14:39etwa 20-mal schneller ist als Rollup.
00:14:43OXLint ist etwa 50- bis 100-mal schneller als ESLint.
00:14:47OXFormat ist 30- bis 40-mal schneller als Prettier.
00:14:51Unser Ziel ist es, das alles kompatibel zu machen,
00:14:57damit man ohne große Refactorings umsteigen kann,
00:15:00aber diese enormen Performance-Schübe erhält.
00:15:04Dein Test-Loop, dein Lint-Check
00:15:08und alles andere wird einfach viel schneller und reibungsloser.
00:15:12Und ja, das würde den Leuten ermöglichen,
00:15:15Apps schneller zu bauen.
00:15:17- Ich liebe es, wie schnell das eskaliert –
00:15:20von "wir brauchen ein Build-Tool für Vue" zu
00:15:22"oh, jetzt will ich diesen Teil verbessern"
00:15:24und "jetzt will ich das hier optimieren".
00:15:25Und ja, wie du sagtest, ihr besitzt wirklich
00:15:27den gesamten vertikalen Stack.
00:15:29Das ist sehr beeindruckend und es ist verdammt schnell.
00:15:32Ich habe den Jungs vorhin schon erzählt,
00:15:33dass wir in einem meiner alten Jobs
00:15:35ein Legacy-Projekt übernommen haben,
00:15:37das Webpack nutzte und 50 Minuten zum Builden brauchte.
00:15:40Ich hatte keine Ahnung, was da schiefging,
00:15:42aber das Erste, was ich sagte, war:
00:15:43Wir müssen das sofort auf Vite umstellen.
00:15:46Denn wenn man nur CSS änderte,
00:15:47musste man zwei Minuten warten,
00:15:49bis alles neu gebaut war.
00:15:49Und ich dachte: Das geht so nicht.
00:15:52Wir brauchen Hot Module Replacement.
00:15:54Wenn ich die Datei speichere, muss die Änderung da sein.
00:15:57Vite hat da definitiv geholfen.
00:15:59Der Fortschritt und die Geschwindigkeit,
00:16:02mit der Vite abgehoben ist, sind super beeindruckend.
00:16:05Ich habe gesehen, dass es so 200 Millionen
00:16:07NPM-Downloads im Monat hat, oder so was Verrücktes.
00:16:09Es ist –
00:16:10- Ja, wir haben neulich die 50 Millionen pro Woche geknackt.
00:16:13- Wahnsinn.
00:16:15- Ich musste gerade an diese 50 Millionen denken.
00:16:19Da ist wahrscheinlich ein bisschen Inflation dabei,
00:16:21durch diese ganzen KI-generierten Apps.
00:16:23Das sind oft nur Wegwerf-Apps zum Ausprobieren.
00:16:26Trotzdem zeigt es, dass viele Leute
00:16:29oder wahrscheinlich viele KI-Agenten es nutzen.
00:16:33- Das Engineering-Team bei BetterStack
00:16:34ist übrigens ein riesiger Fan von Vite.
00:16:36Die nutzen Rails im Backend und Vite im Frontend.
00:16:40Sie haben ein paar Fragen, die ich im Laufe des
00:16:42Podcasts stellen werde, wenn es gerade passt.
00:16:46Aber du hast das Bündeln erwähnt,
00:16:48und eine ihrer Fragen war:
00:16:49Da sie Import-Maps in Rails nutzen,
00:16:52wo siehst du die Zukunft des Bündelns?
00:16:54Denn mit Import-Maps muss man ja
00:16:56gar nicht mehr so viel bündeln.
00:16:57Wohin geht die Reise deiner Meinung nach?
00:17:00- Ich habe dazu tatsächlich eine eigene Seite
00:17:02in der Dokumentation von Rolldown.
00:17:04Der Titel lautet:
00:17:07"Warum brauchen wir immer noch Bundler?"
00:17:10- Wirst du das zufällig oft gefragt?
00:17:13- Ja, ich meine, DHH ist ja ein großer Verfechter
00:17:16von "No Bundle, No Build".
00:17:18Da muss man natürlich hinhören.
00:17:20Import-Maps funktionieren bis zu einem gewissen Punkt,
00:17:24aber das Konzept des Unbundled-Modus
00:17:29funktioniert generell nur bis zu einer bestimmten Größe.
00:17:35Wenn deine App weniger als tausend Module hat,
00:17:39lädt dein gesamter Modulgraph wahrscheinlich
00:17:41innerhalb weniger hundert Millisekunden,
00:17:43was völlig okay ist.
00:17:45Und wenn du weißt, dass du in diesem Rahmen bleibst,
00:17:48ist das eigentlich super.
00:17:50Es ist standardmäßig "lazy",
00:17:53was bedeutet, wenn du eine große App hast,
00:17:56bei der die einzelnen Seiten voneinander getrennt sind,
00:17:58hast du kleine Teil-Graphen,
00:18:00und das funktioniert ordentlich.
00:18:01Deshalb klappt Vite in der Entwicklung auch so gut.
00:18:05Aber es ist kein Allheilmittel,
00:18:07denn wir haben bei Vite selbst gemerkt –
00:18:09und das ist der Grund, warum wir an etwas
00:18:12namens "Full Bundle Mode" in Rolldown arbeiten –
00:18:15dass der Unbundled-Modus seine Grenzen hat.
00:18:18Das Nadelöhr ist wirklich die Anzahl der Module.
00:18:21Es gibt sehr viele Apps,
00:18:25die tausende und abertausende Module
00:18:29während der Entwicklung laden, richtig?
00:18:32Man lädt vielleicht 3000 Module,
00:18:33und das bringt den Browser zum Ersticken.
00:18:36Der Flaschenhals liegt auf der Netzwerkebene,
00:18:38denn mit nativem ESM
00:18:40schickst du für jedes einzelne Modul einen HTTP-Request.
00:18:44Und wenn du einen tiefen Import-Graphen hast,
00:18:46muss der Browser erst das erste Modul laden,
00:18:49feststellen: "Oh, ich brauche diese weiteren Module",
00:18:52und die dann abrufen.
00:18:53Und dann die nächsten –
00:18:54man muss den ganzen Graphen abarbeiten,
00:18:57bevor man das erste Modul überhaupt ausführen kann.
00:19:00Bei einer schlechten Verbindung
00:19:04braucht man zig Netzwerk-Runden,
00:19:06bevor überhaupt das Erste gerendert wird.
00:19:09Und bei tausenden Modulen
00:19:13verstärkt das Netzwerk dieses Problem massiv.
00:19:17Sogar lokal im Vite-Dev-Server
00:19:20dauert es bei mehr als 3000 Modulen
00:19:23schon mal ein, zwei Sekunden, um sie lokal zu laden.
00:19:27Stell dir vor, was das in der Produktion
00:19:29über das Internet bedeuten würde, oder?
00:19:31Das will man wirklich nicht, denn wenn man es bündelt,
00:19:35dauert es vielleicht 100 Millisekunden, richtig?
00:19:38Das ist quasi eine geschenkte Optimierung,
00:19:40die man ab einem gewissen Punkt
00:19:41immer mitnehmen sollte.
00:19:45Das Hauptargument gegen Bundling
00:19:47und Build-Tools ist oft einfach, dass die Leute es satt haben,
00:19:52die Tools zu konfigurieren, oder?
00:19:55Sie hatten wahrscheinlich Bugs
00:19:56oder Config-Probleme, die sie nicht lösen konnten.
00:20:01Weil Webpack es so kompliziert gemacht hat,
00:20:04denkt sich jeder:
00:20:06"Oh, den Bundler zu konfigurieren
00:20:08ist nichts für mich, darauf habe ich keine Lust."
00:20:11Die Leute haben also eine Abneigung entwickelt –
00:20:14sobald sie "Build-Schritt" hören,
00:20:16denken sie: "Das ist schlecht, das will ich vermeiden."
00:20:19Was wir mit unseren Tools
00:20:22erreichen wollen, ist Folgendes:
00:20:24Wir wollen diese Konzepte so einfach machen –
00:20:28und es wird nie völlig simpel sein
00:20:32für riesige, komplexe Apps, klar.
00:20:34Aber für eine neue App soll es einfach genug sein,
00:20:37dass man nicht viel darüber nachdenken muss,
00:20:41wenn die App nicht übermäßig kompliziert ist.
00:20:45Man sollte einfach sagen können: "Okay, start die App,
00:20:48sie nutzt Vite und alles wird super."
00:20:50Ich weiß, dass es in der Community Projekte gibt,
00:20:55wie Ruby Vite oder Vite Rails,
00:20:59die Vite in Rails sehr gut nutzbar machen.
00:21:05Das "No Build"-Setup hat seine Vorzüge, klar.
00:21:12Man fühlt sich wohl, weil man weiß,
00:21:14dass man viele Abhängigkeiten vermeidet,
00:21:17die vielleicht Dinge kaputtmachen könnten.
00:21:20Ich glaube, manche haben auch
00:21:23das Vertrauen in Build-Systeme verloren:
00:21:26"Es geht sowieso immer irgendwas schief."
00:21:29"Der Build bricht ab, wenn ich eine Dependency update."
00:21:33Das alles zu vermeiden, ist natürlich verlockend.
00:21:36Aber am Ende des Tages,
00:21:37wenn die Technik gut und stabil genug ist,
00:21:41willst du immer die bestmögliche UX für deine Endnutzer.
00:21:45Vollständig ungebündelt zu arbeiten bedeutet,
00:21:48dass du dich auf eine sehr begrenzte App-Größe festlegst." : "dass du dich auf eine sehr begrenzte App-Größe festlegst.
00:21:52Du musst dich auch ständig um Optimierung sorgen,
00:21:54weil du immer überlegen musst:
00:21:57"Importiere ich versehentlich zu viel
00:22:01auf einer bestimmten Seite?"
00:22:03"Wie cache ich meine Module geschickt?"
00:22:06Ich glaube, selbst mit ungebündeltem Rails
00:22:08braucht man noch so etwas wie einen Pre-Process-Schritt,
00:22:11um die Module zu stempeln, damit sie richtig gecacht werden.
00:22:15Man muss sich also zwangsläufig
00:22:18mit Optimierung befassen, damit es funktioniert.
00:22:21Ich würde sagen, es klappt für eine
00:22:24beachtliche Zahl an Anwendungsfällen, aber eben" : "beachtliche Zahl an Anwendungsfällen, aber eben
00:22:29nicht für alle.
00:22:31Manche Leute bauen nun mal riesige Apps,
00:22:35die Unmengen an Features haben.
00:22:37Man kann sie nicht einfach zwingen, ungebündelt zu arbeiten
00:22:39und sie damit in eine Sackgasse
00:22:42ohne Optimierungsmöglichkeiten manövrieren.
00:22:45- Für diejenigen, die noch nicht so vertraut damit sind:
00:22:49Wie unterscheidet sich Vite von Vite+?
00:22:54Und was haben die Leute davon?
00:22:57- Bei Vite+ durchlaufen wir gerade eine Art
00:23:02kleinen Pivot, was genau es aktuell sein soll.
00:23:06Die Idee ist: Wenn du gerade erst mit
00:23:11JavaScript-Entwicklung anfängst,
00:23:14völlig neu in dem Bereich bist
00:23:17und einen Rechner hast, auf dem noch nie was installiert war.
00:23:21Wie kommst du von Null zu einer funktionierenden App
00:23:25mit HMR und all den Best Practices,
00:23:28Linting, Formatting und Testing, schon fertig für dich eingerichtet?
00:23:33Aktuell muss man da extrem viel lernen.
00:23:36Das Erste, was man wissen muss, ist:
00:23:38Was ist Node.js?
00:23:39Wie installiere ich das?
00:23:40Was ist ein Node Version Manager?
00:23:42Welchen Package Manager soll ich nutzen?
00:23:44Welches Build-Tool?
00:23:45Welchen Linter?
00:23:47Man muss all diese Fragen beantworten.
00:23:49Wir wollen all diese Fragen eliminieren.
00:23:50Wir geben dir diesen vorgefertigten Startpunkt,
00:23:52bei dem du,
00:23:54nicht mal Node.js selbst installieren musst.
00:23:57Wir experimentieren mit einer neuen Arbeitsweise
00:23:59für Vite+ – einfach über curl:
00:24:03"[https://vplus.dev](https://www.google.com/search?q=https://vplus.dev) install" in die Bash pipen.
00:24:08Dann "vp new", und du hast ein neues Projekt,
00:24:15dann "vp dev", und schon
00:24:17hast du eine komplette Suite für dich eingerichtet.
00:24:21Du hast Linter, Formatter,
00:24:25Test-Runner und Bundler. Du kannst es auch
00:24:28für die Erstellung von Monorepos nutzen.
00:24:31Es bündelt Bibliotheken.
00:24:32Wir planen, Dinge wie lint-staged
00:24:39und Changelog-Management fest einzubauen.
00:24:41Wenn du an großen Monorepo-Libraries arbeitest –
00:24:44und dann gibt es noch "vp run",
00:24:49einen Runner, ähnlich wie "pnpm run",
00:24:52aber etwas ausgefeilter,
00:24:57ähnlich wie Nx, wo das Tool selbst
00:24:59die richtige Reihenfolge der Tasks erkennt
00:25:03und diese auch clever cacht.
00:25:04Das ist aber alles optional (opt-in).
00:25:07Es ist also ein ganzes Paket, aber
00:25:11wenn du diesen Zusatzkram nicht brauchst,
00:25:13kannst du es wie das normale Vite nutzen, okay?
00:25:17Deine Dev-Experience wird genau so sein,
00:25:18wie Vite heute ist.
00:25:20Aber wenn du weiter gehen willst,
00:25:24bis hin zum produktionsreifen Monorepo
00:25:27auf Enterprise-Niveau, ist es den ganzen Weg für dich da.
00:25:31Und da es auf all
00:25:33diesen bewährten Technologien basiert,
00:25:35die Leute bereits in solchen Situationen nutzen.
00:25:39Das ist es, was wir bieten wollen.
00:25:44Wir stellen gerade viele bestehende Nutzer
00:25:47auf unsere Open-Source-Angebote um –
00:25:48Leute migrieren von Webpack zu Vite,
00:25:52sie migrieren von ESLint zu OXLint.
00:25:54Vite+ soll die Antwort auf die Frage sein:
00:25:57"Was mache ich,
00:26:00wenn ich gerade erst mit JavaScript anfange?"
00:26:02"Was ist der schnellste und einfachste Weg?"
00:26:05Ich will diese Frage beantworten
00:26:07und es auch fit für die Zusammenarbeit mit KI machen.
00:26:11- Ist das das Ziel der Firma?
00:26:14Viele Leute erschrecken, wenn sie hören,
00:26:15dass eine Firma hinter Open-Source-Projekten steht,
00:26:17weil man anfangen könnte, Features hinter eine Paywall zu packen.
00:26:20Aber ist es eher das Ziel, dass man,
00:26:23das, was Vite+ macht, auch immer selbst machen kann?
00:26:25Es ist nur eben viel Konfigurationsarbeit,
00:26:26und Vite+ ist quasi die bequeme Lösung,
00:26:29die alles in einem bündelt, wie du sagtest.
00:26:31Ihr würdet also nie ein Feature kostenpflichtig machen.
00:26:34- Ja, wir haben die Idee hinter
00:26:37der Lizenzierung von Vite+ ja schon mal angedeutet.
00:26:39Wir sagten: Okay, wenn dein Unternehmen
00:26:41eine gewisse Größe überschreitet, musst du zahlen.
00:26:44Diese Überlegung hat sich weiterentwickelt,
00:26:46da wir mit vielen interessierten Firmen gesprochen haben.
00:26:50Wir suchen die richtige Balance: Wie bringen wir es
00:26:53in die Hände von möglichst vielen Menschen," : "in die Hände von möglichst vielen Menschen,
00:26:56um Mehrwert zu schaffen, während wir selbst Wert schöpfen,
00:27:00um nachhaltig arbeiten zu können, richtig?
00:27:02Ich denke, wir werden diese Schwelle weit nach oben verschieben.
00:27:07Es wird also nur eine sehr kleine Gruppe von Firmen
00:27:11tatsächlich dafür bezahlen müssen.
00:27:14Die Mehrheit der Nutzer soll es kostenlos genießen können.
00:27:17Außerdem arbeiten wir
00:27:20an Ideen, die eher in Richtung Service gehen,
00:27:25statt einfach nur Features zu bezahlen.
00:27:27Also ein Service, der mit Vite+ einhergeht,
00:27:31der quasi die Codequalität verbessert,
00:27:35sie überwacht
00:27:37und dir Tipps oder Ideen gibt,
00:27:39um bestimmte Dinge zu optimieren.
00:27:41Denn es gibt eine Menge Expertenwissen,
00:27:44das wir jetzt durch KI-Agenten skalierbar machen können.
00:27:48In diese Richtung forschen wir gerade.
00:27:51- Okay. Ich habe mich auch gefragt,
00:27:53da Vite+ ja alles so bequem macht,
00:27:56glaubst du, dass KI das auch mit bestehenden Lösungen kann?
00:28:00Oder hast du die Erfahrung gemacht,
00:28:02dass wenn man die KI bittet, Formatter,
00:28:05Linter, Build und so weiter zusammenzubauen,
00:28:07sie sich auf alte Technik verlässt
00:28:09wegen ihrer Trainingsdaten und nur Chaos anrichtet?
00:28:13- Wir sehen viele KI-generierte Apps,
00:28:17die zum Beispiel immer noch Vite 4 nutzen, oder?
00:28:20Denn wenn wir eine neue Version veröffentlichen
00:28:26und neue Features ausliefern, dauert es, bis die Modelle
00:28:29mit diesen Daten trainiert wurden.
00:28:31Modelle hinken den neuesten Trends
00:28:34und Technologien immer hinterher. Deshalb wollen wir zum Beispiel,
00:28:37wenn wir eine neue Version von Vite+ rausbringen,
00:28:41ihr direkt ihre eigenen
00:28:44Agent-Anweisungen und Skills mitgeben.
00:28:47Wenn du Vite+ updatest,
00:28:50patcht es automatisch die relevanten Stellen für deinen KI-Agenten
00:28:54und verknüpft die aktualisierten Skills
00:28:58in deinem NPM-Paket.
00:29:00Und dann gibt es auch noch die Möglichkeit,
00:29:05dass wir einen Prompt mitliefern, der dir sagt:
00:29:08"Wenn du von dieser auf jene Version upgraden willst,
00:29:10hilft dieser Prompt deinem Agenten, das reibungslos zu tun."
00:29:13Vieles davon muss
00:29:17von den Tool-Autoren selbst kommen, oder?
00:29:19Denn was uns aufgefallen ist:
00:29:22OXLint, OXFormat und Vitest
00:29:26werden in OpenDevin genutzt, richtig?
00:29:29Und OpenDevin ist eine wahnsinnige Codebasis." : "Und OpenDevin ist eine wahnsinnige Codebasis.
00:29:31Es sind etwa 54.000 Zeilen JavaScript,
00:29:34und die Entwicklung schreitet in irrem Tempo voran.
00:29:36Der Autor mergt einfach alles, ohne es zu lesen.
00:29:40Es passieren da viele Dinge,
00:29:43die einfach keinen Sinn ergeben.
00:29:45Wir schauen uns da zum Beispiel PRs an, die OXLint updaten
00:29:46oder OXLint erst einführen." : "oder OXLint erst einführen.
00:29:51Da werden dann Optionen halluziniert, die es gar nicht gibt.
00:29:54Und wir denken uns: "Warte mal, diese Option haben wir nicht,
00:29:57wir müssen..."
00:29:59Oder wenn die KI das Type-Checking macht," : "Oder wenn die KI das Type-Checking macht,
00:30:00biegt sie es sich einfach zurecht.
00:30:04"Okay, ich schalte diese Regel einfach ab,"
00:30:06"damit die Typen wieder passen."
00:30:07KI nimmt also Abkürzungen,
00:30:09wenn man ihr keine Leitplanken gibt, oder?
00:30:12Und was noch wichtiger ist: Peter,
00:30:15der Autor von OpenDevin,
00:30:18ist eigentlich kein TypeScript-Entwickler.
00:30:20Er hat sich TypeScript nur dafür ausgesucht.
00:30:22Er ist also kein Tooling-Experte.
00:30:25Er hat in diesem Bereich keine Erfahrung.
00:30:26Die KI hat ihm dabei geholfen.
00:30:29Aber wir als Autoren der Tools, die von der KI genutzt werden,
00:30:30merken eben genau, wo sie scheitert.
00:30:35Wir denken uns: "Wenn du so weitermaachst,
00:30:38ohne dass wir dich darauf hinweisen,
00:30:41wird dir dein Code in drei Monaten um die Ohren fliegen."
00:30:44Genau das ist der Mehrwert,
00:30:46den wir in der KI-Ära bieten können:
00:30:50Wie stellt man sicher, dass man schnell liefert,
00:30:54ohne Dinge kaputtzumachen?
00:30:58Wie kann man mit KI weiterhin schnell Features liefern?
00:30:59Denn die Geschwindigkeit, mit der Code
00:31:03produziert wird, steigt durch die Agenten massiv an, oder?
00:31:06Die Leute können Features viel schneller raushauen.
00:31:11Aber werden diese Features alle vernünftig geprüft?" : "Aber werden diese Features alle vernünftig geprüft?
00:31:14Wenn man 20 PRs am Tag mergt,
00:31:19ist die Codebasis dann noch
00:31:22so gut gepflegt, wie sie sein sollte?
00:31:25Die Code-Qualität ist da sehr volatil.
00:31:26Man muss also immer mal wieder innehalten,
00:31:30genau wie bei der Entwicklung durch Menschen, oder?
00:31:33Man liefert eine Zeit lang Features," : "Man liefert eine Zeit lang Features,
00:31:36muss dann aber mal stoppen und überlegen:
00:31:37"Okay, wir müssen hier mal aufräumen."
00:31:38"Wir müssen die technischen Schulden abbauen, die sich angesammelt haben."
00:31:40Mit KI-Agenten liefern wir jetzt viel schneller.
00:31:42Wir häufen aber auch viel schneller Schulden an, oder?
00:31:45Man muss die KI also auch nutzen, um diese Schulden wieder abzubauen.
00:31:49Das ist der Punkt,
00:31:53den viele übersehen
00:31:56und für den es dringend Lösungen braucht.
00:31:57- Ja, ich habe mir die OpenDevin-Codebasis mal angesehen,
00:32:00wie du sagtest, und es ist echt ein bisschen chaotisch.
00:32:03Es ist ein super Beispiel dafür, was passiert,
00:32:05wenn man die KI einfach von der Leine lässt
00:32:07und sie machen lässt, was sie will,
00:32:09ganz ohne Aufsicht.
00:32:11Es war lustig, das in den letzten Wochen
00:32:13im Internet zu verfolgen.
00:32:16Aber ich wollte auch fragen: In Hinblick auf die KI,
00:32:19änderst du die Art, wie du einen Formatter
00:32:22oder einen Linter baust, damit KI-Agenten sie besser nutzen können?
00:32:26Beeinflusst das die Zukunft?
00:32:29Oder hilft allein die Tatsache, dass du sie
00:32:31auf Geschwindigkeit getrimmt hast, schon in der KI-Ära?
00:32:34Denn wenn sie schnell sind, können KI-Agenten sie besser einbinden.
00:32:38- Das ist definitiv ein guter Gedanke,
00:32:40denn wir fangen gerade an, über dieses Problem nachzudenken.
00:32:45Der ursprüngliche Umfang dieser Linter
00:32:48und Formatter ist nämlich gewaltig,
00:32:50da wir versuchen, kompatibel
00:32:53mit ESLint und Prettier zu sein,
00:32:54die seit Jahren, ja fast einem Jahrzehnt, im Einsatz sind,
00:32:56wo die Leute all diese benutzerdefinierten Regeln
00:33:00und Legacy-Anwendungsfälle haben." : "und Legacy-Anwendungsfälle haben.
00:33:03Und wir versuchen, zu 100 % kompatibel damit zu sein." : "Und wir versuchen, zu 100 % kompatibel damit zu sein.
00:33:06Das ist eine Mammutaufgabe,
00:33:09die wir endlich gemeistert haben. Wir haben neulich
00:33:13die 100 % ESLint-Plugin-Kompatibilität erreicht.
00:33:17Wir bestehen alle Plugin-Tests von ESLint,
00:33:21und wir haben auch 100 % Konformität
00:33:23mit Prettier in unserem Formatter erreicht, oder?
00:33:25Diese beiden Meilensteine bedeuten:
00:33:28Wir können den Leuten jetzt guten Gewissens empfehlen,
00:33:31auf unsere Tools umzusteigen. Und was kommt als Nächstes?
00:33:34Das ist die entscheidende Frage.
00:33:38Wie müssen sich Linting und Formatting anpassen,
00:33:40wenn Agenten sie benutzen, richtig?
00:33:44An dieser Frage arbeiten wir hier gerade aktiv.
00:33:49Ja.
00:33:53- Also steht die Antwort darauf noch aus.
00:33:54Es entwickelt sich alles noch, ja.
00:33:57Die KI verändert so viel
00:33:59in der Coding-Welt, das ist spannend zu beobachten.
00:34:01- Nochmal zum Thema Vite+:
00:34:04Du hast es auf der ViteConf 2024 präsentiert
00:34:06und ein Feature namens "vite install" gezeigt.
00:34:10Meine Frage dazu: Gibt es dieses Feature noch?
00:34:14Und wie viel Überschneidung wird Vite+ haben
00:34:17mit so etwas wie Bun?
00:34:19- Gute Frage.
00:34:21Seit der ViteConf hat sich einiges geändert.
00:34:23Ich würde sagen, die finale
00:34:27öffentliche Version von Vite+ wird sich
00:34:30in gewissem Sinne wie Bun anfühlen, oder?
00:34:33Die Onboarding-Experience, wie gesagt:
00:34:38Wenn du einen neuen Rechner hast
00:34:41und so schnell wie möglich eine Web-App bauen willst.
00:34:43Du nutzt einfach curl für die Scripte
00:34:45und bekommst eine globale Binary namens "vp". Dann,
00:34:46wenn du in einem Projekt bist:
00:34:51Falls du eine ".node-version"-Datei hast
00:34:56und ein "packageManager"-Feld in der "package.json",
00:35:02was ja üblich ist, um die Umgebung festzulegen,
00:35:04also die JS-Umgebung, in der du arbeitest.
00:35:06Wenn du dann "vp run build" sagst,
00:35:11nutzt es automatisch –
00:35:15sogar wenn du nur "vp build" oder "vp lint" sagst,
00:35:20also alles, was JavaScript ausführt –
00:35:22automatisch die richtige Node-Version
00:35:26und den richtigen Package Manager.
00:35:28Selbst wenn du in dem Projekt
00:35:31Vite+ gar nicht direkt nutzt,
00:35:36kannst du – solange du diese
00:35:40üblichen Standardformate verwendest –
00:35:44Vite+ als Ersatz für NVM nehmen.
00:35:45Du kannst es als Ersatz für Corepack nehmen.
00:35:48Du hörst einfach auf, über Versionen nachzudenken.
00:35:52Die Idee ist: Wenn du deinen Workflow ausführst,
00:35:55hörst du auch auf mit "npm run".
00:35:59Du nimmst "vp run".
00:36:02Die Idee dahinter: Bei einem "vp run"
00:36:05wird immer die richtige Node-Version
00:36:06und der richtige Package Manager genutzt.
00:36:10Und das Richtige wird getan.
00:36:14Das "install" bedeutet dann:
00:36:16Wir haben erst mal keinen eigenen Package Manager, okay?
00:36:19Es ist eher ein Corepack-Äquivalent.
00:36:24Ich weiß nicht, ob du das Paket "ni" kennst,
00:36:27das ist von Anthony Fu.
00:36:30"ni" erkennt automatisch,
00:36:34welchen Package Manager man nutzen muss,
00:36:36egal ob man gerade installiert, deinstalliert
00:36:41oder einen Run-Befehl ausführt, richtig?
00:36:45"vite install" ist im Grunde genau das,
00:36:48plus die Verwaltung des Package Managers selbst.
00:36:49Das ist das, was Corepack macht, oder?
00:36:51Selbst wenn du sonst nichts installiert hast,
00:36:56gehst du in ein Projekt, und in der "package.json" steht,
00:36:58dass pnpm in einer
00:37:01bestimmten Version gebraucht wird.
00:37:03Wenn du "vp install" ausführst, wird automatisch geprüft,
00:37:07ob diese pnpm-Version installiert ist." : "ob diese pnpm-Version installiert ist.
00:37:08Falls nicht, wird sie einfach installiert
00:37:12und der Prozess mit "pnpm install" gestartet.
00:37:14Wir wollen also mehr lösen
00:37:16als nur Linting und Formatting.
00:37:20Es geht um all die alltäglichen Dinge,
00:37:25die man im JS-Workflow braucht, oder?
00:37:31Wir wollen diese typischen Probleme aus der Welt schaffen,
00:37:34damit ein Anfänger gar nicht erst darüber nachgrübeln muss.
00:37:36Wenn du zum ersten Mal ein Projekt erstellst,
00:37:40nutzen wir die aktuellste LTS von Node und empfehlen pnpm.
00:37:43Diese Infos werden auch fest in dein Projekt geschrieben.
00:37:45Wenn du das nächste Mal an das Projekt gehst,
00:37:50wird immer die richtige Kombination von Tools genutzt.
00:37:53- Warum empfiehlst du pnpm, wenn ich fragen darf?
00:37:55- Es bietet einfach die beste Balance aus Features,
00:37:59Korrektheit, Effizienz beim Speicherplatz und Speed.
00:38:02Es hat guten Workspace-Support, wie etwa Catalogs.
00:38:06Wenn wir alle
00:38:10Workspace-Features vergleichen,
00:38:15finden wir, dass pnpm immer noch das beste Paket bietet.
00:38:19Wir wissen, dass Bun wahnsinnig schnell ist,
00:38:21aber pnpm ist für viele von uns schnell genug.
00:38:25Außerdem schließen wir nicht aus,
00:38:29dass wir Bun künftig in unserer Runtime
00:38:33und bei der Versionsverwaltung unterstützen, okay?
00:38:35Man kann dann sagen: "Ich will Bun nutzen",
00:38:37und wir lassen die Dinge einfach mit Bun laufen.
00:38:40- Zu Vite 6: Du meintest doch, es sollte
00:38:42nach dem chinesischen Neujahrsfest erscheinen, oder?
00:38:44- Ja.
00:38:49- Worauf konzentriert ihr euch in der Beta noch besonders,
00:38:52bevor ihr es offiziell veröffentlicht?
00:38:54- Eigentlich nur noch auf Stabilität.
00:38:58Ecosystem CI –
00:39:00wir haben ein riesiges Ecosystem-CI-System,
00:39:04wo wir Vite 6 mit Projekten testen, die davon abhängen.
00:39:06Vor Kurzem haben wir es geschafft,
00:39:10dass alle SvelteKit-Tests mit Vite 6 durchlaufen.
00:39:15Das ist ein großer Meilenstein für uns,
00:39:17denn Stabilität ist das A und O.
00:39:21Wenn man bedenkt:
00:39:24Wir tauschen gerade zwei Bundler
00:39:27gegen einen völlig neuen aus, den wir selbst gebaut haben.
00:39:28Es ist, als würde man bei einem fliegenden Flugzeug die Triebwerke tauschen
00:39:30und hoffen, dass es danach einfach ruhig weiterfliegt.
00:39:33Da kann man gar nicht vorsichtig genug sein.
00:39:36- Ich wollte vorhin schon fragen: Warum die Wahl auf Rust fiel?
00:39:40Lag es daran, dass Leute in deinem Team
00:39:43sich schon gut mit Rust auskannten?
00:39:46Ich sehe nämlich viele in der TypeScript-Welt,
00:39:48die Go bevorzugen, weil es wohl näher dran ist.
00:39:49Sogar das TypeScript-Team setzt für
00:39:51seinen Compiler wohl auf Go.
00:39:55- Ja, ich glaube, der Grund dafür,
00:39:57dass TypeScript nach Go portiert wird, ist wie gesagt:
00:39:58Go ist eine viel dankbarere Sprache für so eine Portierung," : "Go ist eine viel dankbarere Sprache für so eine Portierung,
00:40:02weil das mentale Modell viel ähnlicher ist.
00:40:04Ein großes Hindernis war für uns aber,
00:40:09dass Go nur mäßigen Support für WebAssembly bietet.
00:40:13Es erzeugt riesige WebAssembly-Binaries,
00:40:17und die Performance von WebAssembly
00:40:21ist bei Go im Vergleich zu Rust nicht so berauschend.
00:40:26Und bei Rust ist es so:
00:40:29Klar hat es viel mit verfügbaren Talenten zu tun,
00:40:32Leuten, die bereits leidenschaftlich
00:40:35im Ökosystem investiert sind.
00:40:39Als wir uns nach Grundlagen
00:40:41zum Aufbauen umsahen,
00:40:44gab es keinen Parser oder eine Toolchain,
00:40:46die so gut implementiert und so komponierbar war.
00:40:48OXC ist quasi darauf ausgelegt, dass man darauf aufbaut." : "OXC ist quasi darauf ausgelegt, dass man darauf aufbaut.
00:40:54Es sind diese Low-Level-Utilities.
00:40:59In der Go-Welt sehen wir nichts Vergleichbares.
00:41:04esbuild hat zwar seinen eigenen Parser und alles,
00:41:08aber es ist ein großes, monolithisches System.
00:41:11Man kann nicht einfach den Parser rausnehmen und nutzen.
00:41:14Zudem sind alle Features in esbuild,
00:41:18wie Define, Inject, Transforms, Minification,
00:41:23für die maximale Performance
00:41:25in nur drei AST-Durchläufen implementiert.
00:41:30Das heißt, in einem Durchlauf
00:41:33werden verschiedene Dinge vermischt:
00:41:36Hier ein bisschen Transformation,
00:41:37da ein Inject-Feature,
00:41:39dort eine Minification.
00:41:41Das ist für ein erweiterbares System nicht ideal.
00:41:42Wir wollen zum Beispiel
00:41:45mehr Transforms anbieten
00:41:51und den Leuten erlauben, diese an- und auszuschalten.
00:41:54Sie sollen auch ihre eigenen Transforms schreiben können.
00:41:57Wir wollen ein Linter-System, das
00:42:01klar geschichtet ist,
00:42:03damit auch mehr Leute gleichzeitig daran arbeiten können.
00:42:07Es liegt also viel an den verfügbaren Mitteln.
00:42:09Rust ist zudem extrem performant.
00:42:13Es ist zwar knifflig, gute Transforms in Rust zu schreiben.
00:42:16Wir mussten viel Zeit investieren,
00:42:22um eine gute Architektur
00:42:26für die Visitor- und Transformer-Pipeline zu finden,
00:42:28allein schon wegen der Memory-Ownership-Thematik –
00:42:31wenn man tief im Baum ist
00:42:34und etwas am Eltern-Baum ändern muss,
00:42:37wird es echt tricky, oder?
00:42:39Aber wir haben eine Lösung gefunden.
00:42:42In Go ist es leichter, aber wir wollten halt,
00:42:44dass unsere Tools auch
00:42:45nach WebAssembly kompilieren und im Browser laufen können.
00:42:49Rolldown kann im Browser laufen
00:42:51und das verdammt schnell.
00:42:53Klar, esbuild kann auch im Browser laufen,
00:42:57aber WebAssembly mit Rust ist einfach besser.
00:42:59- Die andere Frage, die ich mir stellte,
00:43:01da ihr ja viel mit Rust arbeitet:
00:43:05Wie nutzt das Team und du selbst KI?
00:43:07Du meintest ja vorhin schon, dass viele
00:43:09im Team KI-Tools nutzen.
00:43:12Findest du, dass KI gut ist für die Arbeit, die ihr macht?
00:43:14Ich finde, für Web-Dev oder das Bauen einer Website
00:43:16gibt es so viele Beispiele auf GitHub,
00:43:19dafür ist die KI super trainiert.
00:43:21Aber das, was ihr macht, ist ja auf einem viel
00:43:23tieferen technischen Level, oder zumindest sehr speziell.
00:43:25Hilft die KI da auch, oder schreibt ihr
00:43:28noch das meiste von Hand?
00:43:30- Sie ist definitiv hilfreich.
00:43:32a lot of manual coding?
00:43:34Das Feld verändert sich so rasend schnell.
00:43:38Letztes Jahr um diese Zeit war ich noch Skeptiker.
00:43:41Ich dachte: "Nee, hab's probiert, für mich klappt das nicht,
00:43:45dafür ist meine Arbeit zu Low-Level."
00:43:49Aber Borshin, der OXC leitet,
00:43:52ist wohl die Person in der Firma,
00:43:59die am tiefsten im KI-Thema steckt.
00:44:03Er fing an, total verrückte Experimente zu machen.
00:44:04Letzten Monat gab es eine Woche,
00:44:07da hat er 60 PRs mit KI rausgehauen,
00:44:11indem er einfach Agenten parallel laufen ließ.
00:44:13Und dann haben wir irre Sachen probiert,
00:44:16wie den Angular-Compiler nach Rust zu portieren –
00:44:19wir haben es der KI einfach hingeworfen, um zu sehen, ob es klappt.
00:44:24Und irgendwie funktioniert es.
00:44:27Vielleicht kommt in dieser Richtung künftig noch was von uns.
00:44:29Unsere Wahrnehmung dessen,
00:44:33was KI leisten kann, wird einfach alle paar Monate
00:44:39komplett auf den Kopf gestellt,
00:44:43wenn neue Modelle rauskommen,
00:44:46bessere Frameworks implementiert werden
00:44:48und neue Praktiken entstehen, wie der Plan-Modus
00:44:51oder das Schreiben eigener Agent-Anweisungen.
00:44:55Wenn man diese Kniffe anwendet, merkt man:
00:45:00Okay, es wird tatsächlich immer besser.
00:45:03Die Nutzung ist von Person zu Person verschieden, klar.
00:45:06Wir ermutigen jeden in der Firma,
00:45:08es so viel zu nutzen, wie er oder sie es für richtig hält.
00:45:13Wir geben ihnen ein monatliches Budget,
00:45:18damit sie Claude Pro oder Ähnliches nutzen können.
00:45:22Einige sind total happy damit
00:45:24und sagen das auch ganz offen." : "und sagen das auch ganz offen.
00:45:27Und sie liefern wirklich gute PRs ab, oder?
00:45:33Es hängt viel davon ab, wie gut man es bedienen kann.
00:45:36Ein Teil ist die reine Modell-Leistung,
00:45:40ein anderer das Tooling, das man drumherum nutzt.
00:45:45Die Tool-Ebene
00:45:49erinnert mich an die JavaScript-Frameworks von früher.
00:45:52Jeder bastelt an seiner eigenen Version.
00:45:54Im Grunde machen sie alle mehr oder weniger dasselbe.
00:45:57Vielleicht hat ein Tool ein paar andere Tricks auf Lager,
00:46:00aber ein paar Monate später machen es alle so, richtig?
00:46:03Das ist ein extrem kompetitives Feld, auch bei den Modellen.
00:46:08Alle paar Monate –
00:46:11jetzt kommt wohl bald Claude 4.
00:46:13DeepSeek bringt wohl auch bald ein neues Modell.
00:46:17Es wird einfach immer besser.
00:46:18Es ist klar, dass KI extrem fähig ist,
00:46:21wenn man sie richtig steuert.
00:46:23Aber genau dieses Steuern ist immer noch extrem wichtig.
00:46:26Man kann nicht erwarten, dass jemand ohne Rust-Kenntnisse
00:46:32mit der OXC-Codebasis arbeiten kann, selbst mit KI nicht.
00:46:34Man wüsste wahrscheinlich nicht mal, wie man richtig promptet, oder?
00:46:37Aber jemand, der sich schon gut in OXC auskennt
00:46:41und selbst ein fähiger Rust-Engineer ist, wird mit KI
00:46:45viel produktiver
00:46:50und kann Features schneller liefern, okay?
00:46:54Das ist so meine allgemeine Meinung dazu.
00:46:58Ich selbst bin wahrscheinlich derjenige,
00:47:00der am wenigsten Code mit KI produziert,
00:47:03viel weniger als die anderen Ingenieure in der Firma.
00:47:08Ich nutze sie eher zur Recherche und als Sparringspartner.
00:47:13- Es ist echt eine verrückte Welt,
00:47:16in die sich das Coding da entwickelt.
00:47:20Ich finde es fast schon schwer, am Ball zu bleiben –
00:47:25wie viele Sub-Agenten man nutzen soll,
00:47:27parallele Agenten, welche Markdown-Dateien man jetzt
00:47:29im Repo braucht.
00:47:32Es ändert sich ständig.
00:47:34Ich bin gespannt, wo wir da in der
00:47:37Zukunft landen werden.
00:47:38- Noch mal kurz zurück zu Vite.
00:47:40In Vite 6 habt ihr den Support für React Server Components eingeführt.
00:47:43Meiner Meinung nach waren React Server Components
00:47:43nicht der Riesenerfolg, den das Team erwartet hatte.
00:47:47Ich meine, es gibt Meta-Frameworks, die das nicht übernommen haben,
00:47:52wie TanStack.
00:47:54Und ich glaube, Remix ist sogar in eine ganz andere Richtung gegangen.
00:47:57Was hältst du von React Server Components,
00:48:00und warum sind sie deiner Meinung nach nicht so eingeschlagen wie erhofft?
00:48:01- Ja, ich war da schon immer sehr zurückhaltend
00:48:04oder besser gesagt vom ersten Tag an skeptisch.
00:48:07Deshalb haben wir auch nie darüber nachgedacht,
00:48:10etwas Ähnliches für Vue zu implementieren.
00:48:14Die entscheidende Frage ist doch: Welches Problem
00:48:17soll es eigentlich genau lösen?
00:48:20Und ich glaube, es wurde zu sehr gepusht.
00:48:23Man hat versucht, die Leute zu begeistern,
00:48:28und es als das Allheilmittel angepriesen.
00:48:30Dass es das Größte überhaupt sei,
00:48:35das jede Website schneller machen würde." : "das jede Website schneller machen würde.
00:48:38Als es dann da war, merkten die Leute: Okay,
00:48:40vielleicht sollte ich es nicht für alles benutzen.
00:48:42Es bringt nur in ganz bestimmten Fällen
00:48:44wirklich Vorteile.
00:48:48In anderen Fällen ist es einfach ein Haufen Kompromisse.
00:48:51Denn bei den Teilen, die auf dem Server liegen,
00:48:54muss jetzt jede Interaktion erst mal
00:48:56übers Netzwerk zum Server und zurück.
00:48:59Und das ist meiner Meinung nach ziemlich
00:49:04schlecht für eine Offline-First-Experience.
00:49:06Und die Hydration-Kosten wird man
00:49:08meiner Ansicht nach nie ganz los.
00:49:10Man verlagert einen Teil der clientseitigen Hydration-Kosten
00:49:14eben auf den Server, richtig?
00:49:20Jetzt hat man bei jedem Request die Last," : "Jetzt hat man bei jedem Request die Last,
00:49:21da der Server mehr arbeiten muss.
00:49:26Es gibt ja diese Verschwörungstheorien,
00:49:29dass Vercel das nur pusht, um mehr Server-Compute zu verkaufen.
00:49:31Ich glaube nicht wirklich, dass das der Grund ist.
00:49:33Aber es ist nun mal wahr, dass RSC
00:49:38mehr Serverlast verursacht.
00:49:44Man lässt mehr auf dem Server laufen
00:49:47und verbraucht mehr Compute-Minuten.
00:49:51Natürlich gibt es auch Vorteile, wie etwa:
00:49:52Wenn man Teile auf den Server auslagert,
00:49:54spart man sich Bundle-Size.
00:49:56Aber es gibt viele Wege, dieses Problem zu lösen,
00:49:59die nicht zwangsläufig
00:50:01einen laufenden Node.js-Server erfordern, oder?
00:50:02Vieles davon ist meine persönliche Meinung, klar.
00:50:06Im Frontend sagen wir oft: Okay,
00:50:07die Architektur ist entscheidend.
00:50:10Willst du eine SPA?
00:50:14Brauchst du Server-Side Rendering?
00:50:17RSC ist da noch spezieller.
00:50:19Die Frage "Brauche ich RSC?" ist extrem wichtig
00:50:21und auch sehr schwer zu beantworten.
00:50:24Und wenn man "Ja" sagt,
00:50:27muss man sich der Kosten bewusst sein,
00:50:31denn ich glaube, einer der Gründe für die
00:50:33mangelnde Akzeptanz ist erst mal:
00:50:35Es ist extrem kompliziert.
00:50:37Das Konzept an sich ist schwer zu erklären.
00:50:39Wie es funktioniert, ist schwer zu erklären.
00:50:43Wir mussten da ganz tief eintauchen,
00:50:46weil es eine Orchestrierung auf Build-Tool-Ebene erfordert,
00:50:48damit das ganze System überhaupt läuft, oder?
00:50:50Deshalb verstehen eigentlich nur sehr wenige,
00:50:52wie RSC im Rohzustand funktioniert.
00:50:56Die meisten kennen es nur durch die Implementierung
00:50:58in Next.js, weil ein normaler User
00:51:02RSC gar nicht selbst aufsetzen könnte, oder?
00:51:04Man müsste wirklich verstehen, wie alles ineinandergreift,
00:51:07um so etwas von Grund auf
00:51:11mit reinem React und Vite oder Webpack zu bauen.
00:51:14Das ist nichts für die tägliche Entwicklung.
00:51:17Dafür nimmt man ein Framework.
00:51:20Dafür sind sie da.
00:51:23Aber um RSC in einem Framework zu nutzen,
00:51:27muss das Framework Design-Entscheidungen treffen:
00:51:29Wie präsentiert man RSC so,
00:51:30dass die DX (Developer Experience) ordentlich ist?
00:51:33Und ich finde, Next.js hat das nicht ideal gelöst.
00:51:36Die Verwirrung um "use server" und "use client",
00:51:39dieser gemischte Graph – sobald man etwas als "use server" markiert,
00:51:42funktionieren andere Dinge plötzlich nicht mehr.
00:51:47Man ist darauf beschränkt, nur diese Dinge zu nutzen,
00:51:51und dann importiert man eine Dependency," : "und dann importiert man eine Dependency,
00:51:55die aber nicht mit "use server" funktioniert.
00:51:58Also muss man wieder auf "use client" wechseln, oder?
00:52:01Dieses ganze Hin und Her,
00:52:03diese vielen kleinen DX-Probleme führen dazu, dass die Leute denken:
00:52:06"Okay, um diese versprochenen Vorteile zu bekommen,
00:52:08muss ich mich ständig mit diesen DX-Ärgernissen herumschlagen,
00:52:10und zwar für immer."
00:52:12"Ist es das wirklich wert?"
00:52:15Es ist also verständlich, wenn die Leute zögern.
00:52:20Sogar für Framework-Autoren ist es schwierig.
00:52:24Vercel hatte diese enge Beziehung zum React-Team,
00:52:27sodass sie gemeinsam schnell daran arbeiten konnten.
00:52:28Aber für Dritte –
00:52:35wobei Vercel ja technisch gesehen auch ein Dritter ist –
00:52:37aber für Frameworks wie Remix oder TanStack
00:52:40ist es nicht so einfach,
00:52:42da viele API-Änderungen des React-Teams
00:52:45Next.js bevorzugt haben.
00:52:49Ich will sie gar nicht dafür kritisieren,
00:52:52denn Vercel ist eben ihr Design-Partner.
00:52:57Sie wollen mit Vercel zusammenarbeiten,
00:53:02um dieses Feature zu polieren und zu veröffentlichen,
00:53:06was ja auch Sinn ergibt, oder?
00:53:08Aber dadurch
00:53:13war Next.js praktisch der einzige Weg,
00:53:15RSC überhaupt zu nutzen.
00:53:17Und diese Erfahrung war eben nicht überragend.
00:53:19Deshalb hat es sich wohl nicht so entwickelt, wie es hätte können.
00:53:21Und ich glaube auch,
00:53:25selbst in einer idealen Welt mit perfekter DX," : "selbst in einer idealen Welt mit perfekter DX,
00:53:29wäre RSC trotzdem kein Allheilmittel
00:53:31für jeden Fall, oder?
00:53:33Man muss genau verstehen,
00:53:38wann es Sinn ergibt und wann nicht.
00:53:41Es gibt einfach zu viele Kompromisse.
00:53:46- Ich nehme an, es gab kein Bestreben,
00:53:49etwas Ähnliches in Vue zu implementieren,
00:53:50da die Verbindung zu Vercel ja eher bei Nuxt liegt.
00:53:52Vercel hat Nuxt Labs gekauft,
00:53:54das Meta-Framework für Vue.
00:53:57Wie ist die Beziehung zwischen Nuxt und Vue,
00:53:59jetzt wo sie zu Vercel gehören?
00:54:01- Ehrlich gesagt hat sich nicht viel geändert.
00:54:03Ich finde, Vercel hat sich seit der Übernahme ziemlich zurückgehalten.
00:54:05Das Nuxt-Team ist einfach froh, dass sie
00:54:08ihre Arbeit so weitermachen können wie bisher.
00:54:09Es gibt wohl Bemühungen,
00:54:13dass Nuxt auf Vercel noch besser funktioniert
00:54:14und dort quasi wie ein First-Class-Citizen behandelt wird.
00:54:18Vercel ist sich aber bewusst,
00:54:21wie sie teilweise in der Community wahrgenommen werden,
00:54:24und sie passen auf, dieses Image nicht weiter zu beschädigen.
00:54:25Nach der Übernahme von Nuxt
00:54:30wäre das Letzte, was sie tun wollten,
00:54:32Nuxt zu Dingen zu zwingen, die die Leute nicht mögen.
00:54:34- Leider musste Evan früher weg,
00:54:38um ein wichtiges Telefonat anzunehmen.
00:54:43Aber wir schätzen seine Zeit wirklich sehr
00:54:47und all seine aufschlussreichen Antworten auf unsere Fragen.
00:54:50Wenn ihr künftig Gäste im Podcast sehen wollt,
00:54:52lasst es uns gerne in den Kommentaren wissen.
00:54:54Und wenn ihr generelles Feedback habt,
00:54:56lasst es uns auch wissen.
00:54:58Wir freuen uns darauf.
00:55:00Ihr findet uns überall, wo es Podcasts gibt,
00:55:04wie auf Spotify oder Apple Podcasts.
00:55:06Bis zum nächsten Mal. Tschüss von mir.
00:55:08- Tschüss von mir.
00:55:10- Tschüss von mir.
00:55:11- War mir ein Vergnügen, danke euch allen.
00:55:12- Vielen Dank, dass du bei uns warst.
00:55:15like Spotify or Apple Podcasts.
00:55:17And until next time, it's a bye from me.
00:55:20- Bye from me.
00:55:21- Bye from me.
00:55:21- It's a pleasure, thank you all.
00:55:23- Thank you very much for joining us.