3 ms·

Mojolicious starts out as Flask/Sinatra, with some added options to grow beyond that. It does pride itself as a batteries-included, modular framework. And one

by mhd 14y ago

Mojolicious starts out as Flask/Sinatra, with some added options to grow beyond that. It does pride itself as a batteries-included, modular framework. And one that doesn't pull in loads of dependencies. Which I can appreciate on one hand, on the other, you do reinvent a lot of stuff that would be on CPAN. (But, well, looking at the dependency list of Moose alone…)

autarch 14y ago
I really don't understand where this oft-repeated FUD about Moose having a lot of deps comes from. Take a look at the list of deps on https://metacpan.org/release/Moose https://metacpan.org/release/Moose I count 18 direct dependencies, 2 of which are core. If you look at the full expanded deps list at http://deps.cpantesters.org/?module=Moose http://deps.cpantesters.org/?module=Moose it's not many more, especially since most of the 2nd (or more) order deps are core modules like ExtUtils::MakeMaker, Test::More, etc. For extra added irony, a bunch of the Moose deps are tiny modules we extracted from Moose or Class::MOP in order to make their functionality availability _without having to install Moose_. This includes Class::Load(::XS), Package::Stash(::XS), Devel::GlobalDestruction, Package::DeprecationManager, Eval::Closure, and Dist::CheckConflicts. Had we just note bothered to break things up we'd have to deal with a lot less complaining.
- mhd 14y ago
  18 isn't "lots"? I'm not saying that I've got a problem with this, as installing CPAN modules and deploying them isn't really a problem at all. I think in the end it's probably the wrong decision to avoid using features just because of something easily automated. I just meant that I can understand the desire. We programmers try to make code clear and concise (hopefully), so that we can better keep the system in our heads. Apply this on a larger scale, and you often get reinvented wheels and proprietary solutions. "Other people's code" is often used as a curse. Hey, my day job involves Catalyst and Moose heavily, and I wouldn't ever want to go back to enterprise Java. So if I came of as "fuddy", I'm sorry.

by mhd 14y ago

autarch 14y ago

I really don't understand where this oft-repeated FUD about Moose having a lot of deps comes from. Take a look at the list of deps on https://metacpan.org/release/Moose https://metacpan.org/release/Moose I count 18 direct dependencies, 2 of which are core. If you look at the full expanded deps list at http://deps.cpantesters.org/?module=Moose http://deps.cpantesters.org/?module=Moose it's not many more, especially since most of the 2nd (or more) order deps are core modules like ExtUtils::MakeMaker, Test::More, etc. For extra added irony, a bunch of the Moose deps are tiny modules we extracted from Moose or Class::MOP in order to make their functionality availability _without having to install Moose_. This includes Class::Load(::XS), Package::Stash(::XS), Devel::GlobalDestruction, Package::DeprecationManager, Eval::Closure, and Dist::CheckConflicts. Had we just note bothered to break things up we'd have to deal with a lot less complaining.

mhd 14y ago
18 isn't "lots"? I'm not saying that I've got a problem with this, as installing CPAN modules and deploying them isn't really a problem at all. I think in the end it's probably the wrong decision to avoid using features just because of something easily automated. I just meant that I can understand the desire. We programmers try to make code clear and concise (hopefully), so that we can better keep the system in our heads. Apply this on a larger scale, and you often get reinvented wheels and proprietary solutions. "Other people's code" is often used as a curse. Hey, my day job involves Catalyst and Moose heavily, and I wouldn't ever want to go back to enterprise Java. So if I came of as "fuddy", I'm sorry.