3 ms·

That's Catalyst. Dancer is Sinatra. I don't know anything about Mojolicious. Is that Node?

DASD 14y ago
Mojolicious implements whatever is trending lately on Twitter. I joke but the gist is that the rapid development is both a blessing and a curse.
tete 14y ago
Node would be POE. Just like Node is Twisted in Python or EventMachine in Ruby. So it's not exactly a new technique, "just" a new technology bringing a lot of fresh air. :) I don't think anything like Mojolicious exists in other programming languages. It's a mix of a lot of concepts, while still being standalone, while still providing everything you need and while still being fast. I think everyone that isn't forced to use something else should give it a try (maybe even reimplement something in a different language), because I never saw a quicker way to get where you want.
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.

DASD 14y ago

Mojolicious implements whatever is trending lately on Twitter. I joke but the gist is that the rapid development is both a blessing and a curse.

tete 14y ago

Node would be POE. Just like Node is Twisted in Python or EventMachine in Ruby. So it's not exactly a new technique, "just" a new technology bringing a lot of fresh air. :) I don't think anything like Mojolicious exists in other programming languages. It's a mix of a lot of concepts, while still being standalone, while still providing everything you need and while still being fast. I think everyone that isn't forced to use something else should give it a try (maybe even reimplement something in a different language), because I never saw a quicker way to get where you want.

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.