Hi Marc,
As the author I'm obviously biased, but I'll give you my take on the three key
differences between Poet+Mason and analagous combos, e.g. Catalyst+TT,
Dancer+TT, and Mojolicious.
1) Builds upon the best of CPAN
Poet+Mason depends proudly on Moose and Plack/PSGI (as well as a few other
best-of-breed CPAN distributions). Being able to depend on the presence of
these powerful modules means that we get quite a lot for free, and can focus on
interesting features instead of reinventing the wheel. Mason components compile
down to Moose classes. Mason and Poet plugins are Moose roles. Poet freely
takes advantage of PSGI middleware and uses the Plack::Request/Plack::Response
objects as a base request/response API. There aren't separate branches of code
or feature sets or documentation for Moose/non-Moose users or for PSGI/non-PSGI
users.
In contrast, Dancer and Mojolicious are proud of their lack of dependencies,
because it makes installation easier; true enough. But this means a lot of
wheel reinvention and divergent usage patterns depending on what is present.
Dancer, for example, invents its own before/after hooks and its own base
request/response API. Mojolicious, with its zero dependency promise, has to
reinvent everything for its baseline behavior.
Some people do seem afraid of the cost of Moose installation and of largish
installation chains in general. So for them, the lack of dependencies is an
advantage. My feeling is that tools like local::lib and perlbrew and cpanm and
Pinto and Carton make it increasingly easy to control the Perl and CPAN
environment that your application uses (with or without root access), so why
not depend on the best?
2) Perl-based template language
Mason does not attempt to invent a new programming language syntax for
templates. It is just Perl, wrapped with just enough extra syntax and features
to facilitiate templating. Mason components compile into Moose classes in an
obvious way.
This gives Mason templates enormous power (whatever Perl can do, Mason can do)
and just as importantly, predictability - if you know Perl and Moose then you
know how your components will behave, and if you forget how a piece of Mason
syntax translates, you can just look at the compiled class or walk through with
the Perl debugger.
In contrast, TT is really is a separate language that you have to learn and
understand. It is well-designed in some aspects, but is undeniably (and
intentionally) weak compared with Perl and has a number of well-known quirks
(e.g. with variable scoping).
One purported advantage of TT over Mason is that it is friendlier for
non-programmers (e.g. designers). Another is that its weakness as a programming
language is actually a strength, in that it encourages you to put complex code
into Perl classes.
The paragraphs above apply equally to HTML::Template, except it is even further
along the intetionally-weak/quirky/designer-friendly spectrum.
3) Combined controller and view
In most frameworks the controllers and views are strictly separated. A
controller gathers data from appropriate model(s), then constructs a hash of
data and passes it to a template to render the page.
In theory the controller method and template are decoupled, so that you could
create multiple templates for a single controller method (one for browser, one
for mobile, etc.).
In practice, you almost never do this; there is one template per controller
method, and the two *are* quite coupled. If you want to figure out how a page
is rendered, you have to look at both the controller and view. If you want to
change how the page is rendered in any meaningful way, you have to modify both
the controller and the view. So with Catalyst development you constantly having
to look in, and edit, two places at once. You also have more decisions to make
about which code goes where.
In Poet+Mason, it's very clear which component handles a URL, and that
component contains both the controller and the view. You only have to look in
one place and modify things in one place, and you aren't wasting time packing
and unpacking a stash in between two coupled pieces of code.
Catalyst and MVC devotees would say that the separation between C and V is
valuable, to ensure you aren't "doing too much" in templates. Whether this
applies when said templates compile to full OO classes is less clear.
Hope that helps!
Jon
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mason-users mailing list
Mason-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mason-users
