Tooling that claims to improve developer productivity should be editor-agnostic. If Microsoft can’t fully support that, an alternative standard will emerge—because, ultimately, locking developers in rarely works long-term.
Besides, the VS Code golden age has passed. It’s well on its way down the enshittification ramp.
Are people sharing their editor configs with this? I thought it was a way of getting a development environment setup, but those shouldn't have editor extensions and configuration.
One approach might be to try to put vscode into the devcontainer or into another container. But it needs a hole poked for the GUI for for someone to do the plumbing to get the GUI to run in a sandboxed browser context, and I don't think MS makes this easy.
(Note that vscode has no security model. If you connect vscode's normal frontend to a malicious backend, you are pwned, and this isn't even considered a bug.)
Is it a last resort, like if your arch is so different from your project environment that you have to go so far as to develop inside a container?
I hate even running local docker containers the second I want to do anything inside them. And that's the vibe I get when I read about devcontainers despite wanting to earnestly try it out at one point (I frankly couldn't figure it out back when I tried).
Why use one of these premade container images vs using a base image, adding extra packages/layers as needed?
Is this a Go project and you don’t have the right Go tools installed locally? Not a problem, as it’s in the container.
Do you have multiple node/js projects and you don’t want modules or tools to overlap? Each project has its own container.
Do you work on Mac, but want to deploy on Linux? The container makes this work too. (This one is my primary usecase). With a devcontainer, I can work on my Mac without having to install dozens of homebrew packages. Better yet, I can work with others and it doesn’t matter what computer they use, as the dev environment is standardized.
If you ever used Vagrant to work in a dev VM, it’s like that… but much faster to get started.
Working across different code bases that use variations of tools and versions, I no longer have to think about them clashing, or using Homebrew.
Very useful for rapidly onboarding new team members, they are of course free to roll their own dev environment, but we have a known good system to use if that doesn’t work or breaks.
I wouldn’t use the CLI of this post, instead I launch them using a Raycast quicklink (e.g. vscode://ms-vscode-remote.remote-containers/cloneInVolume?url=https://github.com/ministryofjustice/modernisation-platform-...)
The team I work on publish some internal guidance for using them https://github.com/ministryofjustice/.devcontainer
The main benefit is actual containerization of the project dependencies (apart from tools that love to download stuff in $HOME). So I can wipe them and recreate them in seconds. And you can use different distros for different workflows.
They're helpful for cross-architecture debugging and serving as a source of truth that the build actually works on a dev machine but definitely the ergonomics leave a bit to be desired.
That means that someone coming into a project has nothing to setup on their local machine - runtimes, compilers, etc.
You can use them for this reason without doing remote dev. But yes for remote dev you wouldn't even need to setup docker locally, and you're able to develop on a different architecture.
I do agree though, I think devcontainers are in an awkward spot where they're cattle but my IDE/environment is typically a pet...