As mirod says, there's Catalyst (http://dev.catalystframework.org/wiki/), which by all accounts is a modern Web framework. It happens to follow the popular MVC model. There are also others to look at if Catalyst doesn't tickle your fancy.

There's also Jifty (http://jifty.org/view/HomePage), which I understand to be somewhat Rails-like. There's a focus on things like DRY (don't repeat yourself), form-based dispatch, and continuations.

Then there's HTML::Mason (http://masonbook.com/), which allows a bit of a PHP feel if you like that sort of thing, but with the power of Perl. It's been called mostly a template framework with some other web-aware pieces, but big web applications have been written using it. It can be used as just the templating part and even inside another framework.

I hear more and more about the Mojo web framework framework and one of the sample frameworks for it called Mojolicious (http://mojolicious.org/) as time goes by. I'm guessing that means it's gaining popularity at least with a few anecdotal groups. The website says Mojo focuses on a clean object orientated API, code generation, supporting the creation of more specific web frameworks, and the ability to run under lots of constraints. It offers its own HTTP server, runs under CGI with another server, or runs as FastCGI^*. Mojolicious is an MVC framework built on top of Mojo as a fully functional working example.

Maypole (http://maypole.perl.org/) is another MVC, this time similar to the Java framework Struts. A main focus is to give an easy path from web page to a database and back to the web page. The authors claim it is able to provide a fully featured interface to a database in under 20 lines of code your custom code, yet still be flexible enough to handle everything else a web site needs.

I don't hear much about Gantry (http://www.usegantry.org/) on PerlMonks, but it has an impressive checklist of features. It offers built-in CRUD support, explicitly supports user authentication and sessions, performs code generation, has a plugin architecture (and a number of plugins ready to go), generates and validates forms, it has a self-contained mode (including using HTML::Server::Simple to serve the application on your local machine) for rapid local development, and even that supports three different databases (PostgreSQL, MySQL, and SQLite). It runs under CGI, mod_perl, or FastCGI^*. You really need to see the 3-minute movie of the application and database generation, updates, and testing that's featured on the homepage before you make a decision about a framework. It has a little bit of a minilanguage of its own on the command line, but a simple multi-table CRUD database interface can be written entirely in one command line.

There's CGI::Application (http://cgi-app.org/), which as the name implies is meant to support applications running on the Web. It is mostly a persistence controller/dispatcher^** framework alongside which you can build your model and view^**. It has plugins so you can include extra code for extra needs, though, and the website lists many other modules that can work in conjunction with it. It even lists examples for using things like CGI::Ajax and DBIx::RecordSet with it. There are also fuller frameworks built around it or fashioned after it.

One of the frameworks derived from CGI::Application is Titanium, which is basically CGI::Application and a standard set of plugins and a bit of interface around it all. It offers lazy loading of its plugins. It runs under CGI, FastCGI^*, or mod_perl.

Combust (http://combust.develooper.com/) is an MVC web framework and CMS rolled into one, with Subversion support for documents, a caching mechanism, and automatic POD to HTML conversion and formatting. It's used at http://perl.org and it sounds handy to any Perl programmer for some of those features. I hear it has rough docs, though, including from the CGI::Application website.

There are probably a number of these (if not all of them) that can support your site development well. Some of those listed are quite popular while some are more obscure. I've tried to make a note of my understanding of the place of each in the community as well as in the scheme of features and style of use. I haven't used most of them for serious work, though, so you might want to follow up with questions to the Monastery about the ones you find interesting.

^* FastCGI is a popular cross-language standard for persistent web programs that under Apache uses mod_fastcgi. There are also FastCGI implementations for many other web server packages. FastCGI programs run separately from the web server and talk to it over sockets. Some, but not all, web hosting providers are more willing to install FastCGI than mod_perl.

^** Updated as per discussion with perrin. I'm convinced I placed the wrong focus on CGI::Application the first time around.

I wouldn't say CGI::Application is a persistence framework. It's a simple tool for writing MVC apps.

Parts of this may be me repeating the misunderstandings of others. Part of it may be from reading dated material, as CGI::Application has been around much longer than some of the other frameworks and has undoubtedly had more updates and maintenance done to it. Part of it may be that I'm just focusing on the parts that seem to differentiate one framework from another a bit too much where they're otherwise similar.

The core of CGI::Application itself, without the plugins, though, really seems to me to be the state machine for the runmodes, the hooks to plugins, the wrappers to template modules you could use in any other framework or without one, and not much else. I thought that was the point. The Session, Authentication, BREAD, and DBH plugins don't even come as part of it.

More accurately than a persistence framework, it might be called a controller framework as the very core appears to be a dispatcher with a lot of hooks. A controller is certainly a good start at MVC, but it's not offering to generate the model or the view for you like some of the other frameworks do. That sort of simplicity it seems is the point. I can't imagine many applications being written with CGI::Application that don't also use some combination of CGI::Application::Plugin::Session CGI::Application::Plugin::DBH, or HTML::Template (which can be used with any framework or without a larger framework), though. Most of the others would be, by the philosophy of customizing the framework for the application espoused on the website, only used (and thus often only installed) if a site is built to use them. That's great if you have the authority to install modules as you want or you can tell your hosting company you want every plugin you may ever use for CGI::Application. It could be a real hassle, too, compared to some of the more comprehensive frameworks getting installed once.

For some idea of where I'm getting ideas about CGI::Application, take a look at these: the plugin page, Titanium, this Perl.com article, the Perl5 Wiki entry on CGI::Application, this earlier Perl.com article praising CGI::Application over Mason and other tools that use separate files for separate parts of an application, the descriptions of other web frameworks according to the CGI::Application team in comparison to their own work, and the breakdown of features and implementation vs. Catalyst (notice that CGI::Application uses plugins for most of that).

It particularly intrigues me that one of the big selling points of CGI::Application according to some of those sources is keeping all the code in one file. That's a horrible way to develop a large application IMO. There is among CGI::Application proponents some bashing of PHP, ASP, Mason, and other tools for necessarily going to the other extreme of having every function of an application in a separate file which isn't even true. I don't see why major sections of functionality can't be located separately on disk for the sake of organization, with each subsection generating more than one page out of a related set of pages for the viewer. If making the logic of the application one big collection of run modes in a single file is a selling point, I for one am not buying.

Then there's HTML::Mason (http://masonbook.com/), which allows a bit of a PHP feel if you like that sort of thing, but with the power of Perl.

Isn't it PHP that has a feel (a little) like Mason?

Mason is my personal pick, by the way. My guess is this whole ORM thing is yet another fad that's going to blow over (caveat: Object-Oriented Programming struck me the same way).

Catalyst, Catalyst, Catalyst.

• SQL abstraction
  • All data level interaction is abstracted in Catalyst in a way that it's not in, say, RoR. You can use any SQL kit (most choose DBIx::Class but Rose::DB is also popular), you can use anything as your model and you can have as many models in your app as you like; from Berkeley to CSV to webservice calls to IPC::Run wrappers on other tools.
• Multi-language support (e.g. via templates)
  • Yep. Though I'm not versed in this, many folks are doing it and there are at least two major il8n kits in Perl and views in Cat are like Models. You can have as many as you like and they can be anything you like.
• Support for basic mechanisms like user sign-up, sessions
  • Mostly. Sign-up will never be completely abstracted except in tied-down frameworks because if you ask 5 devs what constitutes a user account, you'll get 10 answers.
• AJAX abstraction
  • Same as the view. There are some ready-made pieces but you might have to write your own JS if you're serious about it. The view stuff in Cat can be amazing. The same method/URI for example can return JSON, XML, HTML, YAML, whatever, based on the accept headers the client has sent.

It would be a plus if the system would run (albeit slowly) under CGI as well, which would enable me to prototype it on my current host first without having to find a mod_perl server.

Even better it has several engines including one that runs as a persistent (test) server with immediate, automatic restarts on code changes. You could use it on some hosts but developing on a live server is usually a mistake. Just do it at home. It's faster, easier, and more fun. If you follow best practices with your Cat stuff it will also be easy to deploy anywhere else. Since RoR is gaining popularity, many more hosts support fcgi than used to. Cat apps run great on it. A small one might be bearable on CGI but you want fastcgi, mod_perl, or the test server (some folks are running it in personal production set-ups).

Cat is 4, maybe 5, years old, I think. I've been using it for most of that time. It's not trivial to learn how to use it but once you do, writing web apps with it can become so.

That would be Catalyst I believe.

You have your list of choices. You can search for more, but the main point here is, choose what fits you best.

This may be common knowledge, but it's the absolute truth.

If Catalyst fits you, by all means, use it. I will condone it to no end, I will develop it as long as I'm able, and I will continue using it as long as my fingers are able to type. However, this doesn't mean that you *have* to use Catalyst. This doesn't even mean you have to use a perl framework. Some people are completely content with Ruby on Rails. I have my disagreements with it, but hey, if you can learn it inside out, and it matches your train of thought, God bless.

Try out a few, and see what really fits you. I've tried others, and found myself coming back to Catalyst each and every time. You'll be able to find the framework that's right for you in the dark, blindfolded.