Five different Rails dev environment on Windows 10

Developing rails application on Windows used to be painful in the pre-jruby and pre-RailsInstaller era. Most Rails developer in the early 2010 run on either OSX or Linux. As of today, there are five different ways to setup a Rails development environment on Windows 10. When I started working on the Rails project of my current job, I spent quite some time playing with different alternatives. This article tries to give an introduction to each of them and evaluate their pros and cons.

Windows 10 + Virtual machine (linux guest)

This is a standard Windows 10 installation running your favourite distribution of Linux on Hyper-V, VirtualBox or VMware, with full desktop experience. Other than the fact that your Linux environment is virtualized, this is no difference in usability compared to a bare metal Linux installation.

Example setup guide:


Windows 10 + Vagrant (linux guest)

A standard Windows 10 installation running Vagrant with your favourite virtualized distribution of Linux. IDE and text editors run on Windows and access project files from local disk. The virtual Linux is installed with Rails and other services and dependencies.

Example setup guide:

Windows 10 + Windows Subsystem for Linux (WSL)

Using Windows Subsystem for Linux (WSL), a new feature in Windows 10, it is possible to have a Linux environment inside Windows without any virtualization. IDE and text editors run on native Windows. Rails and its dependencies run with WSL.

Example setup guides:

Windows 10 + JRuby

A standard installation of Windows 10 running JRuby instead of Ruby MRI. JRuby is a Ruby implementation that runs on JVM. This installation does not require a compatible C compiler installed on Windows (which is a common pain point.)

Example setup guides:

Windows 10 + Ruby MRI

The supposedly standard way of installing running Rails on Windows. Since we are running Ruby MRI, DevKit also needs to be installed to make sure that gems compiling native extensions can be properly installed.

Example setup guides:


We compare the different approaches in these categories:

Installation Effort : How easy or hard and complicated is it to install the stack?

Performance : A performant stack is able to run the development server and unit tests faster.

Compatibility Issue : Are there any compatibility issues with the RoR installation and other common gems?

Developer Experience : How (un)enjoyable is it to develop on this stack?

IDE Support : A good IDE that supports the stack speeds up the development process.

Mirroring Production Environment : Is it possible or easy to mirror the same setup as production environment, which comes in handy with troubleshooting.

VM Vagrant WSL JRuby Ruby MRI
Installation Effort High; Requires a full installation of desktop Linux, your favourite editor, ssh keys and dotfile configuration. Medium; If you require very basic environment, you might be able to use a vagrant box from someone else. High; Documentation are sparse. WSL is still relatively young. Setup is mostly manual. Medium; JRuby's installer can do most of the heavy lifting. Low; RailsInstaller can take care of everything for you.
Performance High; With modern virtualization technologies (VT-x and VT-d), performance should be close to native. Medium; CPU performance is great, but IO performance is at the mercy of VirtualBox/VMware's shared folder implementation. IO notification support is missing with certain shared folder implementations. High; Essentially native setup, both CPU and Disk IO performances are very good. Medium; JRuby takes a lot more memory than Ruby MRI. Otherwise, performance is fairly on par with Ruby MRI. High; This is a native setup.
Compatibility Issue Minimal; This is essentially a Linux setup. Minimal; This is essentially a Linux setup. Medium; WSL is still young. You may be the first one to experience issues. Medium; Gems that have native extension written in C won't run on JRuby, the community has developed their JRuby alternatives. Medium; Even with DevKit, some C extensions might not build properly. Gem developers might not have tested extensively on Windows.
Developer Experience Potentially problematic; UI could be slow if running with weak, integrated graphics. DPI scaling issue if running on HiDPI display. Potentially problematic; Disk IO could be slow. Symbolic link and Hard link could pose problem. Good; One caveat is that you need to keep a bash shell open so that spring preloader and other services can stay running. Good; Though debugger support is substandard compared to other alternatives. Common tools like byebug is MRI-only. Good; other than having to deal with occasional issues with community gems, this setup is very developer friendly.
IDE Support Excellent; Run your favourite IDE directly inside the VM Good; Rubymine supports Vagrant remote Ruby SDK. But Gem syncing could be slow. Good; Rubymine supports WSL remote Ruby SDK. But Gem syncing could be slow. Okay; Rubymine supports JRuby natively. But I could not get debugger to work. Excellent; Rubymine supports Ruby MRI on Windows. Other editors like VS Code also worked very well.
Mirroing Production Environment Excellent; It's very easy to mirror production setup. Excellent; It's very easy to mirror production setup. Good; WSL is still not a full Linux experience but it is close. Not good; unless you run JRuby in production. Poor; you are probably not running Windows in production

Which one to choose ?

You probably saw it above, unfortunately, none of the environment is perfect. Choosing a development environment is an act of carefully balancing the trade-offs. WSL is almost close to be the perfectly balanced candidate, with future iterations, it might become to best choice for developing Rails on Windows.