Having a solid HTTP abstraction with IOC capabilities and a standard component API is important – and CGI::App’s plugin system is a lot more limited than the many places you can override, tweak and extend Catalyst.

Catalyst doesn’t just have lots of extensions because everybody uses it – it got many of those users because there were plenty of clean ways to make those extensions in order to build your application base up towards the problem in a maintainable fashion.

The way I see it, CGI::App is (intentionally) a microframework; Catalyst is more a metaframework. So for an application of … half a dozen pages? CGI::App may be the best choice to minimise the amount of code loaded, but for a larger app you usually end up taking advantage of enough of the features of Catalyst to make it worth starting there.

With Catalyst 5.8 and Moose, this has got undescribeably powerfull (although I’m trying to work up to showing some really cool use cases in my blog).

As a simple case, if you have a CRUD system, then attaching standard view/edit/delete uris (and associated processing) should be as simple as:

with qw/MyApp::IsViewable MyApp::IsEditable MyApp::IsDeleteable/;

sub item : Chained(‘/’) PathPart(‘thing’) CaptureArgs(1) {
my ($self, $c, $id) = @_;
$c->stash->{item} = $c->model(‘Db::Thing’)->find($id);
}

and this gives you:
/thing/ (GET to view)
/thing/ (POST to edit)
/thing//delete (POST for web)

You can add extra custom actions to the URI space of ‘thing’ just by including them in the code above – but the basic elements of your web interface are really really to write once, and then just reuse..