No, not under every single case, especially not internal or personal—I did say I still use CGI.pm—but persistence is always better and often necessary.

Just loading the libs and the DB connections and config and such at Work™ takes 6 seconds and if we have just 30 clients connecting via CGI, which we did a few years ago, the application is unusable; our Catalyst app takes 30 seconds to start. Our public/demo webapp can have a hundred clients at a time and thousands in a day + all the robots hitting it. Compile on demand CGI is ludicrous with a big app under real usage.

I'm going to go out on a limb and say that there is an architectural issue there. I've worked on multiple CGI projects and we start to wonder what we're doing wrong if a page takes more than 5-6s to run, starting from click to beginning to draw ... with the caveat of network latency not counting in that time. That's for the normal pages, exceptions like running reports don't count as that could require pulling GB of data out of the DB.

The last place I worked doing CGI, we had nearly 300 hits per second during peak times and CGI kept up just fine, including auth/sessions and DB connections+retrievals and processing. Sure, you could feel the site slowing a little at that rate, but it wasn't painful. I'll agree that modern hardware removes a number of the old issues of CGI.

Of course, your app may have special needs, lots of back-end calculations or whatever, that prevent quick take some user input to the server, process, return the result.

Part of the reason I'm not overly keene on Mojo is that it pulls in over 30K lines of Perl last I looked (including parts of Moo and who knows what else). Yes, I know that CGI.pm isn't a lightweight, but changing to CGI::Simple or something like it isn't all that bad and yet gets me the basics of what I need to get the job done. I think a lot of this boils down to the choice of do you want to 'roll your own' or use someone else's code?

There are so many frameworks out there that I'm very choosy when to learn a new one and it has to really wow me before I'll spend the time on it. I've yet to find a good wow-factor for the PSGI stuff; if I ever do, I'll look at switching.

There are several architectural issues in our code that could be improved; mostly because it was built to CGI.pm era standards which are a hodge-podge, string-manipulation oriented mess. There are dozens of issues in our code that cannot be improved. The average page loads something like 30 subpage/resources, many of which are dynamic because of deep, and legally mandated, permission issues. Lots of heavy data image processing, a dozen encrypted IO and CPU intensive dæmons running all day, indexing and reindexing millions of records all the time, and six or seven different code bases and toolsets glued together. If you suggested customer facing compile on demand code, CGI.pm or otherwise, was viable at work at Google or Amazon or any company with big, deep webapps…

Our code base has north of 30K lines of in-house code—the main code lib file alone has 17K and the main JS file has 10ishK—before a single module or C, Perl, or Java lib is loaded. With persistent execution (and enough RAM to throw at the problem) it’s a non-issue.

I wanted to outline why an MVC framework is better than home-rolled CGI.pm for a couple days. It’s too deep to go into except superficially. It boils down to a professional web application can be written in BASIC, the code library isn’t the issue. You can build a mansion with bronze age tools every bit as well as modern tools, there is no contractor in the world who would voluntarily do so and it would cost a thousand times more. The amount of work, the cost of revisions and changes, the risk of regressions, the ease of testing, the flexibility of deployment, the ease of additions like Oauth or model changes, the free development and support from the community. These things matter more than the actual application. In a framework, 90% of the support details are done for you and tested and continuously improved by dozens if not hundreds of other developers and teams. I am a CGI.pm expert. I’ve written a couple thousand CGIs with it going back to the late 90s; including Intranet stuff at Amazon that was used by thousands of employees. locate .cgi | ack -v COPY | wc -l on this new computer, a decade since I’ve written a CGI for professional reasons, still gives 218. I am not a CGI detractor. I am a webdev supporter.

I would like you consider the hubris necessary to believe that home-rolled code is going to be better, on any level, than what two decades of iterative development, deployment, and testing across several languages by the best developers in each can produce.

Part of the reason I'm not overly keene on Mojo is that it pulls in over 30K lines of Perl last I looked (including parts of Moo and who knows what else).

The cpan knows :) at this moment Mojo depends only on these four modules, only the first of which is not core
IO::Socket::IP
JSON::PP
Pod::Simple
Time::Local