Advantages (boo)

Although I guess I could answer "TIMTOWTDI", that seems like a cop out. I'll try to enumerate my reasons as coherently as possible, so this node may be a bit longish.

I wanted to force as little upon a designer as possible. When a client says to me "Why should I install Apache over my current server? And why do I need to install an XML parser for this site?" I can immediately discount Apache::PageKit (and Apache::* in general. Yes, some clients are that pushy and do get their way like this...).

I can understand the comparisons to CGI::Application, especially when both modules have seemingly similar setup and execution methods, but ours allows programmers to explicitly compartmentalize the assorted parts of displaying a page (more on this below.), and allows the programmer an easy way to clone and modify pages. I will admit that I have only cursory experience with CGI::Application, though.

Moving on, CGI::Application also enforces the use of HTML::Template files. I personally do not care for HTML::Template. So, I wanted to code something more flexible...
I believe this will be the only module in its class to embrace and encourage the usage of any templating system, or none at all; the first release used TT2, and through Ben's efforts, this one will use HTML::Template objects as well as TT2 ones. We're preparing methods to allow interface to a wider array of templating systems, so that virtually ANY templater could be used. We're also implementing the ability to run without templates at all, because they can be cumbersome for some situations, or maybe just don't fit well in a given solution. Maybe you just like CGI and want to use it. Like I said, I want to encumber programmers as little as possible.
The same thing goes for data validation; there's a handful of commonly referenced data validation modules on cpan. Which one do you like? Maybe your data validation occurs when data's submitted to the database, and you don't need any perl for it at all, you just want to pay attention to the db handle's return value. It'll be your gig.

Of course, I am not against any other module. I don't think any of them are dangerous, or badly written, so plase don't read anything into this project. In fact, personal experince tells me that Jesse Erlbaum has a thriving and active interest in the CGI::App community, and he's always been responsive to his user's needs.

So what is the strength of the Framework concept?

I believe that it's in the way Framework's pages will flow : there is a well-defined order that things will occur in.
An application will always have the opportunity to (this is sort of a gloss-over - read the parent node if you want the full details.)

determine state
perform data validation
template preparation
preprocessing
template display
post processing

This, in a nutshell, is one of the strengths -- it does what it says, provides a framework for your web app, and not just as a collection of loosely related subroutines and templates, it's structuring makes it unique. If a page has error checking, it'll happen consistently. If a page has preprocessing requirements, you only need to worry about the requirements, and not how to wedge them into the flow of the application, or how to return errors from each of the above phases, or how to handle parameter processing.
So, there are similarities between this and the other modules, yes. Their goals are similar, but I think the execution will be where Framework shines.

Comment on Advantages (boo)