what is built in to perl dist these days that is meant to take the place of CGI.pm?

Short answer: nothing. The philosophy seems to be that since CGI.pm is no longer the de-facto standard for such tasks and has some other drawbacks that it shouldn't be in core rather than there should be something to replace it. A quick search here will show you many discussions about this over the past couple of years so you can look there for the rationale. (Update: Here's one such discussion posted only last month, for example)

My preference these days is for CGI::Lite. It has no non-core dependencies, is lighter (!) and faster than CGI.pm and doesn't require gcc to install because it is pure perl. There are plenty of other CGI implementations out there and there are also a bunch of framework-in-a-box options if you fancy that: Mojolicious, Dancer2, even Catalyst for the brave.

Take some for a spin and see how you get on with them. Folks here will be able to give you ideas but it's a very personal decision which to use depending on whether you prefer speed, resilience, security, flexibility, etc.

"and doesn't require gcc to install because it is pure perl."

Just for clarity CGI doesn't need a c compiler:

"To make this a little easier the CGI::Fast module has been split into its own distribution, meaning you do not need access to a compiler to install CGI.pm"

" even Catalyst for the brave."

For the Foolish.

CGI was a specification and CGI.pm was it's implementation: the new shiny specification is now PSGI and Plack is the implementation by it's author.

That said you can install CGI and you can use it if you understand well your needs and eventual drawbacks.

You can be interested in the following video by SayerX (one of the author of Dancer2) CGI must die!

See also perl as a php alternative 2015 and also CGI alternatives BIS lot of links and finally the recent UP-TO-DATE Comparison of CGI Alternatives - a 2017 Perl Web Panorama

My homoenode if full of links about such alternatives; you are welcome at any time!

L*

IMHO. In fact, we'll probably end up ripping out Mojolicious and converting those pages to CGI to simplify our software code base.

This comes off sounding a bit like: In fact, Perl 5.10 has so many weird conventions and features we don't use, we'll probably end up converting all our scripts back to 5.4.

LoL :)

It's meant in a practical way and more like: All of our programs are in Perl, except for a few that are in Python and no one here knows Python, so if we can get those translated to Perl then we can ditch the Python stuff and our code base will be easier to maintain because we'll have fewer technologies to know. (That was reality for us too until I rewrote the last Python program in Perl a few months ago.)

In the abstract, there's nothing wrong with Python for those of you who like it. In the practical sense, it's an issue for us here because no one here knows Python so it makes our job harder.

Since ~97% of our code is CGI, why maintain a vast minority of code in a framework no one here really knows and slows us down? (How did it get here? Someone wrote it as a proof of concept and then checked it in just before they left for another job and at the time there was no one to prevent that -- a sad tale.)

"Back in time, someone here created a few pages with Mojolicious and they are a real pain to maintain ..."

Without showing us what you are up against, we cannot really have a meaningful discussion.

If the PSGI frameworks work for you and speed you up, that's really great and I'm happy it's a positive there.

For us here, no one really knows Mojolicious, so it's a struggle to work on it when something goes wrong. Yes, we could invest the time to learn it, but it's only like 3% of our code and we have so many other important things to do.

When we do have to work on the code, we find it hard to figure where/when things are happening or how it gets called. There appears to be a lot of "black magic". Now, if we understood the framework, it probably wouldn't be considered magic, but as it is, it looks like subs get called for no reason we can discern.

I don't particularly like all the code that gets pulled in because of the framework, as in many thousands of lines in extra modules no one else uses, plus an extra service (I guess you'd call it): morbo. This appears to be a problem only because our entire app isn't written with Mojo. If it was, I probably wouldn't complain about it because it'd be used for everything. But when only a tiny amount of our app uses it, it seems like a large overhead.

Mojo forces another templating system on us; we normally use Template Toolkit. OK, Mojo's templates aren't not overly hard to understand and there are even a few cool things about them, but the problem is that it's yet another exception to the rest of our code base.

There are probably a few other issues, but those are the main ones. Sure, some of this you can throw into the category of "you don't like it because it's different" and I'll even agree. But a large part of my problem with Mojo is that I can't see the benefit the framework is supposed to give me ... the small examples in the tutorials don't strike me as "wow, that'd be so helpful". Maybe I haven't found the right tutorials. (shrug) It might be great tech, but I just haven't seen why. I'm open to understanding if someone can explain it.

If you're wondering how did that bit of Mojo code get here, the answer is someone wrote it as a proof of concept and then checked it in just before he left for another job. At the time there were no controls in place to prevent that like there is now. It was also from before I started working here.

I like to use PSGI/Plack. It's simple enough to learn and to use, but most people don't use Plack from scratch anymore unless they are making a web framework or prefer their own way to do it. They usually go for higher level and 'out-of-the-box' options, like Dancer2 web framework in case they want to save time and cost. There's also Mojolicious (which has Mojolicious::Lite that is great for microservice web applications prototyping) that you need to try.

Out of curiosity, I looked at the PSGI/Plack website and made an amusing discovery.

Many years ago, before I "discovered" Perl, I wrote a webserver in AWK. It wasn't purely in AWK; I wrote a C program to listen for and accept incoming HTTP connections. It then read the request and "parsed" it into an array of name/value pairs, then exec'd AWK, using the array as the environment pointer.

Seems I "invented" "ASGI". Not the same as PSGI, but very close.

That sounds amazing! Any chance the codebase still lurking around somewhere?

Do you know how raccoons can be so slick at surviving?

Here is an example of using Plack to capture form queries:

use Data::Dumper;
use Plack::Request;
use Plack::Response;

my $app = sub {
    my $req = Plack::Request->new(shift);
    my $query = $req->parameters;
    my $res = Plack::Response->new(200);
    $res->body('<pre>' . Dumper($query) . '</pre>');
    $res->finalize;
};
[download]