My Journey into WSL: From Curiosity to Daily Driver

🧭 Introduction: A Developer’s Quest for Control

For fellow Windows developers curious about bridging the gap to Linux, or anyone feeling constrained by their current setup, perhaps my story will resonate.

As a developer, I’ve always believed that we grow the most when we step out of our comfort zones. For me, the comfort zone was clearly Windows. I had everything set up just the way I liked it — VSCode (a tool I used heavily) with anime themes, endless extensions, and the ease of GUI tools.

But beneath all of that, there was always a lingering curiosity:

\> “What if I could work closer to the systems where our code eventually runs? What if I could understand development at a deeper level — not just through GUIs, but through terminals and raw commands?”

This thought was not random. It was sparked by a real need.

While working on my projects, especially my object detection system using YOLOv10 and other tools, I noticed that despite the power of my Windows setup, things often felt... detached. I was developing in an environment completely different from the deployment environment (Linux servers). It made me wonder:

\> “What if my development environment could mirror production?”

That was the beginning of my WSL journey.

---

❓ Prequel: Why WSL?

Before diving in, I did my research.

Going full Linux wasn't an option yet since I wanted to keep my system dual-purpose. But WSL (Windows Subsystem for Linux) felt like the perfect bridge — the power of Linux, without leaving Windows.

I partitioned my drives into C and D, and by default, WSL installed itself in the C drive.

In the early days, I installed a bunch of random tools without thinking much, and soon noticed that WSL was growing in size — fast. That’s when I learned (thanks to WSL docs!) that I could export and import the entire distro to move it to a different location using commands like

wsl --export <DistroName> <FileName.tar>

wsl --import <DistroName> <InstallLocation> <FileName.tar>.

(Pro-tip: definitely check the official docs for managing distro locations!)

So, I moved it to D drive, giving it more breathing room. This was one of my first wins, and it felt great to start understanding how WSL works under the hood.

---

🐧 Setting Up WSL: Choosing Ubuntu

For my distro, I picked Ubuntu, simply because it’s the default and widely supported option.

Online tutorials, community support, and documentation are plentiful for Ubuntu, making it easier to troubleshoot and experiment, especially for beginners.

Installation was straightforward.

Initially, I fumbled a bit — installing random tools, learning by trial and error. But as I dug deeper into WSL docs and Linux basics, things started to click. Moving it to the D drive was just the start. I kept exploring how to manage packages, handle updates, and keep my environment clean.

---

💻 Life in WSL: The Development Experience

Before WSL, I was a full-time VSCode user — you could even say a power user!

I had anime themes, tons of extensions, and my entire workflow revolved around it.

When I moved to WSL, I initially thought I had to give up VSCode and switch to terminal editors like Nano. But to my surprise, I found the "Remote - WSL" extension for VSCode, which integrates directly with the WSL environment. Perfect! 🚀

For a while, I maintained a two-window workflow:

- One VSCode window connected via the Remote - WSL extension for backend development inside WSL.

- Another native VSCode window for frontend development in Windows.

It worked… until my projects grew bigger.

Slowly, everything started to lag. My PC began to chug and struggle, especially during file-heavy operations or when running multiple extensions. I suspected the overhead of VSCode communicating with the WSL file system might be contributing, but I couldn’t pinpoint the exact cause initially. Meanwhile, I was also learning to navigate Linux purely via terminal — no GUI crutches — and it felt empowering.

Ubuntu made many things smooth:

- Tools like Python were either pre-installed or just one sudo apt install away.

- File handling, server setups, and managing environment variables felt more direct and cleaner than my Windows experience.

Overall, WSL felt snappier for command-line tasks – commands executed instantly, and package installs felt quicker. I loved the raw control Linux provided, even though I had to remember many more commands. I took this as a learning opportunity and soon became comfortable living primarily in the terminal.

---

📈 The Impact on My Project: Growing Beyond Backend

Initially, my plan was simple: use WSL just for the backend and let Windows handle the frontend. It felt like a safe balance. I even ran two VSCode windows side by side: one connected to WSL, one native on Windows.

But as the project grew, the performance cracks began to show, particularly with the VSCode setup. That’s when I started looking for alternatives, and this led me to discover Neovim — a tool that completely changed my workflow. (I've written a full article about my Neovim journey [here]

Switching to the lightweight, terminal-native Neovim resolved many of the performance bottlenecks I'd experienced with VSCode in the WSL context. It’s fast, highly customizable, and felt perfectly suited for my terminal-centric WSL setup. Using Neovim inside WSL felt like unlocking a new level of productivity.

At the same time, I began to move my entire workflow, including the frontend, into WSL. Tools like Bun, which often leverage Linux system calls for performance, ran beautifully. Day by day, my environment became more efficient and streamlined within WSL.

What I especially loved was the freedom Linux offers. I could tweak configurations, run system-level commands, and shape my workflow exactly how I wanted. It felt empowering in a way Windows never quite did.

Of course, there were challenges — occasional library compatibility issues required troubleshooting. I even had a few failed attempts to install a full Linux desktop environment (GUI) on WSL, hoping for a familiar graphical file manager, but eventually realized that embracing the terminal-first approach was more efficient and aligned better with the WSL philosophy. These hurdles taught me a lot.

Now, I spend more time in my WSL terminal than in native Windows applications.

I’ve set up aliases and scripts to launch my projects instantly, opening them in Neovim with my preferred layouts and environments with just a command. Developing inside WSL feels native, closer to the deployment environment, and honestly — far more satisfying.

---

🎯Conclusion: Would I Recommend WSL?

Absolutely.

For developers working on Windows but deploying to Linux, WSL has bridged the gap beautifully. It’s given me faster builds (especially for Linux-native tools), fewer dependency headaches (no more compiling issues specific to Windows!), and a much deeper understanding of Linux-based systems.

And while it’s not always perfect, the learning curve and the performance benefits for many development tasks make it well worth it. In fact, for my next PC, I’m seriously considering running a full Linux setup — maybe even trying distros like Pop! OS or Manjaro, which I’ve heard great things about.

If you're looking to get closer to your deployment environment, learn Linux fundamentals without leaving Windows entirely, and potentially boost your development productivity, I can’t recommend trying WSL enough.