Years have passed but Mason still stands strong! What comes to sane component-based web application frameworks with Perl embeddability there seems to be no real alternatives to Mason. Mason is very mature and the documentation is excellent (including the online book and Mason HQ). I find Mason-based applications to be more logical, easier to develop and simpler to debug than MVC alternatives. I think it is because in Mason your don't have that MVC stash variable running amok but nice components with clear call interfaces. And the best part is just to come: it's excellent to hear that Mason 2.0 appears to be under development! The early signs look very promising like using Moose under-the-hood.

Tried using a couple of well known CMS's and had steep learning curve with CSS templates and php/mysql (my background is Perl & Sybase). However they were too limiting - despite the exaggerated claims made for their addons. I decided to apply the state of the art css ideas (eg no nasty tables!) and sef ideas as well as the CMS structured approach using Mason/Perl and Linux native features (structured directories and user/group permissioning) Extracted all my old work from the CMS mysql database and within a day had site rebuilt in Mason. Couldn't believe how easy it was for a first time Mason user. Autohandler + css template is incredibly powerful with components slotting in beautifully on the pages as either raw html, hybrid perl/html, short perl scripts or pure components. Why didn't I know about this before - answer: its the CSS template that does the work - a lesson from the CMS's I looked at.

- authohandlers and inheritance make for easy modularization in layouts

- excellent support for caching: you can cache the whole output, or only the tiniest of components for as long as you want

- attributes, methods and dhandlers: you won't fall in love at first sight, but those cuties will make any other templating scheme look dull after a while

- very helpful if you're into using active widgets; HTML::Mason will let you build components that can take care of all their data needs: for example, just build a calendar widget, have it 'use' whatever classes it needs, call it where you need it, optionally pass it some parameters to help it be a bit more useful, and you can forget about what is inside until you need to change it.

- the templating syntax is perl syntax with a couple of HTML-looking tags; that the designers should not need to learn/should be shielded from a programming language is a superstition, I think: it's impossible to have a useful templating scheme without some syntax that the designers will have to learn and deal with, and if they are going to learn a syntax, it could as well be basic perl.

- I am not certain that this was planned, but because it does not integrate with DB abstraction classes or session handling classes etc. and does not deal with anything else but with Controller and View tasks, it helps you _a lot_ to deal with obsolescence, since you can simply use your old Model/DB classes without any problem and replace them in time, and still have an application to run your business on

- for simple applications is very easy to switch from cgi to mod_perl and back; for more complex application it's possible to switch from cgi to mod_perl and back without rewriting the whole application; the same for switching from mod_perl to mod_perl2

- you can use it as a templating engine or as an application framework

- good documentation and helpful (and polite, too: have not been witness to any flame fest in the mailing lists until now) community;

extra pro arguments:

- in some situations it might give you good arguments to ask the management to fire the designers that are unable to set Dreamweaver aside and keep polluting the pages with the inane DW generated javascript.

- if your team lead is in love with a particular DB abstraction scheme, s/he cannot use the argument that "HTML::Mason has support for the xyz::class"

- since the dispatch is filesystem based, you can keep the code in small files and if you bork a merge most of the application will still work

- no support for mixing SQL in the template files, so if you manage a project, you don't have to carry a baseball bat with you all the time

- used by Amazon.com: this means it will be actively supported for a some time

con:

- it's not exactly trivial to extend, and the documentation could be a bit more detailed as to what is appropriate to extend

- it is not exactly trivial to share information between arbitrary components; there is $m->notes(), and you can store even objects in that, but I am not yet certain that's a good idea: maybe the documentation should state if it's fine to do it or not

extra con arguments:

- you still have to carry a big baseball bat with you in case some team member is tempted to pass the Apache request object or the Mason request object to some code that's not in the <%init> part of the component and argues that "it's much simpler this way"

- it's not very hyped: in my experience, having HTML::Mason in your CV won't bring you points unless the job description contains "HTML::Mason"

With Mason you can do with your layout code (the templates) what you do with your normal code all the time: restructure every snippet that occurs to be reusable. Masons well-thought component API allows you to do this in various ways: with OO like inheritance, function or macro like calls or just "classical" template including.

There is syntactic sugar everywhere, exactly when you just realise you could need a feature there. Example is the filtering of output with or without entity encoding.

For web programming I prefer Mason over Template-Toolkit (which in turn I prefer for strange text templating, so it's no criticism of TT).

The only thing that I don't like is its prerequisite to Apache::Request which in turn tries to install libapreq which in turn is, depending on the OS, a "challenge" (to avoid the word "problem") for itself and practically everytime better installed with the OS distribution tools or by the sysadmin. I don't know why this dependency is set because Mason can be used without Apache or mod_perl, e.g. with Catalyst. Maybe a historical legacy. I would like to see that coupling divided.

Another thing that might take some time is to customize you editor for mixing highlighting of Mason/HTML and Perl syntax. At least with Emacs it kept me awake some time to fiddle with MMM-mode.

Mason is a well engineered framework and templating system on which you can build powerful web applications. The documentation is excellent, the system is feature-rich, reliable and well integrated with Apache/mod_perl. You can also use it with CGI and non-web scripts.

In my experience, Mason works well when your templates are built and maintained by Perl coders. If you want a system that allows non-programmers to edit templates with their GUI tools then you might be better off looking at Petal or the Template Toolkit.

HTML Mason is a templating system and more. Focused on web site developement it has templating, caching, debugging, and more. It's large. It also lets you put together big sites quickly, component(HTML/Perl chunks) by component.

Nice, Flexible, and BIG. More of a platform than a module. But highly recommended for putting large component based sites together.

Mason is a wonderful application development system. When coupled with mod_perl, it's unstoppable. My only issue with it is the embedded perl. This is not optimal for situations where the HTML people are not programmers. But for all the rest of us, I highly recommend this module set for all your WWW needs.

Mason is a really great tool for building large, dynamically-generated web sites. It is very customizable, and its features like autohandlers, inheritance, and dhandlers reduce the redundancy and increase the maintainability of sites.