CGI.pm != CGI, and PSGI is sort of a false comparison here because the only indisputable part of the equation is that webapps should be persistent and CGI.pm is historically not so while the assumption with PSGI is that is it so; though it’s not necessary, it’s just the modern expectation and the tools are geared to it, unlike CGI where FCGI or something similar is necessary.

It’s certainly possible to write CGI.pm apps well, even big ones, and to deploy them persistently. It is just about a thousand times, quite literally, harder to do than it is to use a modern toolkit. The modern toolkits prevent you from painting yourself into corners and handle tons of best practices and prevent easy mistakes; giving oodles of plugins for everything from sessions to authorization and clean separation of concerns to make code portable and reuse and testing fairly trivial.

I like CGI.pm and I will still fire it up for certain things like one-offs or small site search forms. It’s lunacy or masochism to use it on a big app today. It’s not about the newest, shiny, fad. Catalyst is 12 years old and it was loosely based on an even earlier Perl framework and Ruby on Rails. This isn’t fashion, it’s webapp evolution for the better.

Everyone has different taste, needs, and tolerance for new development and learning. CGI.pm is a perfectly functional relic. It is certainly a relic though and I don’t recall seeing a webdev job posting in many years that mentioned it while they all mention Catalyst, Dancer2, or Mojolicious and most of those mention DBIx::Class.