[UPHPU] CDBaby Return From Rails to PHP

[John David Anderson]

On Sep 23, 2007, at 2:21 PM, jtaber wrote:

> By now, unless you live in a cave, you've all probably read the new  
> Digg/Slashdot article ref CDBaby and their return to PHP from  
> Rails.  But the author misses several things besides the effort  
> being a disaster in project planning and mgmt.
>
> It's true you can easily set up model-type classes in PHP.  In fact  
> I prefer these over Rail's model classes.  But for most other  
> stuff, it's just a case of more effort, complexity, time, and thus,  
> money.  The owner makes some good points about ease of PHP  
> deployment but really misses some of the key problems we had with  
> PHP :
>
> 1) Lack of Built In Testing - I guess there are some external tools  
> like UnitTest but nothing as easy as in Rails.  And sites without  
> testing, well....

There are hordes of PHP unit test packages. PHPUnit, SimpleTest. I  
don't believe Rails' testing is any better or worse than PHP-flavored  
offerings.

> 2) Lack of Good Redirecting - Rails uses a great front-end  
> controller and it's simple to call redirects and linktos from  
> anywhere.  PHP has some real restrictions with redirects (ie before  
> html output, etc).

You can buffer output if you need to. It's not a PHP-limitation: that  
location *header* has to come before anything else. There's nothing  
PHP or Ruby specific there. Code it up different if you want.

> 3) Lack of Good Data Protection/Integrity - simple things like  
> built-in protection against injection attacks

Who cares what language you code in to prevent SQL-based attacks? I  
don't see how Ruby or PHP would really differ at all. You could  
probably create a safe website in BASIC if you wanted to. I don't  
think you can say that Ruby is "safer" than PHP or Java or whatever.

> 4) ORM - actually this is more questionable but ORM comes in really  
> handy in things like views where you don't need to do lookups/ 
> retrieval to show something like invoice.customer.name

You can't have ORM with PHP? I've been using packages that do that  
for a long time. Most frameworks come with something, and there are  
stand-alone packages like Doctrine and Propel.

> The lack of these things make us much more productive in Rails or  
> Django than in PHP.

Rails and Django are not languages. Please compare apples to apples.  
It's like saying Scrum and XP are more productive than English.

I think the choice of PHP over Ruby is a deployment based issue. I  
don't see how Ruby (or Python, or whatever) has a significant  
advantage over PHP just by virtue of the language itself. I realize  
Ruby has some really nice features, but the bells and whistles there  
don't make much get-it-done difference in the long run. You can write  
applications just as easy in either. I can get things done if  
everything isn't an object, without lambda functions or whatever. Sorry.

That said, I think its great to keep up on things. I've developed  
applications in Rails, and there were lots of things I liked (and  
brought with me back to PHP).

For me, it's a matter of familiarity and preference, and a  
realization that Rails (and Ruby) is still very new and is dealing  
with some growing pains. Besides, if you pick a good PHP framework,  
you get all the MVC goodness that comes from Rails methodology, and  
the stability and ubiquity that comes with PHP. For me, I've been  
enjoying the productivity the Rails methodology boasts of for  
years... in PHP.

-- John