PHP is a framework. True it's not a particularly nice one, and some people build even more layers on top, but it comes with all manner of HTTP/url/DB/etc. stuff out of the box. It's also a templating language (that's what the "<?php" tags are for); although, again, not particularly great, and some people layer more abstractions on top.
In the sense of comparing PHP and Rails, then no PHP is not a framework. Codeignitor, Laraval, Cake, Yii; those are PHP frameworks and fair comparisons to Rails.
I can (and have) just grabbed Rack and rolled most everything myself in Ruby and it has way less overhead and is much more performant than Rails. Ruby also has it's own templating language; ERB is part of Ruby core.
So comparing PHP to Rails is a bit apples and oranges.
it's a business decision comparison, not a technical categorical comparison. you need something to receive http request and return http responses, and you're comparing different popular (because hiring, training, and available community / support resources) ways to do that. they might be apples and oranges but at that level you're concerned with comparing fruits.
In this case it was a technical comparison; the original poster stated, "php's performance was an order-to-two or magnitude better than rails".
If you are making a technical comparison then it needs to be at the correct layer of abstraction. If we were to compare performance of Laraval and Rails that would be a fair comparison.
If we are comparing on performance then PHP should be probably be compared to Ruby+Rack since that is sort of the lowest common denominator.
I'm not dogging on PHP here either. Even comparing at the correct level; PHP is still faster, but lets make sure we are making the right comparisons.
as the other commenter said, php is a web framework... and it's what we were using. it's actually more of a web framework than a language in my opinion (or at least was at that point). it's centered around receiving http requests and writing http responses. the article mentions this in fact.
it was a huge pain to try and get php to do anything else. it was totally unpractical to do the kinds of back end processing that we needed (since the database was pretty much off limits during a http request)... long running processes with hundreds of millions of objects were a no-go. believe me, we tried. which meant you had to sync all your logic into Java or something else that could handle the job. which is really error prone when you have a bunch of people moving fast on something.
one of the greatest things about php is that it's a super minimal focused framework. it's also one of it's major short-comings when that model no longer suffices.
you can layer something else on top of it, but the stuff available at the time certainly didn't help the performance or memory characteristics.
Again PHP (the language) vs. Rails (the framework).
What framework was that `big php app` using?
reply