Every dependency you add is a bet. You're betting that the maintainer will keep it updated, that it won't introduce breaking changes at the worst time, and that its goals will keep aligning with yours. Sometimes the bet pays off. Often, it quietly becomes tech debt.

What you actually need

Most websites need very little tooling. A static site generator to turn templates into HTML. A way to write CSS. Maybe a build step for optimization. That's it.

When you reach for a CSS framework, ask what it gives you that a few dozen lines of custom CSS wouldn't. When you consider a JavaScript library for a simple interaction, ask whether a few lines of vanilla JS — or no JS at all — could do the job.

The cost of convenience

Dependencies carry hidden costs:

• Security surface area — every package is a potential vulnerability
• Update burden — dependencies need maintenance even when your code doesn't change
• Build complexity — more tools mean more configuration, more failure modes
• Cognitive overhead — every abstraction is something new contributors must learn

A practical approach

This doesn't mean avoiding all dependencies. Eleventy is a dependency, and it's worth it — it does something genuinely complex (static site generation) far better than I could build from scratch.

The principle is simple: use dependencies for things that are genuinely hard, and write your own code for things that are straightforward. CSS layout, typography, and spacing fall firmly in the second category.