Large dependency trees are usually not about using docker or not. That is rarely a dependency of the code itself. The complaint about large dependency trees is about hundreds or even thousands of dependencies of the code itself, where you could get away with maybe tens, if you write trivial code (left pad ...) yourself and avoided needlessly adding more stuff on top. Every time one adds a dependency, one should feel a little sting and make an uncomfortable face and remember, that this dependency might make things badly maintainable, difficult to upgrade, or vulnerable. Always ask oneself things like: "Did I read the code of that dependency and its dependencies? Do I really know what this code does?" and of course if one does now lock down that dependency to exactly one version, one would have to consider these things every time one upgrades dependencies.
Now for a throwaway web app maybe one does not need to care. But then one should also label it as such. A throwaway, nothing to be taken as a good example. Definitely not production ready code.
It is true that JS and the web + JS ecosystem is absolutely overloaded with “utility” dependencies like lodash or some weird fusion experiment in a way that Python or Java is not. I personally have implemented and removed a ton of dependencies in the latter two languages with little hassle - I’m aided by the fact that these languages support DI or hexagonal architecture and a good project layout can prevent something that I don’t need, care about, or understand from becoming ubiquitous and cumbersome as my codebase grows.
Now for a throwaway web app maybe one does not need to care. But then one should also label it as such. A throwaway, nothing to be taken as a good example. Definitely not production ready code.