Vite.js: Rasantes Build-Tool aus der Vue.js-Schmiede

Vite legt Tempo vor: Das Development- und Build-Tool soll zwanzigmal schneller sein als webpack. Dahinter steht das Team um Vue-Gründer Evan You.

In Pocket speichern vorlesen Druckansicht 15 Kommentare lesen

(Bild: Shutter Ryder/Shutterstock.com)

Lesezeit: 20 Min.
Von
  • Timo Zander
Inhaltsverzeichnis

Kaum eine Programmiersprache polarisiert so sehr wie JavaScript. Während es für einige Entwickler die Wunschsprache ist, stellen sich anderen beim bloßen Klang die Nackenhaare auf. Doch dass JavaScript eine ausgesprochen schnelle Entwicklung ermöglicht, beweist Vite – ein neues Projekt des Teams um Evan You, den Gründer des clientseitigen JavaScript-Webframeworks Vue.

Vite (von französisch "vite" für schnell) soll sich nach der Vorstellung seines Entwicklerteams im JavaScript-Ökosystem vor allem mit Geschwindigkeit und Entwicklungskomfort durchsetzen. Als Development-Server und Build-Tool begleitet Vite JavaScript-Entwickler vom Erstellen des Projekts bis zum Release. Bislang setzten die meisten Entwickler – bewusst oder durch Tools wie die Create React App oder das Vue CLI (Command Line Interface) – auf webpack. Doch je größer der Umfang des Projekts, desto träger wird der webpack-eigene Development-Server. Entwickler warten immer länger, bis vorgenommene Änderungen sichtbar sind. Aus diesem Ärgernis heraus entstand die Idee für Vite. Das Release der stabilen Version 2.0 Mitte Februar 2021 hat die Position von Vite weiter gestärkt.

Young Professionals schreiben für Young Professionals

Dieser Beitrag ist Teil einer Artikelserie, zu der die Heise-Redaktion junge Entwickler:innen einlädt – um über aktuelle Trends, Entwicklungen und persönliche Erfahrungen zu informieren. Bist du selbst ein "Young Professional" und willst einen (ersten) Artikel schreiben? Schicke deinen Vorschlag gern an die Redaktion: developer@heise.de. Wir stehen dir beim Schreiben zur Seite.

Webpack ist im Kern ein sogenannter Bundler. Er sammelt alle JavaScript-, CSS- und Bilddateien zusammen und verschmilzt sie zu deutlich weniger Einzelteilen. Liegen beispielsweise im Quellcode Hilfsmethoden noch in einer anderen Datei als der API-Aufruf, finden sich im fertigen Build unter Umständen beide in einer einzigen, langen JavaScript-Datei wieder. Der Vorteil davon ist die verringerte Ladezeit für die Endnutzer: Statt Tausender Dateien lädt der Browser nur noch einige wenige. Die Laufzeit des Bundlings ist jedoch abhängig von der Anzahl der Dateien.

Beim Build sind einige Sekunden mehr noch vergleichsweise verkraftbar. Problematisch wird es bei der Entwicklung mit dem Development-Server, denn dieser nutzt ebenfalls das Bundling von webpack. Ändern Entwickler eine einzige Datei, muss webpack ganze Bundles aus Dutzenden Dateien neu generieren. Daher verliert das sogenannte Hot Module Replacement – also das sofortige Austauschen geänderter Komponenten im Browser, ohne dass ein Neuladen nötig wäre – schnell an Schärfe, wenn die Wartezeiten an die zehn Sekunden grenzen. Schon für den Start einer leeren React-Anwendung benötigt Vite nur 430 Millisekunden, während es bei Create React App beziehungsweise webpack mehr als 12 Sekunden dauert (s. folgendes Listing).

```
yarn run v1.22.10
$ vite

  ⚡ Vite dev server running at:

  > Network:  http://192.168.56.1:3000/
  > Network:  http://192.168.10.1:3000/
  > Network:  http://192.168.2.119:3000/
  > Local:    http://localhost:3000/

  ready in 430ms
```

```
[13:07:00] yarn run v1.22.10
$ react-scripts start
Starting the development server...

[13:07:12] Compiled successfully!

You can now view cra-example in the browser.

  Local:            http://localhost:3000
  On Your Network:  http://192.168.56.1:3000

Note that the development build is not optimized.
To create a production build, use yarn build.
```
 

Für JavaScript-Verhältnisse ist webpack ein echter Dinosaurier. Seit der initialen Veröffentlichung im Jahr 2012 konnte es reifen und ist ungeschlagen darin, seltene Randfälle gut zu behandeln. Zum Beispiel sind sogenannte "Deep Imports" oft die Ursache für auftretende Bugs im GitHub-Repository, während webpack in solchen Szenarien selten Probleme hat. Aber auch die Konfigurationsgröße von webpack zeigt Flexibilität und zugleich Komplexität, daher büßen häufig etwa 90 Prozent der Anwendungsfälle an Geschwindigkeit und Komfort ein.