Re: Mason advantages

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users