I think a lot of your comments here are very true. I don’t think docker made my world worse and I certainly don’t think it cost me more time, but I also sort of

I think a lot of your comments here are very true. I don’t think docker made my world worse and I certainly don’t think it cost me more time, but I also sort of agree with the author. I came into Typescript late, and to “tame” the wildness of the ecosystem I set up a lot of opinionated systems for our developers. I didn’t dictate them, it was a collaborative process where we worked long and hard go agree on how we would utilise the Node ecosystem as well as the 10ish rules that we’ve changed as opposed to the “global” strict eslint rules. Rules which have themselves been born out of a decade of different rulesets like the Airbnb ones most people in the JS community will have heard of. My approach to containers has been similar. We don’t use docker-compose and never have as an example, we went with Terraform, though today we’re using Bicep, and we make heavy use of dapr side cars. Which makes working with infrastructure sort of easy. Easy to lock down and opinionate at least. You can get most templates directly from Azures GitHub, but you can obviously also build your own, and then it’s simply a matter of having some decent template projects so that your developers can be up and running in a few minutes whenever they need to start a new project. Obviously there is a cost when you’re moving legacy projects into this sort of infrastructure, but it’s not like it’s really that resource consuming if it was already containerised, and it’s not too bad even if it wasn’t. Now, that’s how we do it. It’s also how I think everyone should do it, but it’s not how you “have” to do it. In many ways, you’re as free to utilize the container ecosystems as freely as you can with the Node ecosystem. Well maybe not as free as that, but still free enough to create a lot of horror stories. Which is exactly what has happened with containers in many organisations. As such I think the author has a valid point. I’m not sure where we would go without the freedom though. Our exact setup works for us, you might not agree with our choices and neither of us would be wrong. So while some opinionated processes might be compatible with container infrastructure, others will need to remain “free”. I’m certainly with a lot of you in that it was worse before containers. I’ve also done work with organisations where container deployments worked so poorly that it was clearly not better, however, and I suspect those pipelines are far more common than given credit in this comment section.