In a few words, it's a full-featured development environment living in a dedicated container. It allows you to define this environment in a declarative way, using a config file, and connect to it, using VS Code. As stated in its presentation: "this lets VS Code provide a local-quality development experience including full IntelliSense (completions), code navigation, and debugging regardless of where your tools (or code) are located." It can be used in various ways but the obvious usage is to use Docker dev containers running on your own laptop. The file system can be mounted and synchronised between your host machine and the container, or better, you can clone a Git repository directly to the container without any mounting/syncing.
Surprisingly, this feature is not very known nor widely used yet. This could be because it's quite new, or it may be hard to notice all the benefits it provides without actually using it, I'm not sure. But let me try to convince you how helpful it is, by showing how it helped me in my last projects.
Any project using a container is entirely isolated:
Sandboxed environments do not mess with the host OS packages nor between the different projects themselves.
As you see, sandboxing removes a lot of complexity and various potential issues by the simple mechanism of isolation.
Whatever happens to your environment, you can rebuild it, running a simple VS Code command. It's because everything concerning the project installation is declared in a config, and that this config is versioned on your repository. It will usually take around 20 seconds for my projects, using Docker cache. But why is this so great?
Do you remember the days when you had to follow a 17-step process to set up a project on your laptop? It was long, unreliable, painful, and often eventually failed somewhere because you had a different computer than the person who wrote it. Right? With dev containers, these days are over. Just install Docker, and run the
Clone Repository in Container Volume command. Done. There is no setup process anymore, since the setup itself is declared in the config files.
A good piece of advice for any serious project is to have the most similar environments, especially when not using an intermediary environment like staging, before pushing to production.
In that sense, It seems risky to me to use Windows (or even Mac OS) while your production server runs on Debian. Even if mac OS is unix based, commands are different. Using a dev container, you can choose the same OS that your production environment uses, and avoid accidental complexity related to your host OS. And yes, you may think "we could have done this 10 years ago using tools like VirtualBox or Vagrant". But the general developer experience would have been totally different using your IDE inside a graphical virtual machine, or using SSH to access your file system from your local host. Remember that the promise of a dev container is to keep the same developer experience than the local one. We can't compare apples and oranges.
Besides, when using dev containers with Docker, you could in theory use these Docker files to mirror the setup in production. All that learning to make a clean environment should be used as many times as possible, right? People already using Docker in production should be even more prone to use dev containers.
While we saw dev containers are already amazing for single developers, they shine even more when used within a team of multiple developers. And it's easy to understand why: imagine a world where any developer of your team, no matter its computer or OS, can install the exact same project with no effort? No matter if your teammate has a mac or a windows, in the end, the container will hold the same OS, the same OS packages, the same project packages, and even the same editor extensions and settings.
This work is versioned, and automatically shared with your teammates, after a
git push. This means it's a "once and for all" work, which instantly benefits all your teammates.
By using dev containers, you allow any newcomer to work on the project almost instantly with no effort, making you the team Hero :)
It's hard when starting a project to define rules between developers. How to format code the same way, how many characters by lines, which warning messages should be addressed, etc. Very quickly, developers can disagree on some details and someone has to decide. When all these decisions are enforced, it makes everyone's life easier. Let's see how.
VS Code is very customizable and allows configuration both at user level, and container (project) level. This facilitates the organization:
This distinction has always existed, but dev containers, from their declarative nature, allow CTOs to set things in stone, rather than relying on other developers' good will.
Note that even if you're a single developer working on multiple projects, this VS Code settings flexibility will make your VS Code change automatically when you switch projects, with the right extensions and the right config.
All the time you spend having clean config files, are totally reusable for other projects. That's the role of Docker after all. I personally wrote some scripts that install OS-level packages, customize my PS1, or set some useful aliases. These scripts can be hosted on github and downloaded at the container build time.
As you may have noticed in the architecture chart at the beginning, nothing actually forces the container to live on your local machine. It could be a remote machine with other characteristics. Need some horsepower for AI-related tasks? No problem. What's brilliant here is the ability to keep a wonderful developer experience while using a remote environment. This is because VS Code UI lives on your host machine while VS Code server is executed on the container itself. It provides a much better experience than techniques like SSHFS.
If you're working on multiple projects, no matter if they are on local or remote containers, it will be completely invisible to you: you just connect to your container to run the project.
Thanks to this decoupled architecture (and that VS Code runs on Electron, something more unexpected is that you can even use a simple browser on an iPad to run VS Code (its UI part), while VS Code server runs the remote machine, keeping a good user experience. It basically allows you to keep the same developer experience, no matter the host machine you're using, because most of the demanding work happens at the server level.
Are dev containers perfect? No:
But they're totally worth it. I can't even imagine going back and losing all these benefits.