You seem a bit stuck on FastCGI. I think you should consider reading this article titled, "Which is better perl-CGI, mod_perl or PSGI?"

I think my server is responsible for this and no addition perl modules are needed just to run fast CGI, am I right ?

No, you need a module for fast cgi same as you do for regular cgi.

Just as CGI is an interface/protocol between webservers (like apache) and programs like perl, so is FastCGI, and both protocols require both webserver and program to speak the same protocol, so that the program can speak internet (the webserver helps the program speak internet)

If you don't use a module (like a frenchtalian translator), you have to learn the protocol -- its like making your own frenchtalian speaking hammer -- just use the free one :)

In perl, CGI.pm speaks pretty good CGI, and FCGI speaks pretty good FastCGI

CGI.pm distribution even comes with CGI::Fast - CGI Interface for Fast CGI

CGI protocol is there to help programs speak internet through an intermediary known as a webserver

The best and most flexible way for perl programs to speak internet is PSGI, see PSGI::FAQ

If you use dancer or mojolicious or catalyst ... they all speak PSGI pretty well, which means they can run on mod_perl, plain old CGI, FastCGI... thats the idea behind PSGI

Dancer and CGI are just ways for computer programs to speak internet, you should learn about the internet :)

Re: How does Dancer handle forms? How do other such frameworks do it?

All the frameworks give you a request object

All the frameworks want you to give them a response object

If you're using CGI.pm and following CGI to mod_perl Porting. mod_perl Coding guidelines you're 98% modern , only 2% away from using any "modern frameworks" which have a response object

PSGI, PSGI::FAQ

If you want speed in templating, see Text::Xslate::Manual::FAQ, Xslate - Scalable template engine for Perl5

Quite honestly, I think that right now you are “stuck” by wanting to “move forward right now” when ... quite understandably, actually ... you have no idea either where exactly you are going, or what sort of technology might take you there.   It’s like you’ve stumbled onto a Sears & Roebuck Catalog full of all sorts of tasty-looking things and you just want to order all of them and “have a go” at making something work.

What I cordially suggest that you do right now is to stop.   Spend at least today, maybe a couple additional days, “surfing the net” to carefully(!) read several articles regarding each of the technologies that you have listed in your OP, but refusing to treat any of them as a white-rabbit begging to be chased.   You can start chasing rabbits again, say, next Thursday.   Not sooner.

You need to be sure you know, for instance, just how “vanilla CGI” works.   You need to have a notion of what content-management systems (Dancer, Drupal, Catalyst, what-have-you) do, and when they are (and aren’t) called-for in a project.   You need to understand what templating systems do, and where and how they can be useful for preparing HTML or other content.   You need to know what nginix does.   I consider it highly doubtful that you will actually need to delve into either FastCGI or mod_perl for this project, given that neither you nor I understand, at this point, what the project needs to be.

Gather information, without chasing rabbits.   Then, make a plan for how you will go about catching the little white-haired beast.   Now, when you walk out into that field again, you’ll come home with dinner.

You need to be sure you know, for instance, just how “vanilla CGI” works... (and a lot of stuff...)

Is it any wonder that PHP ate Perl's lunch despite being strictly worse as a programming language?

Provocative though that might be as “spam bait, and nothing more,” the key take-away that I glean from the original post is that “the OP does not yet know what s/he wants to achieve, let alone how to achieve it.”   And, until that point is reached, quibblings about “CGI vs. FastCGI vs. mod_perl” are entirely beside the point.   This seems to me to be “a very basic question, thoroughly clouded by buzzwords.”

Anyone in such a position would find himself/herself equally confused, “equally without a plan,” whether they were working in Perl or PHP.   (Since I count myself equally-conversant in both tools, and many more, I do feel that I am qualified to say that.)   The first order of business now should be to define what (exactly!) is the problem to be solved.   From this, everything else will follow.   At this point, we should assume that “good ol’ CGI” will be more-than sufficient, given that the OP does not yet appear to be decided as to what to implement, let alone how.

(And this, by the by, comes as absolutely no surprise.   The discovery process is, after all, methodical.   “One step leads to another, and if you try to rush things you fall upon your a*s.”)