A bunch of stuff I see comes with a dockerfile these days.

While I get building in docker for reproducibility, kind of -- shipping with one is a pretty big red flag. It means that it's likely to be very painful to port the code out of docker and integrate it into some other build. Which means that it'll be painful to integrate it with other code. Leave the build environment set up to the users. Embrace build diversity, it makes your code less fragile.

Those are the times I wonder whether I’m getting old. I kept using a shell alias that does ssh -ND, even though that requires maintaining a config file.

But on the other hand, is a dependency on having Docker available really worse for portability than having a dependency on having a reasonably standard Unix environment?

I often need to run it somewhere other than docker -- possibly integrating it into a different program.

Docker doesn't make this impossible, but it's a sign that portability was not considered when the code was written, and I'm in for pain.

No it wouldn't. Dockerfiles are stupid simple. A bunch of ADD/COPY commands to add files, and a bunch of RUN commands that are basically wrapping shell scripts.

Plus, find me a modern build system (CI/CD system, rather) that doesn't natively support Docker. It's become a lingua franca at this point.

I just wish it was faster on its own without me having to do all the legwork of maintaining lower layer containers etc. to avoid lengthy package install times.

Yes. And the code sitting beside them starts to make assumptions -- so when I try to port it to Android so that I can run it under the NDK, for example, it turns into a shitshow because I discover that the code depends on the quirks of the docker environment, and I need to untangle a whole bunch of issues to just get it to build on anywhere.

Containers -- dockers, jails, zones, etc -- are useful tools, but I'd rather see them left up to the people doing deployment, rather than the people shipping libraries. As a library author, I don't know where people want to run my code, so I serve them better by keeping the code portable.

A colleague predicted the problem and I learned about one more bit of random fragility that exists in today's ecosystem.

$ Docker system prune

It makes as much sense to complain about Docker because you let images accumulate in your system as it would make to criticize file systems because you never emptied your system's trash bin.

Why the hell should the very existance of unused docker images cause the single image I am using to peg multiple cores?

And no warning was given. Heck if my hard drive gets close enough to full that it's gonna be a problem my OS tells me.

Client side Babel makes sense. And packagers make sense. And it all unfortunately makes sense, but that doesn't make it good.

(Ok being able to try out new syntax with Babel is cool)