Well, it seems that a million monkeys pounding on a million keyboards will write… a million PHP frameworks. I’ve got a client project that needs a rich client front end, likely with DHTML-Javascript-AJAX, a powerful middle tier with complex business logic and processing, and an interface to the backend data that can both support (and hopefully automate and generate) the dozens of generic CRUD processes but also allow overriding with complex SQL (you know, the nasty, multiple page, outer join, union, correlated subquery, inline-function SQL that takes days to write, debug and document, runs in milliseconds, and makes the whole operation worthwhile). Bonus points for caching at the component level, plugin widgets that do all the latest cool stuff (tags, RSS, digg, widgets, etc.) and a smart graphical IDE that can act as a design surface, debugger and data browser. A good manual available online and on paper, along with an active developer community is essential, too. Oh, and Free as in beer along with Free as in speech is desirable (for the former) and required (for the latter).
A guy can dream, can’t he?
There’s a great comparison chart on 10 PHP frameworks from PHPit.net, although dated last year. The many comments indicate that some folks think some of the features aren’t properly credited or misunderstood. Some posters may disagree on the meanings of “MVC” or “ORM.” Some may disagree on what “is” is. Some, I suspect, are those monkeys typing at keyboards. Others likely have valid points. The chart is 14 months old (March 26, 2006) and not getting any younger, while the frameworks either rocket ahead or wallow in the doldrums. I note, for example, the Zend Framework version 1.0 is in Release Candidate phase, just two weeks ago, a major milestone usually taken with some gravity.
There’s not a lot of discussion on how and why these ten frameworks were chosen. Why not blueshoes or dojo? And how about those CMSes? A number of the more powerful Content Management Systems could serve as the basis for an application: already they have a user gui, a writer/editor/moderator/developer UI, connections to a database, and “stuff” in the middle. How well the stuff is designed and whether it’s flexible enough to fit application logic in there brings into place the philosophical questions of where an application begins and where content management ends. I fear that way leads madness: a tool specifically developed for one purpose stretched into a general-purpose tool can be a rough fit. The closer the designers stayed to their original focus of “delivering content” the less likely it is to be flexible enough.
It looks like I’ve got my work cut out for me sorting the wheat from the chaff… any pointers from readers would be welcomed. The good news: it’s all about choice. Having many choices is great news.