I have used and researched many different web frameworks over my years as a web app developer. I have found that the general "try to do everything" frameworks are often not very good, because they try to be too general.

Some examples are Enterprise Java Beans (sorry to not use a Perl example, that is coming shortly). They try to do everying, but because they are so flexible, the developer ends up doing way too much extra work.

Then there are frameworks that focus on a particular type of application. For example, java struts work well for designing strut-stype applications. EZ publish (a PHP kit) works well for news sites.

So, what is happening is that it is very difficult to make something that works for all jobs. The more specific your target, the better job you can do designing a solution. This is true for app frameworks.

For that reason, I like to plug together a set of different tools to meet my needs on a per-job basis. For example, in one application, I might use Class:DBI as my database interface and Template Toolkit as my view generator. But another job might be easier to develop if I used DBI as the database interface.

Now, moving more specifically to your example: how do you validate a form, or an email? How do you manage a session? It changes from one category of application to another.

While it may take a little extra work glueing your components (APIs) together, the trade-off in flexibility is worth it (for the kinds of apps I deal with).

In short, it is very hard to put something monolithic together that will serve many jobs. Of course, by my very own assertions, it is quite possible that you can put together a framework that meets the needs of the types of apps you develop very well.