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

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.

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.

Zelots.

[Saeed al-Sahaf]

Why is it that there is very little PHP discussion here, and this story has been taken over by the RoR zelots? Seems like that's par here at Slashdot.

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.

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.

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.

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.

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

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