Lots of benefits!
You can work on many projects, with different versions of Node, for a start. No more faffing about with NVM. So if you are a consultant you might have two customers on different versions of node–with Docker you can switch between their projects without a care.
What’s more, if you wanted to upgrade to a new version of Node then you could try it out by editing just one line in your Docker Compose file, and then doing a rebuild; and if there are too many changes to resolve then just revert. Imagine the pain of upgrading the version of Node on your laptop for one project, and then finding that you’ve broken another project.
Also, you can easily work on a multilayered system; if you are working on both the API and the UI for a project, it’s easy to fire up both services together. And of course all of the changes you make are trackable and clearly visible in the Docker Compose file.
You mentioned that you just install the tools you need and then you are done. But again there are version issues when using Webpack, Gulp, etc. What’s more,
npm install starts to get a bit messy if there are dependencies that don’t fall easily into the NPM model–but which are really easy to manage when using Docker files.
In addition there are issues relating to the OS that other developers you are sharing code with might be using. You could tell me to install various tools, and if you are on Windows and I’m on a Mac there will most probably be fun and games. But if we both use Docker files and Docker Compose then we both have exactly the same development environment.
Coincidentally I wrote a couple of blog posts on these kinds of benefits last week, as well as some points about image version numbers and the PID 1 problem:
If I haven’t convinced you, then I’d really love to hear your observations.
All the best,