Vite, Rust & die Zukunft des JavaScript-Toolings | Better Stack Podcast Ep. 11

BBetter Stack
컴퓨터/소프트웨어창업/스타트업AI/미래기술

Transcript

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.

Key Takeaway

Evan You treibt mit seinem neuen Unternehmen VoidZero die Zukunft des JavaScript-Toolings voran, indem er einen vereinheitlichten, extrem schnellen Rust-basierten Stack entwickelt, der Entwicklererfahrung und Performance auf ein neues Level hebt.

Highlights

Evan You erklärt den Übergang von Vite zu Vite+ und die Gründung seines neuen Unternehmens VoidZero.

Der Einsatz von Rust (OXC-Stack) ermöglicht massive Performance-Steigerungen gegenüber herkömmlichen JavaScript-Tools.

Rolldown wird als der neue

Timeline

Einführung und die Entstehung von VoidZero

Evan You stellt sich als Schöpfer von Vue und Vite vor und präsentiert sein neues Unternehmen namens VoidZero. Er erläutert, dass die Firma an einer Reihe von Open-Source-Projekten arbeitet, darunter Rolldown, Vitest und die OXC-Toolchain. Da er nun weniger Zeit für die direkte Programmierung hat, leitet er ein Team von Ingenieuren, die verstärkt KI-Tools wie Claude oder Cursor für das Schreiben von Rust-Code einsetzen. Das Ziel ist es, Entscheidungen zur Developer Experience (DX) zu treffen und diese Projekte in marktfähige Produkte zu verwandeln. Dieser Abschnitt verdeutlicht den strategischen Wandel von Einzelprojekten hin zu einer professionellen Unternehmensinfrastruktur für Web-Tools.

Die technischen Herausforderungen und der Weg zu Rolldown

In diesem Teil wird detailliert dargelegt, warum bestehende Bundler wie esbuild und Rollup für die Zukunft von Vite nicht mehr ausreichen. Evan You beschreibt das Problem der Inkonsistenz, da Vite derzeit esbuild für die Entwicklung und Rollup für die Produktion nutzt, was zu subtilen Fehlern führen kann. Er erklärt die Performance-Grenzen von JavaScript-basierten Tools und warum einfache Portierungen nach Rust oft an den Kosten der Datenübertragung scheitern. Die Lösung ist Rolldown, ein von Grund auf in Rust neu geschriebener Bundler, der die API von Rollup mit der Geschwindigkeit von esbuild kombiniert. Dieser technologische Durchbruch ist notwendig, um die Effizienz bei der Verarbeitung großer Modulgraphen drastisch zu erhöhen.

Die OXC-Toolchain und der vertikale Stack

Der Sprecher vertieft die Bedeutung von OXC, einer Sammlung von Low-Level-Sprachtools, die als Fundament für den gesamten Stack dienen. Er hebt hervor, dass der OXC-Parser dank spezialisierter Speicherverwaltung (Arena Allocator) bis zu dreimal schneller als SWC ist. Durch die Vereinheitlichung von Parser, Resolver und Transformer über alle Tools hinweg werden Konfigurationsfehler vermieden, die sonst bei der Kombination verschiedener Tools auftreten. Beeindruckende Statistiken zeigen, dass OXLint bis zu 100-mal schneller als ESLint arbeitet und OXFormat Prettier weit hinter sich lässt. Das Ziel ist ein nahtlos integrierter vertikaler Stack, der ohne mühsame Refactorings enorme Geschwindigkeitsvorteile bietet.

Die Zukunft des Bündelns vs. Import-Maps

Hier diskutiert Evan You die Debatte um "No Build"-Setups und Import-Maps, wie sie beispielsweise in Ruby on Rails propagiert werden. Er argumentiert, dass ungebündeltes Laden bei kleinen Anwendungen funktioniert, aber bei großen Apps mit tausenden Modulen zu massiven Netzwerk-Flaschenhälsen führt. Ein Bundler bleibt essenziell, um die User Experience durch optimiertes Caching und weniger HTTP-Requests sicherzustellen. Viele Entwickler lehnen Build-Schritte nur deshalb ab, weil die Konfiguration in der Vergangenheit bei Tools wie Webpack zu komplex war. Vite+ zielt darauf ab, diese Komplexität zu verbergen und gleichzeitig die notwendigen Optimierungen für Enterprise-Anwendungen zu liefern.

Vite+ und die Vision einer vereinfachten Entwicklung

Vite+ wird als eine Komplettlösung vorgestellt, die den gesamten Workflow von der Installation bis zum Deployment abdeckt. Ein zentrales Feature ist die Beseitigung der Notwendigkeit, Node.js oder Package-Manager manuell zu verwalten, was durch eine einfache Binary namens "vp" erreicht wird. Das Tool erkennt automatisch die richtigen Versionen und bietet integrierte Funktionen für Linting, Formatting und Monorepo-Management. Evan You betont, dass Vite+ für die meisten Nutzer kostenlos bleiben soll, während sehr große Unternehmen für zusätzliche Services zahlen. Es soll die Antwort für Einsteiger sein, die sofort produktiv sein wollen, ohne sich mit der JS-Infrastruktur-Hölle auseinanderzusetzen.

KI in der Entwicklung und die Risiken für die Codequalität

Der Fokus verlagert sich auf den Einfluss von KI auf die Softwareentwicklung und wie Tools wie Vite+ damit interagieren. Evan beobachtet, dass KI-Modelle oft veraltete Technologien nutzen oder Optionen halluzinieren, wenn sie keine klaren Leitplanken haben. Da durch KI-Agenten die Geschwindigkeit der Codeproduktion massiv steigt, wachsen auch die technischen Schulden in den Codebasen schneller an. Er sieht eine große Chance darin, Tools zu entwickeln, die KI-Agenten aktiv steuern und die Codequalität überwachen, um ein Auseinanderfallen der Projekte zu verhindern. Die Geschwindigkeit von Rust-basierten Tools ist hierbei ein entscheidender Vorteil, da sie sofortiges Feedback für die KI ermöglichen.

Vite 6, pnpm und technische Design-Entscheidungen

In diesem Abschnitt werden spezifische Details zu Vite 6 und die Wahl von Rust als Kernsprache erläutert. Evan You erklärt, warum pnpm derzeit der bevorzugte Package-Manager ist, da er die beste Balance aus Effizienz und Workspace-Features bietet. Die Entscheidung für Rust gegenüber Go fiel vor allem wegen der besseren WebAssembly-Unterstützung und der Verfügbarkeit hochperformanter Low-Level-Bibliotheken wie OXC. Ein fliegender Wechsel der Triebwerke findet statt, während die Stabilität durch umfangreiche Ecosystem-CI-Tests mit Projekten wie SvelteKit sichergestellt wird. Dieser Teil unterstreicht den hohen Anspruch an die Zuverlässigkeit des Tools trotz radikaler technischer Änderungen.

Kritik an React Server Components und Ausblick

Zum Abschluss äußert sich Evan You kritisch zu React Server Components (RSC) und deren mangelnder Akzeptanz in der Community. Er bemängelt die hohe Komplexität und das Hin und Her zwischen Client- und Server-Direktiven, was die Developer Experience beeinträchtigt. Seiner Meinung nach ist RSC kein Allheilmittel und verursacht oft unnötige Serverlast ohne signifikante Vorteile für die meisten Standard-Apps. Das Gespräch endet mit einem Einblick in die Beziehung zwischen Nuxt, Vue und Vercel, wobei Evan betont, dass die Unabhängigkeit der Projekte gewahrt bleibt. Das Interview schließt mit einem positiven Ausblick auf die kommenden Veröffentlichungen von VoidZero.

Community Posts

View all posts