I disagree. I'll argue that most of the new crop of developers are self-taught/bootcamp-trained/career-switching and they straight to the web. For RoR, Node.js, Python, Go, etc. it's not a common setup and those are the languages being learned today.
Now if we are talking about the public who has a "I remember when I started with PHP" nostalgic feeling while reading this article I might agree, but that is not "most developers" :)
Don't forget PHP on Windows IIS (like I must live with at my job, because we have lots of enterprisey COTS, and the sysadmins don't want to have to administrate two OSs, and I don't want to sysadmin, because I don't want to get the 2 AM phone calls).
I agree with you. I am not sure "convenience Makefiles" like these really accomplish much, other than letting you put 6 shell scripts in one file. The cost, of course, is that you can't run anything on Windows. If you have a native Make-like, I would just use that instead (npm lets you define them in packages.json, for example.)
These convenience Makefiles ultimately don't get to the root of the problem of building a dependency graph for your project, and result in much overbuilding. For example, I have a Go backend + Vue/Typescript frontend. "make all" will re-webpack the frontend when you modify the backend because make was not taught the dependency graph. It doesn't understand the dependencies between input and output because it was not told that. Telling it that involves reverse-engineering your language's internal dependency management (go already knows what it has cached, for example), so nobody does it. If you _do_ decide to rewrite your language's dependency management to make make do incremental builds correctly, you will get it wrong and then _underbuild_, which is why "just run make clean!" is such a common remark. To me, underbuilding is worse than overbuilding, but both are bad. If you can't solve that problem (by using something like Bazel), I would not bother with make. (We all dream of the days when .c became .o and your binary was just all the *.o files linked with some libraries. But that is not how newer programming languages work at all.)
For the case where the author is just using docker-compose, I would say... you have two docker-compose files, one for local development, one for production. You build your development docker-compose approximately once, have it running, and tell your web framework thingie to rebuild when the code changes (mounted in the container with a volume). Meanwhile, your CI system builds a container without any of that dynamic recompilation stuff for production. Not great, but not horrible either. You will need some glue to run your unit tests inside the container. Probably a shell script that the Windows users on your team will port to Powershell for their own use. All in all, not ideal, but not super bad either. (I personally think I will move in the direction of ksync/telepresence and minikube, so the shell scripts to do things like run the tests or wipe the database are run inside the dev container, and nobody has to pretend their local machine matters for anything but "minikube start". But it is more work than docker-compose, for sure.)
You don't really need Makefiles until you don't have dependency management. If you just need 'shortcuts', you can just use python/shell/whatever scripts
I disagree. I'll argue that most of the new crop of developers are self-taught/bootcamp-trained/career-switching and they straight to the web. For RoR, Node.js, Python, Go, etc. it's not a common setup and those are the languages being learned today.
Now if we are talking about the public who has a "I remember when I started with PHP" nostalgic feeling while reading this article I might agree, but that is not "most developers" :)