Dependencies Run Deep

From the “get off my lawn” department.

I start a new Python web project using a popular “modern” template.

Immediately after creating the project, the top-level directory includes .babelrc, .bandit, .bootstraprc, .coveragerc, .editorconfig, .env, .eslint.ignore, .eslintrc.js, .isort.cfg, .pre-commit-config.yaml, .prospector.yaml, Makefile, Pipfile, Procfile, app.json, package.json, postcss.config.js, runtime.txt, and three different webpack.*.config.js files.

There are 47 direct Javascript front-end dependencies and 28 direct Python back-end dependencies. The out-of-box Webpack configurations run to hundreds of lines long and utilize half a dozen plugins. I shudder to consider how many transitive dependencies there are.

This feels broken in a way I can’t quite put my finger on. I accept that we’re long past the day when, to start a new project, we needed precisely two dependencies: the Commodore 64 Programmer’s Reference Guide and the Merlin Assembler. But I don’t accept that this complexity and layering, especially with its typical paltry documentation, is at all manageable for the average developer. I’m not convinced that it’s manageable for any developer, including the developers who created the template itself!

Yes, the substance of programming has changed radically since the days of the 6502. Then, the art was to understand the machine and coax it to do useful things despite its limitations. Today, the art appears to involve stringing together black boxes in endless new combinations, hoping to arrive at utility that outweighs the mental and operational overhead imposed by those boxes.

If that is indeed today’s art then I believe we’re far from finding an aesthetic that makes it meaningful.