Docker is a great tool, particularly for development environments on projects with complex dependencies: multiple databases, caches, message queues, asynchronous workers. Docker compose provides a great wrapper to link all these dependencies into a simple, developer-friendly API.
There are some trade-offs: containers need to be rebuilt when package dependencies change, port forwarding and volume mounts can be akward, and when not running natively on a Linux host, performance tends to take a hit (e.g. Docker for Mac). In many cases, the ease of setup make these trade-offs worthwhile, and the host machine (i.e. the laptop) is kept clean. So long are the days when you have to install two versions of elasticsearch on your development box because you are working on several projects simultaneously.
There are instances, however, when using Docker doesn't make sense: the application with no dependencies (i.e. a standalone app).
This tends to be more prevalent in the front-end world where
jumping-on-the-bandwagon seems to thrive. I've seen convoluted
dockerized setups whose sole-purpose is to run npm install for a single-page,
static JS application. Unless doing so to save other developers the hassle of
installing C-libraries for ImageMagick, libxml2, etc., there simply is no
need for this extra layer of complexity.
Environment isolation is already provided with npm as project
dependencies are stored locally under node_modules by default. In Python,
virtualenv
has solved this problem for over a decade.
If the goal of dockerizing the standalone app is to use a specific runtime version, then something like rbenv and its JS and Python forks: nodenv and pyenv are excellent choices.
Whenever possible, use a version management system for your standalone projects, and use Docker when you truly need it.