Last month I read Adam’s call OSCON papers. I mention this today because I have to submit something this weekend, but I remember reading something funny.

As usual, they’re desperate for PHP papers. In fact, the only thing they won’t take is a paper about your database abstraction layer or “Yet-Another-CMS“. I find this amusing and true. There are way too many PHP Frameworks out there. Sure PHP-Nuke/PostNuke/XOOPS are great for making a website if you don’t know PHP or have design sense, but knowing any PHP is worse than useless—the more PHP you know, the more offensive they become.

The problem is they do only one thing well. Color outside the lines and you run into the mess of a framework.

Approaching from the other side has actually turned more disastrous. The reason is a framework tries to do too much well and ends up doing nothing at all, other than keep a lot of Java consultants employed *cough* J2EE *cough*. There are many more of these for PHP than nearly anything else, and I won’t embarrass anyone by singling a few out.

The only truly successful framework for PHP is PEAR. And it’s only successful because it’s framework consists of only two classes: PEAR and PEAR_Error.

It’s probably because framework code is the antithesis of the design principles that went behind PHP. Frameworks try to do too much; PHP tries to pass the buck. Frameworks are complete; PHP is a component (the ‘P’ in LAMP). Frameworks are standard; almost nothing in PHP is standard, that’s why you need a website to document its quirks. Frameworks surround; PHP sits inside. Frameworks are complicated; PHP is simple.

You have to seriously be out of touch with PHP to try to make a framework in it.

It’s been a while since I’ve done serious PHP programming. I had better change that, lest I run out of things to talk about at OSCON.

Guess it’s high time I wrote a PHP Framework…