[sf-perl] All these Perl web frameworks
bryan at beeley.org
Thu Aug 2 10:17:33 PDT 2012
On 08/01/2012 01:39 PM, Joseph Brenner wrote:
>> Catalyst- http://www.catalystframework.org/ - grandaddy of the big
>> active frameworks? Lots of modules / flexibility?
> Yes, I think that's about the size of it.
I have used Catalyst extensively, and would definitely recommend it. It
is a huge memory hog though. I would also recommend you take advantage
of copy-on-write as much as possible (load as much as possible into
memory before forking child Catalyst processes).
>> Mojolicious- http://mojolicio.us/
> A lot of us seem to agree that Mojolicious is a scary project.
> They're main feature is they've reduced external dependencies, but
> that means they've re-written a lot of stuff from scratch themselves.
I don't know much about Mojolicious. I was on their mailing list for a
while though, and it didn't seem like things were moving very fast.
>> Dancer- http://perldancer.org/
> I've got a vaguely positive vibe about dancer, though at this point I
> can't remember why... I gather Catalyst is more configurable.
I have heard that Dancer is nice and much lighter weight than Catalyst.
Probably better for quick, simple projects where Catalyst would be
overkill. I haven't had any direct experience with it though.
>> Poet- http://search.cpan.org/~jswartz/Poet-0.09/lib/Poet/Manual/Intro.pod
> I would say that Jonathan has a good point that while the various
> MVC-style frameworks talk-up "separation of concerns" really the
> pieces end up being pretty tightly-coupled, and you have to keep
> making parallel changes everywhere.
As with a lot of things, I think there are a lot of design decisions
that can be made to keep things more separate. What worked for the last
big project I was on was to move all the code dealing with the model
into a Form object (we use HTML::FormHandler). This makes the
controllers very simple, and allows you to test your forms separately
from your Controllers. Assuming you will be using DBIx::Class, you can
help to keep things less tightly-coupled by putting any complicated
searches into custom ResultSet methods. Doing so makes it more likely
that you will be able to make model changes without having to touch code
outside of the model.
> Also, using Mason by default appeals to me more than TT, it feels much
> more perlish.
I feel like using TT is great because its is too simple to do anything
too complicated well but flexible enough to allow you to make most pages
work when only passing in a form object -- encouraging more separation
More information about the SanFrancisco-pm