When should I use Perl CGI instead of PHP (or vice versa)?

Question

For hobby purposes, I have a shared space on a hosting server that is providing, as many of them are, both PHP and Perl CGI. I have read on several places that CGI scripts are obsolete now, I think mainly for performance issues (like Is PHP or vanilla Perl CGI faster?).

But since I just started studying Perl, I wouldn't want to waste time on implementing solutions in PHP that are way easier (or only possible) in Perl.

Also there are the boilerplate issues, I'm aware of CPAN (that is the existence, not yet the content), but not familiar with PHP libraries (although I have no doubt they exist). I'm not prepared to write a login-procedure or basic user administration from scratch for the 10^10th time.

I don't the luxury at this point to waste a lot of time in research for hobby projects either, so I thought, let's ask the experts for a headstart.

Answer 1

The "obsolete"-ness of CGI is really only a factor if you are doing big, complex sites with lots of page views.

Many people push the idea that CGI is obsolete don't really understand what CGI is. There is a widespread misconception that CGI is an inherently Perl-based technology. Many people attack CGI as a way to pad out cultic attacks on Perl in support of whatever language they support. If you want to be a real technologist, you need to understand the fundamental issues and make a choice based on the facts of the situation.

CGI is an interface with a webserver that allows you to write interactive pages in any language--even befunge. When a server gets a request for a page controlled by a CGI script, the server runs the script and returns the results to the requester.

If your programming language requires a VM, interpreter or compiler to load each time it executes, then this start-up time will be required each time your page is accessed.

CGI accelerators like FastCGI, mod_php, mod_perl and so forth, keep an interpreter/VM in memory at all times, may keep libraries loaded, and even cache bytecode from scripts to reduce script start-up overhead.

If you are making a simple, personal or hobby site, CGI will be fine. So will PHP.

If your site should grow to need a faster technology, you can move to mod_perl, FastCGI, or other CGI acceleration technologies.

What language you use should be determined by the tools it provides and how they fit with your needs.

1. Make a list of the capabilities you need.
2. Make a list of deal breakers.
3. Now check each of your possible toolsets against these two lists.
4. Which one comes out the best? Test it.
5. Does it suck? Cross it off your list, and go back to step 4.

Also, I recommend against using befunge. Just because it is possible, it doesn't mean you should use it.

---

Update: As mpeters points out, mod_perl, mod_php, mod_ruby, et alia are much more than mere CGI accelerators; they provide access to the Apache API. They act as CGI accelerators, but can do much, much, more.

FastCGI is a pure CGI accelerator.

Update 2: PHP and CGI are not mutually exclusive. PHP can be installed as a CGI. PHP is often used with FastCGI.

Answer 2

This is a fairly subjective issue for deciding what to use for a hobby. I decided to learn Perl as a hobby after looking into PHP and not liking the fact that I could not read most of the PHP out there and being daunted by the list of builtin functions.

The first few things I did were CGI scripts for contact forms and a photo album generator. I was on a cheapo shared hosting plan and I was not getting any performance problems so the performance issue never came into play.

Instead, the existence of comp.lang.perl.misc and CPAN ensured that I never reconsidered my decision not to delve into PHP.

In the mean time, I realized most of the content on my web sites is static once generated, so now I write Perl scripts to generate the content offline.

So, my answer is, pick a small project, anything will do, and implement it using Perl and appropriate CPAN modules and see if you like it.