Arguments for not using a framework

A little while ago I read a great article which described a number of reasons against using any of the RAD frameworks available for PHP. Basically, it argued that a good framework should get you off the ground quickly, and then should get out of your way. But none of the PHP frameworks did that. It pointed out that Django was good at doing just that (but that's obviously not a PHP framework).

For the life of me, I can't find the article now.

So I'm curious. Does anyone have any solid arguments as to why applications should not be built on top of a RAD framework? And I'm not necessarily talking about generic applications (frameworks by definition try to solve a generic problem. The quesiton is does that translate well to specific problems).

And when I say built on top of, I mean from the ground up based on the framework. I don't mean referencing the framewo开发者_JAVA技巧rk as a series of libraries. I mean basing the entire architecture of the application off of the framework (which then ties you into the framework).

I'm also not really talking about rapid prototyping where the code will likely be re-written anyway. I'm more looking at long-term applications that have a specific business requirement to meet, and must be supported and maintained (and modified) for a relatively long period of time.

We always hear about why we should be using a framework. There are reasons galore:

• Not reinventing the wheel (although I hate this reason)
• Faster development time (since architecture is skipped)
• Easier to bring new developers in
• Common problems are already solved
• etc...

But I'm looking for the antithesis...

Any thoughts?

It is implied that frameworks being written by some unknown heroes who is smarter than you by default.
But as a matter if fact it's often not true.
It has bugs, it can be messy and unnecessary overcomplicated. Thus, having your own helper library is often more handy than using such a monster, knowing roughly 10% of it's features.

A few ideas:

1. The type application you are creating does not have a commercial or free framework available (custom hardware-based apps come to mind) (this is the obvious answer)
2. The system has extensibility requirements that are made more difficult by using a RAD framework (i.e. framework values convention over configuration, where you really need the configuration)
3. The project scope is small enough that it doesn't make sense to invest the learning curve into using a RAD framework (if you already are past the learning curve, this may or may not apply)
4. The tools/approach/back-end/platform requirements provided by the framework will introduce unnecessary complexity (YAGNI, using a framework without a business need for its features may increase support costs as you have to support the whole thing, including unused features)

My fear has always been, what happens when a framework stops being maintained/updated (for whatever reason)? Your project is locked into whatever PHP/MySQL versions the framework supported.

I'm doing a little framework research lately.
http://matrix.include-once.org/framework/

And to some extend I have to agree. The majority of frameworks don't significantly simplify development. Particularily the "MVC" frameworks are about abstraction more than utility. There are however always features which do help for everyday tasks. ActiveRecord/ORM come to mind as reducing tedious manual work. Form helpers might do, but I haven't seen a seriously helpful one yet.

Generally I believe, the more functional library code a framework provides, the higher the productivity. But in the case of Zend Framework, it's randomly dwarfed by complexity. However, check some of the smaller frameworks out. Avoid the overly abstract. Look for scaffolding tools, not libraries.

One of the main advantage to not use a framework is that you have more flexibility in what you can code. For project with a smaller scale, it is often better to have that flexibility.

• Some frameworks need shell access to deploy.
• Scalability, I've read that sharding is an issue
• If performance is a priority, frameworks tend to slow down execution speeds
• Not all developers familiar with MVC pattern so maintainability if developers rotating in/out of project could be a challenge.