Given the diversity of packages that call themselves frameworks, the broadest description we can give, is that frameworks for web development are collections of reusable software components for building websites (or web-based applications).

Frameworks generally belong to one of two camps, “pure frameworks” and “full stack frameworks”.

Most frameworks don’t make a distinction between “framework” and “application” features, and as a result they become cluttered. They also become more daunting to newcomers, with their sheer volume of classes that attempt to solve every practical problem a web developer might ever encounter – user management, document and image handling, upload and downloading, etc.

My favorite PHP framework, Yii, is a pure framework – free from the burden that many frameworks drag around, namely a full “application stack”. Yii consists almost exclusively of components and features designed to support certain practices or paradigms.

One of my favorite things about Yii, as compared to “full stack” frameworks, such as Zend, is that Yii only comes with components and architecture that can be rightfully said to belong in the “framework” domain, and not the “application” domain.

Of course, it may be hard in some cases to draw an exact line between the two, and I think the first criteria for selecting features that belong in the framework, and not in an application stack, should be:

• Is it absolutely general-purpose?
• If not, is it fully extensible?

Certain features, like the URL manager or Active Record, are not absolutely general purpose, in the sense that they may not satisfy every possible need anyone could ever have. But they are sufficiently general purpose in the sense that almost everybody is going to need at least the core functionality of those components. And because they are fully extensible, developers can build on top of them, rather than having to replace them, if they find that a component does not fully cater to their specific needs.

The reason why I do not want application features in a framework, is because I know from experience that these will not meet my strict requirements. I will eventually end up replacing many of these features and the existing features provided by the framework are reduced to baggage.

Everybody is different – we all have different goals, and even if we share some goals, we usually have different means for reaching those goals.

I believe the reason why we web developers converge around a framework, is because we agree on certain practices. The framework is designed to leverage those practices in a convenient and streamlined way.

The subtle art of the framework is to achieve accepted practice, without getting in the way of individuality – to enable us to adhere to the good practices that we agree upon, while still allowing us to be as different, as versatile and as colorful as we can!

In short, frameworks enable us to focus our efforts on “business logic”, the functionality that has real value to the website users. Thanks to the framework, we can focus on the practical requirements, without sacrificing the values that professional software developers care about: clean, maintainable and extensible code.

With a good framework, we can deliver value and high code quality, without charging extra for quality!