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

Pretty obvious answer

[rylin]

Our in-house framework, as it does precisely everything we need - no more, no less.

Re:Pretty obvious answer

[KILNA]

Indeed. You have the choice of someone else's idea of what features and work-flow you need, or your own. Writing wrapper classes for output, databases, etc. isn't that hard, and you can get a solution 100% tailored to you needs.

The only argument I could imagine for using someone else's framework is to reduce the overhead to bring in new programmers since they'll already know much of the ropes. But in the case of PHP there really isn't a clear winning system with a large pool of available programmers...

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?

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.

Re:uh-oh

[downward dog]

I switched from PHP to Ruby after reading the Pragmatic Programmer's tip to learn a new language every year. Learning new languages makes you a better programmer, and Ruby is a great language to learn.

After only a few months using Ruby on Rails, I can't imagine trying to manage a large project in PHP. My attempts at OOP resulted in huge classes (100+ lines), my code wasn't reusable, unit testing was nonexistent, and adding functionality to an existing page usually meant breaking the rest of the application. I'm sure that there are better programmers out there than I was, who can avoid these problems while using PHP. That is fine. But Ruby and Rails helped me to become a dramatically better programmer.

Re:uh-oh

[mysticgoat]

I also go along with the sentiment (of sometimes wanting to avoid learning yet another language).

This can be summed up with the question: "Is this guy a programmer with ten years' experience, or a programmer who has repeated one year of experience ten times over?"

As Grasshopper plans his career it can be good if he asks himself how others will see him in a few years.

Re:uh-oh

[ibbey]

This argument falls flat pretty quick. You don't need to abandon everything else you've learned to learn a new language. I'm not arguing that you need to learn every new language that comes along, but spending an hour learning -about- a new language is quite reasonable. Once you've done that, you can make a reasonable decision about whether you should continue and learn more.

Every language has advantages & disadvantages. I love Ruby & Rails, but for some jobs, I'll still use PHP. Some jobs are best suited to Perl, and some to C. A good programmer will be able to choose the best tool for the job at hand. Remember, all four of these languages have the same underlying inspirations, so once you know one, it's much easier to learn another. If you're a good PHP or Perl programmer, you can be a competent Ruby programmer in a week with some effort. Do you truly believe that your career & programming ability will be better served by NOT making that effort? If so, that's fine, that just leaves more jobs for the rest of us.

Re:uh-oh

[f0rt0r]

Good point. A company thinks long term. Jim Bob wants to code a new solution in Ruby because its fun. What happens when Jim Bob leaves the company? Or transfers to another department. Omg, now John Bob has to learn Ruby and support it. 90% of the apps in the company are in Java and Jim Bob's manager approved Ruby.

Now his manager's manager wants to know what the business case was for coding in a langauge that:
1) No one else knows.
2) Could have been done in Java.
3) Offers no benefits over other languages already in-use in the company.
4) Has not been tested in the heterogenous company enviroments
5) Has no standards in place for system and user acceptance testing,

OK, he is sweating the decision he made to allow Jim Bob to use Ruby. Looks like he should have first come up with a business case for moving to it and made sure it passed the 'ritual of fire' before creating a solution in Ruby.

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 ...

Re:Which PHP5 Framework is Your Favorite?

[alatesystems]

Dude, I totally wish I could mod you up right now for that totally subtle Office Space reference. That made my morning.

+5, Awesome

Re:lame excuse

[D'Sphitz]

How about just accepting that while Ruby may suit your needs just fine, most people aren't interested. Then you can quit wandering around all pissed off at everyone because they don't use Ruby, and be happy that you use Ruby even though other people prefer Python or PHP.

Seriously, is Ruby some kind of a cult or something? I thought mac zealots were bad, but everytime a scripting language is mentioned the ruby enthusiasts come out with such hate for everything non-Ruby. Get a grip.

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.

Re:lame excuse

[namekuseijin]

i said "modern, multi-paradigm, very higher-level language", not a "severely patched M$ offering for a very old, simple and basic language for beginners", not unlike PHP btw.

"find that even if it takes a bit longer to code, you will get better results out of C/C++/ObjC."

"Inevitably, as higher level languages are written in C, you're almost always going to find that you get better performance out of a comparable C app."

ah! the "slow performance" argument, easily refutable by noticing that most performance bottlenecks in systems come external factors like file system, DBMSs, network etc; and also that most libraries for such languages are just ( mostly thin ) wrappers for native libs.

"As for scripting, PHP is pretty good now. It used to be trashy, but version 4 and 5 are very nice, easy to work with, and reasonably fast."

it really isn't: it's still a mess of a language with no support for modularization other than OO classes or relying on shallow naming conventions for functions in the global namespace.

"Python's not my cup of tea (little too much like Java for me, and I really don't like my "language" to include a library for everything; I can find my own and include them or write my own). Ruby would be interesting to learn, but

"I doubt if I'd ever use it for anything."

you won't. remember the mantra: "right tool for the right job"

"don't really mind if the language dies in the next ten years, Ruby or Python will work for you. Meanwhile my C app will be maintainable by the newest upstarts to the oldest of the oldies"

FUD. plain and simple. your C app from 10 years ago most likely depends heavily on external 3rd -party libraries that may be hard or impossible to either find or make them work today.

Python, Ruby and company are open-source projects with already more than 10 years old and are likely to stay.

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?

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.

Re:Which PHP App?

[TheTomcat]

"Database abstraction? Why would anyone need that?"
http://php.net/pdo

"Namespaces? Why would anyone need that?"
it's coming

"Design patterns? What are those?"
http://php.net/language.oop5.patterns
http://phppatterns.com
php|architect's Guide to PHP Design Patterns

"Security? If it's a problem, we'll fix it later."
http://php.net/security
(Almost all of PHP's historical security problems have been third-party.)

S

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 . . .

Re:Zelots.

[aminorex]

When a large number of intelligent people with practical experience conclude that a given tool is superior to another given tool, it's a good idea to check it out.

PHP is very accessible, and that's a great strength. But any time you start talking about "frameworks", you're well outside the user base that is best served by accessible.

Having said that, there are a lot of big PHP projects doing good service in the real world. It might not be the place to start new development, but integrating it into new development is going to be important for years to come. I'd be particularly interested to hear of good experiences integrating existing PHP apps with RoR development.

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

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*

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.

Re:People vs. Technology

[ttfkam]

Actually, in PHP and PHP/FI days, that was common practice, and in some languages still is.

I meant predecessors like Perl. As for common practice, not in any circles I've been exposed to. Even C tutorials from twenty years ago for command line apps preach distrust and validation of user input as standard procedure.

In the modern internet, the practice is unforgivable.

frameworks? no i18n, no custom auth, ...

[HTD]

Almost all the frameworks, no matter which language they are written in, don't provide the basics for a real world application. What about i18n? I have yet to see a framework where the template system AND the application supports translation of messages.

Customize Authentication? There are more complex apps that don't just require username+password to login (e.g. logon to database - username+password+database depending on the database you may have access or not). Also users may be in many groups, each group having different rights, even each user could have different rights - where the next isssue comes up.

Only few socalled frameworks have rights-management. There are actions that should be restricted to qualified users, like editing customer-accounts, adding new co-workers. There are things that should be displayed only to certain users. Think of current items in-stock of an online-shop. You probably want to show the shops co-workers the real in-stock amount and some info when the next delivery of that stuff is coming and the customers would see in-stock minus 10% and no info on the upcoming delivery - from the same template, only difference is the rights the user has.

These are just 3 examples of missing functionality that keep me from even considering any of those "frameworks".