WSL for Development — When and Why
I spent a long time going back and forth between native Windows and WSL before settling on a clear rule: if it touches a server or a terminal, use WSL. If it talks to Windows hardware, stay native.
The Decision
| Use Case | Environment | Why |
|---|---|---|
| Web dev (Django, Flask, Node) | WSL | Matches production. Dependencies just work. |
| Data Science / ML | WSL | Installing TensorFlow on native Windows is pain. WSL is not. |
| DevOps, scripting, automation | WSL | grep, sed, ssh, cron — the full Unix toolkit |
| Desktop GUI apps (Tkinter, Qt) | Windows Native | You’re building for Windows, test on Windows |
| Arduino / robotics | Windows Native | Windows-only drivers and upload tools |
The Setup
The magic combo is WSL 2 + Ubuntu + VS Code with Remote-WSL extension. You get a full Linux filesystem, native Docker, all your terminal tools — and VS Code just opens files from the WSL side as if they were local.
From a WSL terminal, code . opens the current directory in VS Code. That’s it. No config, no friction.
See Also
- Running LLMs Locally with Ollama — GPU passthrough in WSL makes this possible
- Oh My Zsh Plugins — first thing I set up in any new WSL install
- Self-Hosting a Server on an Old Laptop — where WSL workflows end up deploying to
- Bash Keyboard Shortcuts — essential once you’re living in the terminal