Not so much out of grace as much as (I think) it's fairly heavy for what it is and somewhat convoluted to configure and use.

Mojolicious and Dancer are the more modern equivalents, and both are frameworks in the vein of Ruby's Sinatra or Rails (probably more in-between). While you can run them as CGI/FastCGI, really nowadays I think most people just run them as standalone pure-Perl web servers (which makes it really easy to access and deal with every part of the request and routing), optionally with a proxying front-end such as Nginx or Apache to speed op static requests or handle SSL (but that's not needed, both are entirely capably of doing SSL encrypted servers in pure-perl with a few configuration params set).

Like the sibling comment, I prefer Mojolicious, and it's simple enough that the landing page for it[1] shows not just one but two fully functional standalone web applications with embedded webservers, one of 5 lines and one of 25 lines (both counts including blank lines). That may not help much with existing Catalyst apps, but I would be hard pressed to recommend Catalyst given how far the state of the art has advanced, but then again I've never really been a Catalyst user, so I may be unaware of a lot of its benefits.

1: https://mojolicious.org/

Well, TMTOWTDI and all, but also research Mojolicious

https://mojolicious.org/

Big monolithic web applications, which catalyst is optimised for have fallen out of favour. Catalyst helped solve many perl tooling problems, and it’s still a totally viable dev target. However as the author of the good catalyst book, I’d probably reach for mojo first in 2018.

The thing I like about catalyst is the same as the thing I like about git. It works well for the smallest use case and it scales well to the largest reasonable case.

In addition to the other comments made here ... Task::Catalyst is right there after Plack and before Template (TT2).

Rather than try to guess at the proper set of modules recommended by a subproject, if there was already a recommendation (ie a Task:: module) we tried to re-use that.