It's been great for quickly putting together something simple and functional. It's reasonably fast if used with mod_perl or the like. And supports persistent database connections etc (essentially in any page you specify something to run once per initialisation, and then the rest of the page/code to run on every render). The autohandler support (a page or code that runs every time any page in a directory is loaded) is useful for setting up things such as sessions, or header/footers.

The downsides are that it's difficult (and I've never gone to the effort of discovering exactly how) to run a debugger on a broken page. I've always reconciled myself to merely use the Perl warnings and manually inserted tracing (print statements) to keep track of what is actually going wrong.

A lot of people don't like Mason because there is very little separation of code/presentation. However the truth is that Template Toolkit muddies these waters too.

On a side note I have been able to get Mason working on a large virtual web hosting provider in the USA - where they only provide CGI support. Because they use large powerful servers and throw a stack of accounts on them the "slow" CGI response is not actually that slow.

Thanks, you actually had real experience with Mason, which was helpful

>> The downsides are that it's difficult (and I've never gone to the effort of discovering exactly how) to run a debugger on a broken page.

I've noticed one issue which occurs when there is a failure in a dependent module from "use" (not the first level include in, say the .html component, but a secondary module). It gives a very generic "failed to load" name-of-primary-module. You could find this by having a dummy program which loads the same modules, and invoke it from the command-line to find these problems (but it is odd Mason doesn't find them).

I've also noticed a little weirdness with the caching when there is a failure in a unit to compile. Things get unhappy, and well, you just have to restart Apache. The only way to know this is you get this odd feeling that not all is right with the world.

If you follow the Very Good Advice of keeping most of your non-display code in external libraries and you run under mod_perl, make sure you fully stop&start apache whenever you make a change, to ensure you see the results.

Consider developing in CGI mode (no mod_perl,) with a single apache process, with code_cache_max_size => 0 (disabled, no caching) to avoid some such weirdness and speed development.

From its docs:

Template::Alloy represents the mixing of features and capabilities from all of the major mini-language based template systems (support for non-mini-language based systems will happen eventually). With Template::Alloy you can use your favorite template interface and syntax and get features from each of the other major template systems. And Template::Alloy is fast - whether your using mod_perl, cgi, or running from the commandline. There is even Template::Alloy::XS for getting a little more speed when that is necessary.

I second CountZero and perrin. I've started using Template::Alloy lately and I really like it so far. Mason is a solid, widely used, powerful kit. It's also the closest in style to PHP. This is what perrin was warning about, however. PHP style is generally terrible. (Perl can be, and too often is, coded this way too but PHP presents it as the first avenue so that's where most folks drive.)

The moral there being, if you prefer that style, go for it. If you are hacking big stuff however, you will find that at least some near MVC or hybrid of it with concerns separated as cleanly as makes sense gives you a lot more time to have fun and requires a lot less time debugging, shimming in noodles, and cursing the day you thought to yourself, "Oh, I'll just do it this way, it'll be faster since I already know it."

You can use Mason, any view or combination of them at all, with Catalyst too.

“shimming in noodles...”

:-D   I'll have to remember that one!

Sorry, I can't seem to do good writing...

I'd say, don't limit yourself or tie yourself to a specific thing if you can. There's lots of great stuff that can help out at different levels. I was just poking at CGI::FormBuilder yesterday, and was really impressed. Template::Toolkit is awesome. You can probably blend all of these and more with Mason.

You'll never build the perfect thing, so leave wiggle room. That's my $.02.

I used mason for my own projects and PHP at my day job. What I miss most about mason syntax is being able to layer content and control structures. In PHP, once you open a tag you are writing code until you close it (HEREDOC and NOWDOC being poor exceptions.)

As for a framework (which is another ball of weasels) inheritance from autohandlers in mason makes site structure code re-use dead simple. I assume there is a PHP framework that does something similar, I just haven't looked very hard. Some people like to use mason for rendering/layout inside other frameworks (Catalyst, Bricolage, etc,) so this should be another point to consider.

Multiple inheritance, closures... my list goes on, but that's all more general PHP vs Perl.

If you're doing a Javascript-centric website, the back-end support is often “fairly light, anyway.” These days, it mostly consists of RPC-call handlers and a persistent session-store... and of course, queries from some SQL database or another.

The best approach is probably to map-out your intended site very carefully, then look over the various Perl-based offerings to find the one that gives you the most coverage at the least cost. This may or may not be (likely won't be...) a direct parallel to “the way that PHP does it.”

My experiences with Mason (which I like quite a bit):

If you're careful with your coding style, it's not too hard to achieve a separation of perl and html with Mason. You can write Mason components that seem like html to the html monkeys, so they don't feel disenfranchised. As other people have mentioned, keeping as much of your code as possible in modules is key -- for one thing, it makes it very easy to write stand-alone tests of the code.

Just working on projects on my own, I feel the strong temptation to move all the content into the database, so I end up writing very few mason components -- you can do a lot with an autohandler and a dhandler and a header and footer component.

Of course, the down side of working this way is you're also going to need some CMS-features to edit the content in the database, and how much time do you want to put into reinventing Bricolage? Bundle::Bricolage

Some technical hints:

Take a few minutes to wrap your brain around the "autohandler" and "dhandler" concepts. A "dhandler" is called if the request doesn't find what it's looking for, an "autohandler" is called after something is found, but before evaluating it. A typical request cycle for me is a request comes in for something that's not on the filesystem, so the dhandler takes it, then Mason backs-up and finds the autohandler, which calls my header component, then does a "call_next" to insert the material returned from the dhandler, after which the autohandler calls my footer component to finish the generated page.

By the way, getting Mason to deal with empty directories correctly is a minor headache. I strongly suggest reading this page from the wiki: HandlingDirectoriesWithDhandlers