Counter-productive over time
Ovid wrote a post recently on an unexpected result of Mojolicious' "no dependency" policy.
I won't go into the horror stories of people getting yelled at for saying Mojo doesn't support dependencies. Instead, I'll give my opinion on the concept of no dependency, and you could decide for yourself if it relates to Mojolicious or not. I honestly don't care. Obviously, this is not a "don't use Mojolicious" post. In fact, I think it's a cool framework and you should try it out. This post is about my general opinion on the "no dependency" idea. Mojolicious is an example, DBI is another, and there are definitely others (Moose, anyone)?
The whole "NO DEPENDENCY HEAVEN!11" approach to me seems like the PHP "we embedded the code in your HTML!11" approach. Basically, doing something that tries to handle the current situation but in a way that actually ends up counter-productive when technology advances.
Back in the day, web code printed out HTML code. That was horrible. CGI.pm tried to alleviate it by suggesting using functions instead of hardcoded HTML tags. It wasn't much better. Then PHP came along and said "hey, let's just embed the engine code inside the design code!" - everyone was happy. Then we realized HTML coding is actually outside the scope of engine coding (and vice versa), so they were separated. We created templates and had engine code render them using variables. Neat! But now PHP is actually an HTML document that only opens a PHP tag, that runs code that opens a different HTML document, which is an HTML template, and renders it to HTML. That's how all PHP applications are. Suddenly it ain't cool no more. Suddenly it's stupid.
The "no deps" camp (whether in a web framework or elsewhere) tries to handle a similar problem (which is actually temporary, and constrained by technology and willingness), which is the ability to include additional code. It's hard to change willingness (a point which Ovid expresses eloquently), but technology is more manageable. Including dependencies is no longer a hassle: you have local::lib, FatPacker, Carton, cpanminus, perlbrew and Plack. Nowadays, including additional code is actually very easy. In fact, some technologies (such as cpanminus, perlbrew and local::lib) made it extremely easy to install new code instead of bundling it. But hey, you can do both.
Mojolicious is one of the few projects that have such a skilled core team (and lead developer) that they actually can rewrite the entire core, including any required dependency from scratch, and do a damn good job. Unfortunately, this is not the case with most other developers. In fact, even very skilled developers (and there are a ton in the Perl community) prefer not to spend their time rewriting something that is already (possibly, plausibly, probably) well-written, even if they can do an incredible job at it.
This lays the beginning to the consequence Ovid mentions: people are learning from the "zero-dependency" concept to be zero-dependent. They actually start to abhor dependencies. I've seen people coming from that camp try to rewrite DBI. Yes, I really did see it. It was horrible and expectedly it failed.
So what does zero dependency really means? To me, it means you either don't support a lot of features, or have numerous possible bugs, or have rewritten a lot of things, or you don't know how to bundle your stuff, or don't know how to setup Pinto (or you don't understand the reasoning for it), or you don't understand the idea of reusability, or that you're incredibly arrogant thinking you can do better than everyone (and frankly, a few can), or... well, a lot of things which are generally not good practice, by any fair standard.
I honestly don't intend to work on projects that require me to use zero dependencies no matter what. It's a serious - in a term Ovid proliferated - code smell.
Remember, the excuses of "I don't have permissions to install new modules" or "I can only upload stuff here" are no longer relevant since we have tools to bundle stuff, pack them, install them locally and more. Those situations are no longer a problem.
In short: with time, technology changes, and we should have an approach that isn't locked on a certain approach that might change as technology advances.