Response to Ejecting CGI.pm From the Perl Core
CGI.pm From the Perl Core chromatic discusses the pending deprication
of a storied module. I needed to address a perhaps overlooked aspect
of the argument.
Nearly all web ui are written to support small usergroups inside some
kind of organizational infrastructure.
Very few websites are moderate to large. Most are small. With maybe
a few dozen to a hundred or so users. Most are tools used to provide
some internal organizational function. Not to serve media websites to
thousands viewers or general public readers. On the complementary side
of this, most perl users have some other axe to grind. Web development
is at best a side interest. Or maybe a self defense skill they picked
up out of a need to automate away some function of their job.
Strangely, Apache and CGI fit well into this niche. the local
sysadmin/devops person probably already had apache running for some other
reason. Enabling cgi in some subdirectory was just a matter of editing
a config file and restarting the server. Now he could drop files into
the cgi-bin directory and off they went. Needs were met and the work of
automating away administrative jobs with simple perl scripts could begin.
Life was good.
When there was only one way to do a thing it was pretty obvious how to get
that thing done. Now things have changed. The web is not as simple as
it was. There are so many different approaches to delivering information
to the browser. Client side frameworks, server side frameworks, hybrid
endless. Browsers are no longer "thin clients" Today they are full
function platforms. That's a good thing. But it does complicate things
for beginners and casual users.
For me perl is about two things. Its about making the easy stuff trivial
and making the complex stuff possible. How best should the casual perl
user deploy a web page? How best should he manage the organic growth of
his script base of small pages? Should he choose a big webserver such
as apache or ngenx and integrate through that? Or pick one of the stand
alone perl based solutions such as hypnotoad? starman, one of the others?
Or bail on the whole perl thing and pick a CMS and build from there?
Today the average sysadmin is going to have a suite of different UI
delivered via a web. Wiki, directory services, ticketing, revision
control, monitoring etc. Many depending perhaps on Apache. How best
to integrate custom local tools into that mix?
The perl community needs a new "best practice" approach for delivering
small dynamic web user interfaces. It also needs good documentation on
how to do it. Once upon a time that best practice was Apache and CGI.
Part of perl's popularity in the 90s and 00s was exactly because of
this combination. Also the availability of good documentation like
the CGI.pm perldoc, Ovid's CGI tutorial and the tutorials by Rob
McCool at NCSA. We've fallen off our game. We have no such de facto
boot strap best practice any more. The casual web script developer,
The one with some other axe to grind other than developing a website,
will probably fall over and just use Wordpress, Jango, Drupal, rails
rather than try to wade through the mess of different perl offerings.
None of which seem to have a solution that solves the casual users needs.
Plack, PSGI and technologies around it may be revolutionary. But it
is meaningless middle-ware that just does not seem to fill the niche
occupied by the average CGI.pm user today.