Read Dru’s Thoughts on PHP.
[A couple more thoughts after the jump]
I want to add a couple things:
- The fact that most of the top applications out there are written in PHP shows that PHP is simply the best language for solving the web problem.
- The fact that there are many successful products out there not written in PHP shows that the web problem is not that hard to solve.
- I think Rails is a great framework, perhaps the best framework. At the end of the day though it is a framework and just one framework reflecting one development philosophy.
- Rails is caught between the a sourceforge and a hard place. On one side, PHP has proven shrinkwrap solutions for download. On the other side, PHP has proven itself time and time again (scalability, speed of development, price of development, etc.), while Rails in unproven. Rapid Application Development is nice, but the problem is the pareto principle.
- Specialism beats generalism. There Is More Than One Way To Do It with Perl; anyone can read my Python; PHP solves the web problem ad hoc; Java runs anywhere and has a JIT. Ruby needs to distinguish itself.
- PHP is an easy, though sloppy language. It almost empowers the non-developer to be a web developer. PHP developers are cheap. These facts are really important to its success.
- PHP’s scalability comes from passing the tough solutions to another layer. This is often called “shared none architecture” but I call it “not solving the solved problem” or… being practical.
- Try not to have PHP be the bottleneck. If performance is an issue, try to find out why and see if you can push that part to another layer. PHP and performance is an oxymoron.
- Don’t violate the philosophy of PHP. Don’t try to teach the PHP dog new tricks: If you want a RAD framework, use Delphi or Rails, don’t make one in PHP. If you need threads or have very tight memory constraints for a component, use a language with threads and better memory management. If you want a web server, launch a web server. Don’t make PHP the server—that’s why they call it “glue.”
I agree with all the points (can’t comment of RoR, don’t know enough about it), apart from the last one.
Point 9 is a bit misleading though. A framework (either homegrown or something off the shelf) is pretty essential for a large scale website.
note to self, proofread *twice* before hitting post. >.
Good point! Here is the way I meant it. Taking some large scale websites:
– WordPress: the application is the framework
– Wikimedia: the application is the framework
– SugarCRM: the application is the framework
– phpBB: the application is the framework
So while you are correct as the framework is “homegrown,” they are definitely not RAD frameworks, they’re application-specific ones. I still feel that bullet is true.
There are exceptions to the rule: many of these use PEAR which is has two framework classes; a couple apps are built on Horde; there is certainly a blurring of lines for CMS frameworks and CMS applications; a lot of new developers are trying ZF and Symfony. Still I feel these exceptions prove the rule.
A lot of developers are trying CakePHP and loving it too. Point #5 is Specialism beats Generalism, and I agree that is true, so it follows that a specialized framework would be better than vanilla PHP. Further as you said in #6, PHP enables anyone to develop for the web. This results in many developers learning to program in different styles with the “application as the framework.” If you lo.ok at what people are doing with wordpress now you will see how badly they want a framework. BTW, point 9 completely misses the boat. I think I understand where you were going with it, but you seem to be saying a RAD framework can only be made in Ruby, which is drastically undercutting the power that is PHP. PHP is not RAD just as Ruby is not RAD, but RAD can be done in both and that is a good thing. Remember, as soon as you cease to teach old dogs new tricks, they sit under your coffee table shedding all over your rug, drooling, and generally being nothing but a vacuum cleaner around the kitchen table.
It comes down to standards. We have standards on the Web for a reason. Applications by essence create standards to operate within. PEAR attempted to create a standard approach. CakePHP and other frameworks do the same create the most structure and enable RAD.
The most experienced developers can manage without structure and standards because they have their own. As you trickle down, structure and standards empower the developer to find an approach that others will understand. I can take a CakePHP application give it to someone else and they will know instantly what is going on. This is any CakePHP based application not just one or two. Why would I want to learn an API for a different CMS, CRM, or Blog when I could learn how the underlying framework works and therefore understand any application that works with that framework.
Frameworks are pushing PHP forward, not moving it back. They are empowering developers to share ideas and expand their knowledge. In general, they are teaching developers good coding practices and how to use OOP in a successful way.
Let’s stop for a moment and use my metrics:
Well take all the webites built on CakePHP and compare it to all the ones built on top of WordPress. Who has more?
We’ll take all the users who use every application built on CakePHP and compare it to all the users who have used Tagged, not even close to the largest social network built on PHP (Friendster or perhaps Facebook soon take that). Who has more?
CakePHP is a generalized framework because it can be configured to make a blog or a social network (as examples). There is no doubt that WordPress or Tagged themselves use frameworks that are self built. And you know Cake’s architecture is like 1000x cleaner than WordPress (and I’ll tell you that it is 100x cleaner than Tagged’s)
BUT
I’ll say flat out anyone who wants to host their own blog is going to download WordPress over building it in CakePHP. If Tagged used CakePHP for our back end with our millions of users and many different componets, CakePHP would roll out and die. The data object model alone would cause our database tier to crumple.
@gwoo: Touched a nerve there, did I? 🙂
“A lot of developers are using Ruby on Rails too and loving it.” Isn’t it funny how that only translates into a lot of overhyped Web 2.0 sites (*cough* 37Signals *cough*) but not into a lot of successful ones? (I’ll define success as sites that bring in say at least 10 million USD a year.)
To #5, PHP is a language, it’s not a framework. If I want to compare apples-to-apples then it’s Ruby vs. PHP, Rails vs. Symfony vs. ZF vs. CakePHP.
To #6. I look at WordPress and I see a wildly successful product written on very shoddy code. I see a marketshare that David Heinemeier Hansson would gladly trade 37Signals, all the Rails development he’s ever done, and his left arm for.
To #9: You are free to disagree with me. In fact, I expect it since you write CakePHP. See the issue is while it is easier on paper for someone to develop a blog or a wiki in CakePHP than from scratch using PHP, it begs the question of what happens in practice. Matt Mullenweig didn’t build WordPress in Ruby on Rails, or Cake, or BinaryCloud, or whatever, and neither did Jimmy Wales make Wikipedia that way. Neither were programmers by any definition: Matt likes to take photos and Jimmy sounds like a librarian with a kimono fetish.
And as far as the lame “teaching” excuse, I say learn to code Python if you want a language that is easy to teach. Or maybe Pascal. Java is a common teaching language in universities for over a decade now. What has it given the web world? J2EE? Hah!
Finally, I never claimed that frameworks are moving PHP backwards. However, I am going to claim that 90% of SPL can be flushed down the toilet and it’ll be like a tree falling in an empty forest. I am claiming that results trump theory. I am claiming that I’d like you to show me wrong about Cake PHP and me eat humble pie.
Or is that humble cake? 🙂
Good luck with CakePHP.
Thanks for the well wishes. Btw, humble cake is delicious. 😉
@Garrett. I know I come off as a little harsh, but I really do mean what I say: I do wish you guys well, I follow what you are doing there, and I do love humble cake.