Programmers use frameworks to make their work easier. Frameworks are made by people working on the same sort of project and solve many of the common problems one might encounter. What makes one framework better than another?
For my first few years as a MS Windows C++ programer, I used the MFC application framework because that's what most people used. MFC is a grand object-oriented design where each of the classes inherits from CObject. It seems like a clever idea and a good strategy for organizing a complex system, but I noticed that for some tasks using direct API calls — bypassing the framework — was simpler and easier to understand.
I started working on an existing project much different from the typical MFC application. This project used no framework at all, which meant solving common problems all over again. It was sometimes tedious, but also a good lesson about what MFC did behind the scenes. I realized that MFC provided a lot of support, but the clever object-oriented design created extra work. Interested in alternatives, I tried a framework called WTL which provides wrappers for common tasks, but without the clever CObject design — making development easier without adding layers of complexity. I wished I'd taken a chance and tried WTL much earlier.
What makes one framework different from another is the design goals. MFC's designers set out to make a clever framework making full use of the object-oriented style. WTL was an internal project intended to allow developers to write small and efficient code, which was eventually released as a framework for others to use. It seems that the key difference between frameworks is not the design of the framework itself, but what kind of code is written when using the framework. A framework that helps a developer write easy to read, concise code will be a better framework regardless of how clever the internal workings of the framework are.
When I switched to PHP development, I researched various PHP frameworks and eventually settled on one. It took me some time to become familiar with PHP and realize that the framework I chose is bloated because the code I'm writing is more complex than it needs to be. Unsurprisingly, the design of the framework centers around a seemingly clever object-oriented tree structure that actually adds unnecessary complexity. It's not that object-oriented design is flawed, but that not every design benefits from being coerced into objects. The goal of a framework should be to make the life of the developer easy by solving the common issues they'll encounter in a way that allows them write concise, readable code, and while this framework is nowhere near as bad as MFC, it seems to focus more on clever design of the framework.
I researched more PHP frameworks and didn't find anything that suited my needs, so I decided to write my own framework which I call PHP Off Road. I started with the code I wanted to write and built the framework to support that. The framework — like many other PHP frameworks — is divided into Controllers, Models, and Views and mini views which can be embedded in other views like child controls on the window of a desktop application. Nothing that hasn't been done before, but the core of the framework is a single 200 line file. The rest is optional extensions (or plugins) and a fairly simple contract between Controllers, Models and Views. It's working now (this site uses it), but it still needs a bit of work and polish before it's ready for public release.