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?"

Comments

uh-oh

[Santana]

but frankly, I don't want to learn a new language

That's the worst thing that can happen to a professional (assuming you are one): not willing to learn new things. I strongly recommend you to learn Ruby, "it puts the fun back on programming", you won't regret.

yet another framework

[larry bagina]

I haven't used it (I only learned about it from one of the endless /. RoR articles), but Cake is another option. If nothing else, the logo is making me hungry.

Which PHP5 Framework is Your Favorite?

[dont_think_twice]

Which PHP5 Framework is Your Favorite?

I guess I sorta like them all ...

Learn Ruby

[Anonymous Coward]

Listen, I've been programming PHP since version 3. I've been writing Perl since.. well since before some of you have been born. I've been working in Lisp and C since before that!

The secret to Ruby on Rails is RUBY. You just can't do that kind of stuff in PHP. PHP is pretty pathetic once you get beyond the basics. It is truly a language for the "bottom 95%" as I call it. PHP has at least the following flaws:

* poor metaprogramming: try creating an anonymous function in PHP, it's just a STRING! Yuck. Closures? Never heard of 'em. Try writing a one-liner in PHP that sorts a list of objects. Impossible.

* global variables for session, cookies, etc. Makes unit-testing a bitch!

* no "finally" clause on exceptions. WTF? Built-in functions don't raise exceptions. WTF?

* no way to refactor object fields. Yes you can use "__get/__set" but those "fake" fields don't work in every place a regular field works. WTF? In Ruby everything is a method, there are no fields, refactoring is a breeze.

* No "mixins".. I can't write a method and then stick it into multiple classes. Not even with include().

* Exposes variables vs. variable references. I thought PHP5 would get rid of "&" forever. I was wrong.

Now Ruby ain't Lisp, that's for sure. But I'd rather stick forks in my eyes than programming in PHP again.

Anyway, a good programmer has no problem learning a new language. It'll take you longer to learn the framework than the language. Ruby is simple and clean and VERY consistent from top to bottom, give it a try.

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:Frameworks for PHP, not that hot.

[Qa1]

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.

I heartily disagree.

First of all, can you explain what's a good "web-specific-language"? As both a web-programmer and a general-purpose programmer, I'd say there's nothing really "web-specific" about a core language. You do need some good library support for stuff like handling web protocols (HTTP, url parsing, etc.), and both Python and Ruby (and many more) have that.

What's important in a core language in order to be suitable for web-programming is good string handling facilities. Which, when you look at it, is what "web-programming" is really all about: generation, manipulation, and occassionally parsing of strings.

I'm not sure how you can imply that Python and Ruby are not as good as PHP for web programming. You indicated that you're "looking to broaden my horizons a bit". So I guess you do know PHP well, but you don't really know Python or Ruby yet.

I've been a PHP programmer for years too. I worked in positions where it was just too problematic to switch. But eventually, I did, although it meant rewriting a lot of legacy code in a new langauge.

Why did I switch? Because I finally understood what I wrote in the above paragraph: that webprogramming is really all about generation, manipulation, and occassionally parsing of strings.

I've used Python a lot for general purpose programming, and I found myself over and over again unfavorably comparing PHP to Python when developing in PHP.

I would say to myself "o.k., now I need to get this substring from the incoming string, manipulate it a bit and plant it in the response page." And immediately a very short, concise and elegant solution Python would pop to my mind. But then I'd need to translate that elegant solution to some awkward PHP translation, and my mind would ache

To get the substring, I couldn't just do "substr = str[3:24].lower()" like I would do in Python. I had to use some godawful substr(str, 3, 24) function, and then run another function on the output, since PHP doesn't support the slice notation and treating of strings as objects that modern languages like Python and Ruby support as core feature.

Also, PHP's handling of regex (another important tool in the web-programmers toolbox) is coarse and awkward. Python's regex support is incomparably better, and Ruby's - even more so.

To sum up, I switched to Python from PHP4 since Python is, hands off, an incomparably better language for web-programming. And Ruby is even better than Python, which is why my current tool of choice is Ruby on Rails.

And while we're on the subject, why didn't PHP manage to create a framework as good as Rails, with all its huge advantage in user-base size?

That's because PHP isn't just an inferior language to Ruby in the web department (supposedly its home court) - its also generally a clunky programming language.

Writing a good web development framework is a general programming task. You need a good object system. PHP didn't even have a half-decent object system until release 5.0, and most of the world still uses PHP4. PHP doesn't have closures. It doesn't have elegant flow control mechanisms like Ruby has. It doesn't have any meta-programming facilities I'm aware of, while Ruby is the best meta-programming language I've used (with the possible exception of Lisp with its uber-macros).

So not only is PHP inferior to Python and Ruby for the simple tasks; for complex tasks, such writing a web-development-framework, the gap only widens. The result is that developing with a better language like Ruby, and on a superior platform like the RoR framework, is incomparably easier, faster, and more maintainable, even for the simple stuff PHP used t

you win the horrible anaolgy of the day contest

[geoffspear]

I've never come across a carpenter who could drive nails, cut boards, and turn table legs with a hammer.

Which PHP App?

[ttfkam]

Isn't that like asking what type of sauce you want on your spaghetti (code)?

I have yet to see a PHP app -- especially one that also used MySQL -- that used a design pattern other than "Big Ball of Mud" most often.

Do be fair, PHP 5 looks pretty good -- or at least is a vast improvement. Unfortunately I can't say the same thing about the people who've coded in PHP up to this point. Even when PHP shows some growth, most PHP coders ignore it.

"Database abstraction? Why would anyone need that?"

"Namespaces? Why would anyone need that?"

"Design patterns? What are those?"

"Security? If it's a problem, we'll fix it later."

PHP: We'll be there for you if your development environment doesn't have enough side effects.

PHP: Because we know the money's in the maintenance contracts.

PHP: Because you obviously don't know any better.

PHP: We take security as seriously as Microsoft ten years ago.

PHP: Doing it fast is always better than doing it right.

PHP: Proving that if any idiot can write an e-commerce package, any idiot will.

PHP: Yet another great reason to make regular backups.

PHP: Fast, cheap, and robust. Two out of three ain't bad, right?

-----
I'm liking this meme. Anyone got any more?

eGroupWare, of course!

[mangu]

I was assigned a task that would seem to be more or less the dream of any programmer: develop a QA management system (ISO9001 compliant, of course) for the whole company. Choose freely how you want to do it.

After searching all over for several weeks, I chose eGroupWare. Their "etemplates" framework settled the issue for me.

Re:eGroupWare, of course!

[Seumas]

I was assigned a task that would seem to be more or less the dream of any programmer:develop a QA management system (ISO9001 compliant, of course) for the whole company.

This completely explodified my sarcasmification detector . . .

Ruby resources

[Santana]

Heh, well, no offense but, people that use to reply like you haven't tried Ruby, or don't understand it. Otherwise you would be in love with it already.

We cannot compare PHP and Ruby. It's like comparing BASIC and Perl, you get the idea. Remember when you discovered Perl and all its magic? Well, that's what happens when you get into Ruby. It's a true object oriented and dynamic language ready for real applications.

This might or not make sense to you. It depends on the use you are giving to your language of choice. If you write one-liners in Perl, you might not feel motivated to move to Ruby. If you are writing templates in PHP for your web applications and you're doing fine, you might not need Ruby either.

You see the light :) when you want to write OO applications/scripts. PHP used to have an awful hack (I haven't seen PHP 5), so does Perl 5. Python would be your choice, but for some reasons I cannot explain (yes, this is subjective) Ruby feels more natural.

Ok, I have fallen again in the "I love Ruby so much" that gets you so bored. So, here is some homework for you (some very nice presentations and small articles):

Ruby: A transparent, object-oriented programming language
10 Things Every Java Programmer Should Know About Ruby
The Ruby Programming Language (by Matz, Ruby's author)
Thirty-seven reasons I love Ruby
Blocks and closures in Ruby