Which PHP5 Framework is Your Favorite?

matt_j_99 asks: "With all the talk about Ruby on Rails, I've been thinking about PHP frameworks. Ruby on Rails looks pretty cool, but frankly, I don't want to learn a new language. It seems that with all the slashdot discussion about RoR, somebody always makes the valid point that PHP is not a framework. But with PHP5's, Object Oriented features, a standard framework might emerge. Prado, Carthag, BlueShoes, and PHITE all seem like interesting frameworks. What PHP frameworks have you used in your applications? What were the pros and cons of each? Which framework do you think will have the best chance of long-term viability and maintenance?"

Re:lame excuse

[namekuseijin]

how about learning a modern, multi-paradigm, very higher-level language for rapidly developing business apps like Ruby rather than an ancient portable assembly to build infrastructure like C?

Frameworks for PHP, not that hot.

[Elamaton]

But with PHP5's, Object Oriented features, a standard framework might emerge.

Indeed, one might. So far, not looking so good on that front. All the frameworks I've encountered so far have seemed cumbersome or tedious somehow (I glanced at Prado just now; the advantages of their approach aren't readily apparent, I'd say. The demos are unimpressive, using some god-awful javascript: pseudo protocol links for updates and deletes, which really puts the internals of the framework into serious question).

It seems that PHP is bereft of any real, exciting developments on the framework front. There are a lot of frameworks, but I guess the reason why none stand out like Rails does with Ruby is simply that none are good enough, providing no significant added value.

You have to ask yourself: why a PHP framework? What such significant advantages would one of the existing frameworks provide that learning its ins and outs wouldn't be a waste of time and energy? If you're looking to automate some of the drudgework of form processing, for example, I suggest you roll a minimalist "frameworklet" - or simply "component" - yourself (if that's plausible in your situation) for that specific purpose, making it generic enough to be reusable, but not so generic that you end up fitting your projects to the tools instead of vice versa, which often happens with frameworks.

I've found minimalism to work really well with PHP. Frameworks that try to be all things to all people mostly end up being more trouble than they're worth. It may very well be faster and more efficient (and more fun) to code a small component for a specific purpose than trying to work with an existing solution. Your own solution will be tailored to fit your application and will work as your mind wants it to work, not the way the framework creator sees fit for himself.

It's a Unixy approach, I think: combine small tools in inventive ways to accomplish even the largest tasks. Of course, with tools of your own creation, you wouldn't have to deal with inconsistent APIs, a thousand syntaxes and wholly different philosophies across these tools. Write a custom session handler here, a generic input validator there... Even if you create these tools for a specific project, you will most likely find yourself reusing them in future projects, too, with possible minor customizations.

An example: when I first wanted a lightweight way of separating the business logic from the display logic for a project, I coded a single class that did the template stuff, using standard PHP with no additional burdens. Smarty etc. were readily available options, but PHP is already a templating language, and separate template engines would just have added excess bloat to the mix. My solution wasn't as feature-rich, of course, but it did exactly what it had to in the parameters set by the project specs. I've successfully and rapidly reused the code (and more importantly, the overall technique) in several later projects. Besides templating, I've had similar good experiences with an extensible input validation system I cooked up once, adjusting and refining it to later projects.

The way I see it is this: languages like Ruby and Python benefit from good web frameworks, since they're non-web-specific languages, and these frameworks make their use a lot more convenient in web programming. PHP, on the other hand, is very much a web programming language at heart. Ignore the "PHP suxx0rz!" trolls, it is a good tool for that purpose. (Even though it's capable of more, it's rarely - if ever - the best choice in those circumstances.) The best a framework would do with PHP is addressing clear shortcomings of the language in some way, but you don't really need a full-fledged framework to fight these annoyances. I find the "invented here" mini-component approach superior.

In short, I don't see a framework "enabling" significantly better ways to do web programming in PHP, unlike with Ruby or Python. For PHP, a framework will probably be more trouble than it

Re:Ruby is a passing fad, a PhD's toy

[ttfkam]

OTOH, if you aren't in an ivory tower and have to program for a living, then PHP is like C, a language the "perfessors" hate,but it keeps working just fine for the 99.5% of us.

Would that be the 99.5% of all C apps that have weekly buffer overflow exploit notices?

Or would that be the 99.5% of PHP apps that have constant SQL and variable injection attacks. *cough* PHP XML_RPC support *cough*

Re:Which PHP App?

[tom's a-cold]

Me: Writing logic in your presentation layer (your web pages) is a bad idea no matter what language you use.

While I agree with this, I think that, for trivial apps, it's not such a big deal to mix the presentation layer and the logic. The problem I have with PHP is that some over-enthusiastic developers have tried to extend its use to writing enterprise applications. That's not what it was designed for, though feature-creep has moved it a little in that direction. There's not much wrong with it for small-scale throwaway web apps, but beyond a certain point, it just isn't the right tool anymore.

I saw some earlier posts that were sneering at language features that "95% of us don't use." Well, that might become what keeps you from being one of the 5% who will still be programming five years from now. Though I've met a few diehards who were writing spaghetti ten years ago and still are.
And, just to be very clear, I'm not a language zealot. I have coded in, and led teams who coded in, C, C++, Java, Smalltalk, Lisp (various flavors), Perl, Python, Ruby and various app development frameworks. Despite my having used other languages, and the likelihood I will continue to do so, I understand what drove the additional features in Python and Ruby and enjoy the added productivity that they enable. PHP was meant more to "get the job done, screw the fancy stuff" and the simplistic feature set has become a limitation as its usage has grown.

People vs. Technology

[ttfkam]

Except that for years PHP and MySQL, tools marketed to beginners, didn't have the "correct" option available.

And beginners won't know to ask about it. The incorrect option is all they know. The solution, of course, is better tools. ...and tutorials. There is no excuse as a documentation/tutorial author to demonstrate values injected into SQL strings in examples.

And, once again, there is NO excuse for building a network-aware technology that allows for setting variables from the URI query string. None. Even PHP's predecessors had better sense. It speaks volumes that after it was exposed as the security nightmare that it was, it was simply disabled as opposed to removing it outright. Why? Because it would break existing apps? Guess what? Apps that blindly allow end-user manipulation of variables are already broken.

The correct decision is fixing the flaw, not merely disabling the flaw by default. It should not be an option. If developer need that functionality for some corner-case reason, they should be knowledgeable enough to write the functionality themselves.

That, in a nutshell, is why I don't like PHP. It doesn't present good decision and allow people to make bad decisions, it presents bad decisions by default unless developers write the better behavior themselves -- better decisions that newbies, by definition, will not make.