Warum VS Code + WSL2 heute der Goldstandard ist

Hand aufs Herz: Früher war Webentwicklung unter Windows oft ein Kompromiss. Träge virtuelle Maschinen, Dual-Boot-Experimente oder halbgare Toolchains. Mit WSL2 hat Microsoft diesen Zustand fundamental verändert.

Heute ist Windows eine vollwertige Plattform für Cloud-native Webentwicklung. Du arbeitest mit echten Linux-Toolchains, behältst aber deine gewohnten Windows-Produktivitäts-Tools.
In diesem sechsten Teil der Serie zeige ich dir, wie du Visual Studio Code und WSL2 so verzahnst, dass sich dein Setup wie ein nativer Linux-Rechner anfühlt – nur ohne dessen Nachteile.

VS Code & WSL2: Das Client-Server-Prinzip verstehen

Bevor wir konfigurieren, ein kurzer Realitätscheck: VS Code arbeitet in WSL2 nicht als klassische lokale App, sondern über ein Client-Server-Modell.

So funktioniert es:

Die VS-Code-UI läuft nativ unter Windows (Client)
In deiner Linux-Distribution läuft ein VS Code Server
Kommunikation erfolgt über einen lokalen Socket

Der Server übernimmt:

Dateisystem-Zugriffe
Debugging
Sprache-Server
Workspace-Extensions

Wichtige Praxis-Erkenntnis: Installiere VS Code immer unter Windows, niemals als Linux-GUI-App in WSL.

Nur so bekommst du:

Hardwarebeschleunigte UI
perfekte Clipboard- & Fensterintegration
stabile Performance

WSL2 installieren – richtig und zukunftssicher

Da dieser Schritt entscheidend ist, gehe ich hier bewusst nicht ins Detail.

Die vollständige, aktuelle Schritt-für-Schritt-Anleitung findest du hier:
WSL2 unter Windows 11 installieren – der komplette Praxis-Guide

Dort behandle ich u. a.:

WSL2 vs. WSL1
Windows-Features & Kernel
empfohlene Distributionen
typische Installationsfehler
Performance-Optimierungen

Kurzfassung für diesen Artikel:
Du brauchst Windows 10 (ab 1903) oder Windows 11 und eine laufende WSL2-Distribution (z. B. Ubuntu).

Das Dateisystem entscheidet über Performance oder Frust

Einer der häufigsten Anfängerfehler ist gleichzeitig der teuerste:
Code auf /mnt/c/ entwickeln.

Warum das ein Problem ist

WSL2 greift auf Windows-Laufwerke über das 9p-Protokoll zu.
Das ist bei vielen kleinen Dateien extrem langsam – und genau davon leben:

node_modules
Composer-Vendor-Ordner
Python-Venvs
Git-Repos

Die goldene Regel

Dein Code gehört ins Linux-Dateisystem. Immer.

Empfohlene Struktur:

/home/{user}/projects/my-project

Vorteile:

ext4-Performance
bis zu 20× schnellere Builds
saubere Inotify-Events
stabile Watcher (Vite, Webpack, Laravel Mix)

Zugriff von Windows:

\\wsl$\Ubuntu\home\{user}\projects

VS Code Extensions: Wo sie laufen – und warum das wichtig ist

VS Code unterscheidet in WSL zwischen zwei Extension-Typen.

UI-Extensions (Windows)

Themes
Icon Packs
Keymaps

→ laufen nur auf Windows, einmal installieren

Workspace-Extensions (Linux)

PHP Intelephense
ESLint
Prettier
Python
Go
Docker

→ müssen in WSL installiert sein

Achte im Marketplace auf:

„Install in WSL“
grünen Status: WSL: Ubuntu

Empfohlene Extensions für WSL-Workflows

Remote – WSL
PHP Intelephense
ESLint
Prettier
Docker
GitLens
EditorConfig

VS Code & WSL verbinden: Der magische `code .`-Befehl

Voraussetzungen

VS Code unter Windows installiert
„Add to PATH“ aktiviert
Remote Development Extension Pack installiert

Projekt öffnen

cd ~/projects/my-awesome-project
code .

Beim ersten Start:

VS Code installiert automatisch den Server in WSL
danach erscheint unten links: WSL: Ubuntu

Ab jetzt arbeitest du vollständig in Linux – mit Windows-UI.

Ports, Services & Debugging ohne Konfiguration

WSL2 übernimmt automatisch das Port-Forwarding.

Beispiel:

# läuft auf Port 3000
npm run dev

Im Windows-Browser:

http://localhost:3000

Kein Host-Mapping. Kein NAT-Chaos.

Debugging

Breakpoints in VS Code
Code läuft in Linux
Debugger verbindet sich transparent

Wenn der VS-Code-Server spinnt:

wsl --shutdown

FAQ: Häufige Fragen zu VS Code & WSL2

Warum soll ich VS Code unter Windows installieren und nicht direkt in Linux?
Microsoft nutzt eine Client-Server-Architektur, bei der die UI unter Windows von der Hardware-Beschleunigung profitiert, während der Server-Teil in Linux nativ auf die Dateien zugreift. Eine direkte Installation in Linux (via GUI) ist oft instabil und wird nicht empfohlen.

Ich kann von Windows aus nicht auf den Webserver (127.0.0.1) in WSL zugreifen. Was ist da los?
Oft blockieren Hintergrunddienste von Drittanbietern wie VMware die Virtualisierungs-Features von Hyper-V. Das Deaktivieren dieser Dienste oder der Wechsel in den „Mirrored Mode“ in der .wslconfig löst diese Verbindungsprobleme meistens.

Fehlen in meiner Linux-Distribution wichtige Bibliotheken für VS Code?
Ja, manche Minimal-Images verzichten auf Pakete wie wget oder ca-certificates, die der VS Code Server zum Starten braucht. Ein schnelles sudo apt-get install wget ca-certificates behebt dieses Problem in Sekunden.

Muss ich Docker separat für WSL installieren?
Am besten nutzt du Docker Desktop mit dem WSL2-Backend. Das integriert sich nahtlos und du kannst deine Container direkt aus dem VS Code Terminal oder der Docker-Erweiterung steuern.

Fazit: Windows als Linux-Entwicklungsplattform

Mit VS Code und WSL2 arbeitest du:

mit echten Linux-Toolchains
auf produktionsnaher Infrastruktur
ohne VM-Overhead
ohne Dual-Boot-Risiken

Dein Editor bleibt schnell, deine Builds stabil, dein Workflow sauber.

Ausblick: Teil 7 – Containerisierung mit Docker unter WSL2

Bis hierhin haben wir eine Entwicklungsumgebung aufgebaut, die sich bereits sehr nah an einer realen Produktionsumgebung bewegt:
Echter Linux-Stack, sauberes Dateisystem, performantes Networking und eine nahtlose IDE-Integration mit VS Code.

Im nächsten Teil der Serie gehen wir den konsequenten nächsten Schritt: Containerisierung mit Docker unter WSL2.

Was dich in Teil 7 erwartet

Docker Desktop vs. Docker Engine in WSL2
Wann Docker Desktop sinnvoll ist – und wann nicht.
Docker & WSL2 richtig verheiraten
Performance-Fallen vermeiden, Volumes korrekt mounten, Networking verstehen.
Lokale Stacks mit docker-compose
PHP, Node, Nginx, MySQL, PostgreSQL und Redis reproduzierbar orchestrieren.
VS Code + Docker + WSL2
Debugging direkt im Container, Dev-Container sinnvoll einsetzen.
Produktionsnahe Entwicklung
Warum Container dein „It works on my machine“-Problem endgültig beenden.

Am Ende von Teil 7 hast du eine lokale Umgebung, die nicht nur wie Produktion aussieht, sondern sich auch genau so verhält – reproduzierbar, versionskontrolliert und teamtauglich.

Wenn Teil 6 dein Cockpit ist, dann ist Teil 7 der Moment, in dem du den Jet vom Boden abheben lässt.

#vs code

VS Code & WSL2: Das ultimative Setup für professionelle Webentwicklung unter Windows