Usually web developers that don’t work with Microsoft technologies don’t use Windows because they prefer UNIX-like operating system such as Apple’s MacOS or popular Linux distributions like Ubuntu, Debian, Fedora, and other. UNIX-like operating systems simply have better support for many ecosystems and that’s one of the main reasons why it’s easier to use them instead of Windows.
Because of these issues I tried to use Windows 10 as my main development OS. I wanted to check out the possibilities for developing web applications on Windows. My goal is to have UNIX friendly terminal and UNIX-like tools and workflow.
There are several choices for setting up a development environment. Before I start covering all of them, we first need to choose the most essential tool and that is proper terminal. There are a lot of options for terminals and shells but I’m going to list only the ones that I’ve tried:
- Git Bash (terminal + BASH emulation shell + git and many popular UNIX commands)
- Hyper Terminal
My favorite is Hyper Terminal because I like its cross platform consistency and it looks and “feels” the best. However, since it’s Electron app it is a bit slower than the rest. Also, it doesn’t come with any sort of Bash emulation shell so it’s using Command Prompt out of the box. If you want Bash emulation you can install GitBash and configure Hyper Terminal to use Git Bash shell.
However there is another amazing option and that is Windows Subsystem for Linux (WSL). It is built-in Windows 10 feature that you have to explicitly enable. It enables you to run native Linux shells and binaries in Windows 10. You can read more about it here. If you’re coming from MacOS or Linux I definitely recommend Hyper Terminal + WSL. From there you can set up your Linux shell of choice and configure everything as you would in regular Linux distribution.
Choices, choices everywhere!
Next, you need to decide what’s your approach for development environment. There are a lot of choices but I’m gonna cover the most popular ones today:
- Running native binaries directly on Windows without additional “layers”
- Running Linux binaries using Windows Subsystem for Linux and Ubuntu
This is not a tutorial piece, just an overview of approaches so I won’t go into details. I’ll only briefly mention some good and bad sides of each approach based on well known facts and my personal experience. Also, in some use cases some of these approaches are not an option at all.
Vagrant enables you to manage and provision virtual machines in a simple manner. You have to install virtualization provider software (VirtualBox, VMWare, Hyper-V, Parallels) before you can install and use Vagrant. Then you can download Vagrant box. Box is a fancy word for pre-configured virtual environment image. Usually there are multiple choices for major web platforms/ecosystems. These boxes come with installed and configured software so you can start developing immediately. You can also make your own but that’s more complicated and usually not required (and it’s more of system admin’s job).
- boxes usually fully configured for major web platforms
- very easy to use and ready for development out of the box
- boxes are usually easy to configure using simple configuration files
- virtualized and isolated environment – low risk of breaking your host OS in any way
- it’s easy to mimic and distribute production server setup to all developers in team
- since it’s fully virtualized environment it comes with performance cost (potentially CPU and RAM intensive and low I/O throughput)
- for advanced configuration there’s a big learning curve (good knowledge of Vagrant and virutalization provider is required)
Docker is a software which you can use to create and manage containers. In short, container is an application packaged with all of its dependencies in a single unit. You can read more about it in official documentation. The main idea is to have simpler way of distributing and deploying your application to any environment. At first glance containers sound similar to Vagrant boxes. But they are not VM’s so they are more lightweight. If this sounds a bit confusing that’s because it is. To get comfortable with Docker you need to properly read documentation and check out a few examples.
- it’s easy to mimic and distribute production server setup to all developers in team without big performance overhead
- isolated environment – low risk of breaking your main OS
- for development it’s not dead simple as it requires proper understanding of how to manage and configure containers
- for advanced configuration there’s a big learning curve
3. Running native binaries directly on Windows without additional “layers”
This approach is the most straightforward. You simply install all of the software that you need for your web application and start developing. Best performance, easiest to understand. However, there are some caveats. Windows is usually not well supported by open source web technologies. You usually run your web apps on Linux servers. Sometimes configuring for completely different platforms may be very different. That could lead to confusion and bugs. Also, Windows still doesn’t have official package manager. However, there’s Chocolatey. If it has everything you need then that’s the best option. If Chocolatey doesn’t suit your needs then you’re out of options. Without package manager it’s harder to manage system software. This is especially important for running web technologies.
- best performance
- no abstraction layers or “middle-man”, just simple executable (.exe) files
- configuration methods could be different compared to Linux (usually used in production) so it’s more prone to bugs
- without package manager it’s harder to manage software (and PM’s are not popular on Windows)
- sometimes important and popular software is not available as native binary (rare, but Redis is the biggest example)
- harder to mimic and distribute production environment configuration
4. Running Linux binaries using Windows Subsystem for Linux and Ubuntu
This is the “wildest” and the most experimental approach. Basically you can install Ubuntu as part of WSL. Then under WSL you could install native Linux binaries needed for your application. The process is the same as you would do it on production server. Then you can use those binaries and run your application. Since Canonical (Ubuntu’s company) is officially collaborating with Microsoft this actually works well. However, this is still not “battle-tested” and it’s hard to call it stable. It’s faster than spinning up full VM with Ubuntu, though. So, if you have simple requirements and want to get up and running quickly, this is a good approach. Especially if you have an older computer. One notable downside is that WSL doesn’t have init system so you have to run and stop processes yourself.
- good performance
- familiar Linux tools, workflow, and package manager
- isolation of software – easy to get rid of WSL instance without cluttering your Windows installation
- it’s new and a bit experimental so it’s prone to bugs
- you have to manage processes yourself
- not convenient for mimicking production setup
We covered most popular approaches to development workflow. Nowadays, developing web applications on Windows 10 is pretty accessible. Before picking anything you need to set your requirements and conditions. Then you could use this article as a starting point and move on from there.
My personal approach for Windows 10 is Vagrant. Sure, it’s slower than all the other options but any decent laptop can handle my needs. I choose it because it’s easy to understand and configure boxes I use (usually Homestead for PHP development). Docker is a great method too but it takes more research and understanding. I think it’s the best option if you’re in a company with dedicated DevOps engineer. Then it’s his/her job to prepare and streamline development environment workflow. For smaller companies and projects I don’t think it’s worth exploring.
Other approaches come with good performance but with other inconveniences. In many cases it’s required to mimic production environment and they are not good in this regard.
Thank you for reading this! Let me know what you think and leave a comment down below.