Can you use PHP without frameworks nowadays?

Initially I thought the answer was a big "No, you are in the stone age."

Then things started changing.

The PHP community mindset

For example, I met Ilia Alshanetsky, a contributor to the PHP core, at the PHP Barcelona conference in October.  He said he's not considering frameworks in his work. I don't know if he meant going procedural or only avoiding incorporating frameworks as external code, but that's a start.

The costs of frameworks

In the same days, I attended Matteo Vaccari's talk at Webtech 2010. It was in Italian, but the translation would sound like Framework-free web programming. The context was the Java platform, where frameworks are even more invasive than in PHP.

In that talk, I learned some interesting points which are often overlooked while considering frameworks adoption, delighted by the hope of writing less code.

• Learning curve and lock-in: you have to work for a certain amount of time with the framework in order to become accustomed to it; then you'll find difficult to come back as you have invested a lot of time (which is money) and lines of code into that framework. I developed my Bachelor's thesis with SMILA, a Java framework for search applications, and half of the time went away to get it to work.
• Upgrading and version management: frameworks are similar to libraries, and they have to be upgraded regularly, and embedded in the build or in the repository.
• Errors, bugs, missing features that we difficult to push in, magic features which we would want to push out. Frameworks are another level of abstraction which opens new way for bugs and errors to get in.

Thus typically, the costs of libraries integration are underestimated, and frameworks are not an exception.

How to integrate a library

The first thing you do when you integrate a library is to wrap it in an interface that your code finds easy to work with, and define only the functionalities you use in this Facade.

That's a good way to keep a library isolated, far from the core of your codebase, so that you can swap it in the future with a similar one in case the project dies or take new directions you don't like at all.

The catch is - you can't do that with a framework. Framework are defined as libraries that call you, instead of you calling them. For example, in Zend Framework you define controllers as

class MyController extends Zend_Controller_Action{    public function indexAction() {}}

and an object of this class will be instantiated and called for you. That's incredibly handy for generating an application from scratch, but it's difficult to isolate. While a layer of abstraction over a library is simply a couple of interface and class, I've never seen someone trying to abstract away a controller by implementing different "controller drivers". The best we can do (in PHP) is to keep controllers as small as possible.

Frameworks are catch-all facilities, that have to support many different use cases

Zend Framework, which is actually an hybrid, is easy to use as a library: you create Zend_Locale, Zend_Translate, or Zend_Filter objects and compose them.

But the framework side (Zend_Controller mainly) pushes for defining Zend_Locale and Zend_Translate as global objects which magically intervene in your input and output handling. Testing code that involves a framework is a blood bath, unless the framework provides you some utility as workarounds for the magic functionalities, like Zend_Test (which disactivates exits(), redirect, and Zend_Session).

Is this really cool? To manage a full application, the framework is littered with Singletons and global state (which are under rework in Zend Framework 2.0), lots of configuration, and many issues on how to define ini values, and with what names.

The folder structure is also different from standard autoload but somewhat a standard in the framework's application (another lock-in). There are many different conventions you have to follow - uppercase names, lowercase ones, underscores, camelCase, and all-lower case.

And for what? For example, supporting multiple paths for view helpers so that some paths overwrite the previous ones magically. In your view, you could call $this->url() and the right Url view helper will be dispatched.

Do you really need that? Some of us do, but it's a minority. I would just provide an hardcoded list of view helpers classes to inject in my view (I know class maps will probably do something like this).

The same goes for resources, plugins, form elements and decorators; Zend_Form supports filtering, validation, rendering, decoration, display groups... I never use more than half of them at a time.

Each moving part adds to the complexity of understanding how the framework works, and how to fix it when it breaks. At the same time, it adds little to the developer as it is a generic implementation which will have to be tailored to the current needs anyway.

Conclusion

Summing it up, a framework tries to save you work by make you define an overly complex configuration, that has to accomodate every possible use case. This declarative approach to building an application is not always superior to the programmatic one, where you build object graphs by hand.

Is this a reason to ditch a framework? Only if you already know that your application won't need such a complex architecture. But meanwhile, I'll continue to make my controllers as small as possible. Hope to see your opinion in the comments.