Before WSL1 I would run Linux inside a VM from Windows and use remote development tools (like VSCode via SSH, SSH tunnels for port sharing, etc). It was all pretty straight forward, stable and I had no issues.
I used WSL1 when it launched and it was _incredible_. Bash actually on Windows. My workflow changed because of the level of integration I had with Windows. I could run browser automation tools against my Windows browsers, from Linux. I could run Windows programs from bash.
WSL2 came on the scene and introduced a hypervisor layer and I essentially came full circle. Sure it has some smarts around memory VM allocation - but it doesn't always work right and you're never really certain it's not running, consuming memory. Network port mappings were automatically tunneled, but only in one direction and they would occasionally fail causing random issues that require a reboot to solve. Now GUI windows are shared with Windows via RDP, cool..
Ultimately, WSL2 is the attempt to take Linux VM and make it appear like it's not a VM. Maybe it'll get there one day, but due to the got-ya's it's not for me.
I have since reverted back to using my choice of distro inside my choice of hypervisor, where I know what's going on and don't have to mentally reverse engineer the magic when it goes wrong.
> Ultimately, WSL2 is the attempt to take Linux VM and make it appear like it's not a VM. Maybe it'll get there one day, but due to the got-ya's it's not for me.
In my experience, its been pretty great and elegant to work with. I've used it for ~1.5 years so far and they seemed to have broken down a lot of those vm walls to make it seem like some kind of hybrid windows + linux operating system. Doing stuff like 'code .' from within wsl to open the current wsl working dir in the vscode windows gui is pretty neat. And you can also do kind of neat stuff like writing to your windows clipboard from within WSL by running the powershell windows executeable. This is in my wsl .bashrc to do that:
function cb () { powershell.exe -command "\$input | set-clipboard" }
echo "hello" | cb # write hello to my windows clipboard
Cygwin has been able to do this for 2 decades, actual bash plus other unix tools compiled to actual windows exe's. You can even run some gui tools if you run an xserver on windows.
Even WSL1 wasn't as good, there were too many issues like tail not working properly on windows files, issues with network shares, interop, etc. I pretty quickly reverted to cygwin.
I much prefer WSL1 and I've only run into a couple of issues over the last year (can't set Windows time from Linux and ssh-agent doesn't work out of the box) which is a significant improvement over cygwin or even a proper linux distro (which would occasionally boot to a black screen after updating anything related to X)
Once I moved to Manjaro/XFCE a few years ago, all the problems disappeared. Docker just works. All the web dev tools are built for my platform and just work. There are no compatibility layers or emulation layers to worry about. I'm in charge of updates. I don't get nagged to do things at inopportune times. I'll never go back to either one of them full time. Windows for games, Macs for iOS/Xcode. That's it for me. Even for .Net and iOS now - I can do that too on Linux with .Net core and React Native.
A lot of developers use MacOS, particularly web developers who are almost always deploying the server to a linux machine. With the Mac being BSD-flavoured, a lot of open source tooling works the same as it does on Linux. MacPorts and Homebrew have done a lot to drive that.
The experience on Windows for this has been incredibly poor. There are solutions, but they're less integrated.
WSL comes in, along with Windows Terminal, and now you can have a much nicer time with it all without dual booting or running a VM.
Who knows where it'll be in a decade, but if anything, they're just making themselves a viable competitor to Apple by providing better development tools than they do.