Below is a table which compares some features of the CGI::Application framework to Catalyst.
Please enhance where you see omissions or errors.
It should be noted that much of the power of working in either framework comes from modules that are popular for use both including: HTML::Template, Template Toolkit, Class::DBI, Data::FormValidator
||CGI::App current (4.0)
||Catalyst current (5.3)
||Via CGI::Application::Generator. After some initial setup, you can quickly create a module shell in your preferred style. It's not as powerful or as easy to use as it could be, but there has been little demand to improvement it since CGI::Application projects need little infrastructure.
||Built-in: catalyst.pl. It's a multi-tiered system where this script generates more scripts specific to your project, and then those scripts can be used to generate project specific scaffolding, usually mostly empty files to start with. Catalyst projects require a certain amount of infrasture in terms of files, layout and naming conventions. These tools help get these details right. Catalyst has a sub-project generate scaffolding specific to BREAD applications: Catalyst::Helper::Controller::Scaffold
||Improvements to ::Generator are underway, including generating scaffolding for BREAD applications.
|Register actions in the dispatcher at compile time
||CGI::App doesn't do this, but no one is complaining about the performance, either.
|Supported output options
||Any template system can be used with its standard interface since the only requirement is that it returns the output after the page is built. There are plugins for tighter integration with HTML::Template, Template Toolkit, HTML::Template::Expr, and Petal;
||There are Catalyst-ish Template Toolkit, HTML::Template, Mason, Petal, and PSP . and adding your own is only a few lines of code. You can also use any templating engine you want directly, although the Catalyst::View::* approach is cleaner and generally preferred.
||No specific plans.
|Each plugin is loaded in the standard clear syntax use CGI::Application::Plugin::Foo; Plugins are built using the mixin pattern which will import new methods into your namespace.
||Catalyst offers a shortcut method to load plugins use Catalyst qw/FormValidator FillInForm/; Plugins are implemented using Multiple Inheritance, and the above syntax will automatically alter @ISA for you.
||Catalyst users will say that implementing Plugins using Multiple Inheritance is cleaner, whereas CGI::Application users will say that using a mixin pattern is a cleaner method for building plugins. Both methods have their drawbacks, and both have their benefits. Also note that nothing is stopping you from using mixins in Catalyst, or using Multiple Inheritance in CGI::Application (it is merely a recommended convention).
|Compontent Auto-Discovery (Adding parts to the system based on their location rather than explicit module-load)
||Yes. The AutoRunmode::FileDelegate plugin allows you to put each run mode in its own file, so a minimum amount of code is loaded for each request. The TT, AnyTemplate and TemplateRunner Plugins all have ways to determine the template name automaticaly.
||No further specific plans.
|Easy to switch between CGI and modperl
||Yes. Using stock CGI::Application, code will often run under both without changes. The Apache plugin offers additional performance benefits for modperl with few or no code changes
||Catalyst auto-detects the environment it's running in and autoloads the appropriate Engine, so the same app can run natively as a standalone server, CGI or mod_perl app.
||With the LogDispatch plugin. It's lazy-loaded and can work as a singleton for extra performance in a persistent environment.
||A simple logger is built-in, and it obeys the Log4Perl API so any compliant logger can be loaded.
||Built-in. The environment and CGI params can be dumped as text or HTML.
||Built-In. Key objects can be displayed as text or HTML, along with query information and response time.
||More developer tools are planned or in progress, including a persistent popup to provide details about each request including DBI profiling data, response time, and HTML validation results.
||Via the Session plugin, which integrates with CGI::Session, which several CGI::App developers are now contributing to. Lazy loading is used to improve performance.
||Yes, via Catalyst::Plugin::Session which supports multiple backends for both storage (FastMmap, DBI etc.) and state maintenance (URI, Cookie)
||No specific plans.
|Debug Screen on Crash
||Yes, with the DebugScreen plugin.
||Yes. Crashes will display a debug screen showing details of relevant data structures, software and OS versions, and the line numbers of errors.
||Yes, with CGI::Application::Dispatch.
||Yes. There are multiple ways to map a URL to an action built-in.
|Suitable performance for CGI
||Yes, CGI::Application is commonly used for CGI scripts.
||No, it has a slow load time. CGI::Catalyst is in early development to address this need, but will be lacking some features.
||We are always interested in evaluating further optimizations.
||Yes. Plug-ins can mix-in methods and also register code to run at particular stages via callback, creating powerful for transparent experiences for end users.
||Yes. Plugins can perform a variety of functions, and are NEXT-driven so any request step you want can be overriden easily without callbacks, although Catalyst::Plugin::Observer provides them if you want them. Plugins are just superclasses of your app so the execution order is inherently set by the order you specify them in.
||Customizing the order of execution of callbacks is a planned feature.
||Yes, with HTML::Prototype plugin
||Yes, with HTML::Prototype plugin
||Yes, since about 5.6 although there is little documentation.
||We'd like PAR integration, too. (Drop me a note and I'll try to get you started. –Steffen Müller)