However, I wonder if it is really a good idea to recommend this module anymore. Arguments against CGI.pm are as follows:

1. The internals are a mess
2. The documentation reads more like a tutorial than a man page
3. It should only be used for basic CGI tasks, such as parsing params and handling cookies. HTML generation is right out.
4. There are much leaner, meaner alternatives on CPAN.

I'll take these arguments in the order above.

1. The internals are a mess. For starters, look through the CGI.pm code. Search for 'strict'. I did this on CGI.pm version 2.752, and all I got were a few comments. This module would take a major effort to get working under use strict. Few people would suggest using a more recent module that couldn't run under strict.

2. The documentation reads more like a tutorial than a man page. The root-level POD document for any module is inevitably going to be the most referanced documentation on that module. It should thus be written to be used as a continuing referance for people who are already familer with the module--in other words, a man page. Tutorials have their place, but that place isn't at the main module document. Doing so just makes unnecessary digging for people who want to know the specifics of how a certain subroutine works.

3. It should only be used for basic CGI tasks. This is a matter of debate, and there are many promanent Perl programmers on both sides of the issue. The argument is that all those HTML-generation subroutines in CGI.pm just shouldn't be there. Plus, they are contributing to the documentation problems mentioned in #2. Perhaps it is better than printing them by hand, but wouldn't it be even better to use a templating system?

Perhaps a templating system is overkill for a quick-and-dirty CGI, in which case we are back to either generating HTML by hand or using a module to do it for us. Even if this is the case, those subroutines still don't belong in CGI.pm. Other module exist with similar functionality (see below).

If CGI.pm were reduced to param() and maybe cookie(), most people wouldn't notice the difference.

4. Other modules exist with similar functionality. This in itself isn't a reason to dump it or any other module, but if the community were to decide to move away from CGI.pm, it is important that alternatives exist. A short list:

• CGI::Lite -- All you need for parsing basic input parameters
• Apache::Request -- Interface is the way I think CGI.pm should have been in the first place. Claims that param() method is faster than Apache's native Apache->args. Only works under mod_perl.
• HTML::Stream -- I'm not a fan of these quick-and-dirty HTML generation modules, but if you're into that sort of thing, here you are.
• HTML::LoL -- Another quick-and-dirty HTML generation module.
• HTML::EasyTags -- And another one, this one very similar to what is currently in CGI.pm.

This is certainly not an complete list. CPAN is way too big for it to be. This just lists a few of the alternatives.

Overally, I think that CGI.pm's time has passed. It is likely to be used for quite a while longer, at least until another CGI param-parsing module makes it into the core--perhaps not even then (we're still working on getting rid of Perl4 code, after all). Even so, I think it's time to recommend alternatives where it is possible to do so.

Update: Slight problem in last paragraph fixed (orginal left out "another" in second sentance WRT CGI param-parsing module).