The dependencies.
prototype in Mojolicious::Lite then grow it into a Mojo app later on
if the project needs it.
i run both and prefer mojolicious over catalyst quite a bit especially
for quick prototyping. i repeatedly wrote minimal viable products in
the course of a weekend and even though i know catalyst quite well, i
am never that fast with it for some reason.
play with Mojolicious::Lite for a day or two and you'll see what i mean.
cheers
lenz
--
twitter: @norbu09
current project: iWantMyName.com
On Mon, Mar 5, 2012 at 8:58 AM, gavino <gavc...@gmail.com> wrote:what are main differences?prototype in Mojolicious::Lite then grow it into a Mojo app later on if the project needs it. i run both and prefer mojolicious over catalyst quite a bit especially for quick prototyping. i repeatedly wrote minimal viable products in the course of a weekend and even though i know catalyst quite well, i am never that fast with it for some reason.
I started out using Catalyst ~6 years ago. Moved to Mojolicious last
year. I liked Cat for many things, but it got progressively harder to
use for a number of reasons.
1) Dependency radius, which immediately impacts deployability. Mojo is
relatively self contained, very little extra stuff, very few things to
break on you. Catalyst is large, many moving parts, often somewhat out
of sync, and stuff breaks regularly (one of the hardest problems for us
was maintaining an exactly functional working environment in Catalyst)
2) Performance. Catalyst was fast, then they started building it upon
Moose. Moose isn't fast. And we run some very fast CPUs, with lots of
RAM.
3) Speed of development. One of our products uses a very
simple/straightforward Mojolicious::Lite app as one of the major
components. Rolling this app, took less than a day, in toto. Compare
this to the roughly 2 month long session I had with Cat trying to get it
to do exactly what I wanted.
Honestly, I like the whole concept behind Mojolicious::Lite more than I
do behind the exploded view of an app. With M::L, deployment is, and I
really mean this, trivial. There is no dependency hell to deal with. I
can debug the app in Komodo (I have this up in the background now as I
work on creating a sane Login system for an app that we are going to
reuse everywhere).
This is not to say Catalyst is bad. It isn't. It solves a specific set
of problems in a particular way. It does a good job of it. Its just
not the right tool for us, as it evolved in a different direction than
we needed.
There is also Jifty, and while I like quite a bit about Jifty, it makes
Catalyst's dependency problem look like a minor irritant. The
Jifty::DBI code is IMO exactly the right way to handle DBI interfaces.
--
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics Inc.
email: lan...@scalableinformatics.com
web : http://scalableinformatics.com
http://scalableinformatics.com/sicluster
phone: +1 734 786 8423 x121
fax : +1 866 888 3112
cell : +1 734 612 4615