问题
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.
回答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.
- Make a list of the capabilities you need.
- Make a list of deal breakers.
- Now check each of your possible toolsets against these two lists.
- Which one comes out the best? Test it.
- 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.
回答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.
回答3:
Whether you use PHP or Perl is moot from a scaling perspective much in the way that the difference between a webapp written in PHP and C is moot. If the difference really mattered, we'd all be writing C, or assembly.
PHP is slow, but that isn't stopping Wikipedia, Facebook, and Yahoo from using it extensively.
There are two major reasons it doesn't matter, from a scaling perspective, which language you choose:
- Use a caching reverse proxy like Squid. By offloading most of apache's workload, you can cut your CGI invocation load dramatically.
- Scaling your web tier is easy. It's scaling your database tier that's hard. You can always add another webserver to the farm. If you can serve 1000 requests per second with mod_php, and 500 requests per second with a CGI, if it's cheaper and faster for you to develop the CGI, do it. You'll need twice as many web heads, but either:
- You're in the bottom 90% of the web, and only really need one webserver anyway.
- You're in the top 10% of the web, and need multiple webservers -- but you've got enough traffic to justify the additional cost.
Pick the language that you and your team can develop in most efficiently.
回答4:
Here is a simple "hello world" example that runs under CGI using the Squatting web microframework:
use strict;
use warnings;
{
package MyApp;
use base 'Squatting';
use base 'Squatting::On::CGI';
}
{
package MyApp::Controllers;
use Squatting ':controllers';
our @C = (
C(
Index => [ '/' ],
get => sub {
my ( $self ) = @_;
my $v = $self->v;
$v->{say} = 'hello world!';
$self->render( 'hello' );
},
),
);
}
{
package MyApp::Views;
use Squatting ':views';
use HTML::AsSubs;
our @V = (
V( 'html',
layout => sub {
my ( $self, $v, @yield ) = @_;
html (
head ( title( 'My CGI App' ) ),
body ( @yield ),
)->as_HTML;
},
hello => sub {
my ( $self, $v ) = @_;
p ( $v->{say} );
},
),
);
}
use CGI;
my $q = CGI->new;
MyApp->init;
MyApp->relocate('/cgi-bin/myapp.cgi');
MyApp->cgi($q);
Save as "myapp.cgi" and place in your cgi-bin.
回答5:
I use both Perl and PHP for websites - for historical reasons, mainly Perl at work and PHP at home; I don't think there is a lot to choose between them.
If your pages are mostly fixed HTML with only a small amount of computation, PHP is a bit easier, because it is embedded in HTML anyway.
I find PHP a more disciplined, and therefore sometimes more limiting, language than Perl. PEAR is very similar to CPAN - not as big, I think, but then CPAN is so big that it's got a lot of dross in it.
HTH
Colin
回答6:
If you use hosting, in many cases PHP would be run as CGI too. If you don't want to run FastCGI or mod_perl, you can use CGI::Application framework. CGI::Application will run with FastCGI or mod_perl too, but unlike Catalyst will run as CGI too. Both Catalyst and CGI::Application also can be run with their own web servers.
回答7:
Both PHP and Perl have their moments, but this is truly subjective. Perl has massive frameworks available on CPAN which can make it work as well, or better, than PHP, even in a purely CGI environment. At the same time, PHP has a large following, and a ton of out of the box features to make website programming simple. The choice, to me, boils down to personal preference. I personally prefer to use Perl than to muck about with trying to find all of the functional ways to do things in PHP. Good luck!
回答8:
Try Catalyst with Template Toolkit.
sub hello :Path('/hello') :Args(0) {
my ( $self, $c ) = @_;
# Hello World
$c->response->body( $c->welcome_message );
}
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN">
<html>
<head>
<title>[% title %]</title>
</head>
<body>
<div id="header">
<a href="/index.html" class="logo" alt="Home Page"></a>
<h1 class="headline">[% title %]</h1>
</div>
[% content %]
<div id="footer">
<div id="copyright">
© [% copyright %]
</div>
</div>
</body>
</html>
来源：https://stackoverflow.com/questions/824730/when-should-i-use-perl-cgi-instead-of-php-or-vice-versa