RE: Re: Ruby on Rails and other sites use PHP?

Rails
1

of tasks?

Why is a hammer better than a screwdriver at hitting nails ?

You could weld a screwdriver onto a hammer, but the end result would be
a
tool that’s better at using screws and worse at it’s core functionality:
hitting nails. Would this be a better tool ? (it would also have a
bigger
learning curve and more accidents would happen with it, and a lot of
beginning carpenters would get confused and start trying to hammer
screws)

Hobbyists use swiss army knives - pro’s don’t: they have the right tools
for
the job and know how to use them in order to get a better result faster.

My 2 cents…

Piet.

2

This question of PHP vs Rails comes up more than enough, and it
therefore
needs to be seriously addressed.

I used to work for a company specializing in PHP web development.
Towards
the end of my employment I was advocating the development of a PHP
framework
based off of Rails and Cake (the open source PHP framework inspired by
Rails). I spend a little over 2 months putting together a prototype of
a
PHP like Rails. The endeavor has illuminated many fine points of this
distinction. In an attempt to answer the question of “Why would anyone
prefer PHP over Rails or visa versa?”, I present the following with an
emphasis on the implementation.

  1. Ruby over PHP

a) the PHP parser is too inflexible.

  • The biggest caveat of PHP is that methods cannot be added on the fly
    to
    classes without compiling in a special library called runkit, located at
    http://php.net/manual/en/ref.runkit.php. In other words: classes are
    closed
    upon definition. If one wants to create an active_record like ORM then
    one
    is determined to include runkit when compiling the php parser or write
    class
    definition files to the hard drive on the fly.

b) PHP references are kludged in PHP4. It is common to pass by
reference in
C and C++ in order to save memory and utilize return value optimization.
In
my implementation of a PHP version of Rails I ended up splitting an
“ActiveRecord” into two classes: a Factory and an Object class. Each
object
instance would have as a data-member a reference to its Factory in an
effort
to not duplicate the sql_generation methods. The Factory instance would
also contain all of the instances of its objects, hoping that each
object
would simply be a reference into the Factories container. As a bug,
when
the objects filled up memory so did the reference count… I belive
this is
fixed in PHP5.

c) is possibly two counts: an overbearing responsibility upon global
methods
in PHP, and the fact that PHP’s object.c class is designed to do
everything. Addressing the later first, I acknowledge that both PHP and
Ruby have base object classes. Their distinction is that, in Ruby the
object class is designed to provide methods to all inherited objects,
whereas in PHP the object class is designed to also contain data: for
example, there is a minimal distinction between PHP’s array data
structures
and PHP’s object data structures; the two are almost equivocal and it is
therefore tiresome to distinguish (in code) between objects, arrays and
hashes (what PHPers call associative arrays). As a result there is a
lot of
type checking in PHP. I suspect that this equivocation is the main
reason
for the plethora of global methods.

d) finally, I find that the simplicity of Ruby’s to_s style methods put
the
language above and beyond both Java and PHP. However, I fear that I am
not
expert enough to defend this adequately.

It may not be hidden that I loath PHP, and mainly because of the
presence of
(c). However I also feel that PHP has its place. Let me elaborate.

  1. PHP over Ruby

a) PHP’s learning curve is close to nothing. Switching mentalities
between
Java, C and C++ to PHP is admirably easy. Most CS graduate students
only
have experience in the three canons of development languages listed
above.
The better education includes experience in Scheme, or Lisp, for the
shear
breadth of syntactic understanding. Most of us do acknowledge the
importance of pseudo code and see that all implementations are just
divergent from that initial “pseudo” logic. However, as a precondition,
some development environments cannot cater to a heightened sense of
programesque. In other words, there is a need for non-CS people to
write
web based programs and PHP satisfies that need.

I do, in an elitist fashion, consent that Ruby is the superior language
over
PHP. However I also realize that PHP satisfies a niche that is
difficult
for Ruby to semantically attain (however it is certainly possible to
attain
a php (read global) like semantic).

  1. A little bit about Rails

Insofar as I can tell, PHP has another upper hand over Rails/Ruby, and
that
is the support PHP has within Windows Servers. One of the major
setbacks I
encountered in a PHP version of Rails was the esteem of the
dispatch.fcgi.
Windows servers are mainly processed based (as opposed to thread based),
and
therefore prefer to spawn another parser for each request rather than
handle
an error in a thread. PHP has done an awesome job making a fastcgi port
of
their parser. PHP’s fastcgi is oriented towards ever .php file rather
than
just one dispatcher. I would love to see Ruby duplicate this effort in
their own fcgi such that it can run different dispatch.fcgi’s.

Such a framework as Rails is possible in PHP, however because of the
implementation restrictions of PHP, developing a “Rails” for it should
be
tiresome, if not mind wracking. However, I do not think there should be
a
Rails equivalent developed for PHP solely because the language fits a
different niche; if I were to describe it, I would say that it is the
quick,
easy and dirty.

Regards,
Travis Michel.

3

Thanks Derrick, By far a better post than mine. It is at base a
pragmatic
issue.

4

…
Hobbyists use swiss army knives - pro’s don’t: they have the right
tools for
the job and know how to use them in order to get a better result
faster.

Yes, this is the meat of the matter. It’s about using the right tool
for the right job. Rails for a simple static website is what we call
“overkill”. Yes, rails is capable of performing this “simple but
frequent kind of task”, but why would you use it for that? It’s more
akin to using a sledgehammer to drive a finishing nail.

David makes an excellent point about the variety of technologies
employed on the rails site. Actually, I think that reflects
positively on the rails community as a whole. This is not about
starting some rails religion (sorry perl guys). It’s about
pragmatism. Get it done in the best way possible in the least amount
of time.

-Derrick

5

Piet, Derrick, David and all

>> For wiring together static pages? I rather like PHP. I wouldn't
>> recommend anyone to use Rails for something as simple as wiring
>> together a couple of static pages with headers and footers.

Please explain WHY and HOW PHP is better than Rails, to somebody who
doesn’t know PHP.
If it’s really better, then it may be worth learning but so far, nobody
has explained why they think PHP is better.

Alain

6

On 2/6/06, Alain R. [email protected] wrote:

Please explain WHY and HOW PHP is better than Rails, to somebody who
doesn’t know PHP.
If it’s really better, then it may be worth learning but so far, nobody
has explained why they think PHP is better.

To put a header in using PHP:

include(“header.php”);

To put a header in using Rails:

Generate a rails application
Create a layout
Create your controllers
Create your views
etc.

The point is that Rails is a framework for building web applications,
and PHP is a programming language. You don’t need the large overhead
of a framework for putting some headers and footers on a few pages.
Instead, use a single line of PHP and forget about it.

Does that Help?

Josh

7

On Mon, Feb 06, 2006 at 10:56:02AM -0600, Josh C. wrote:
} On 2/6/06, Alain R. [email protected] wrote:
} > Please explain WHY and HOW PHP is better than Rails, to somebody who
} > doesn’t know PHP.
} > If it’s really better, then it may be worth learning but so far,
nobody
} > has explained why they think PHP is better.
}
} To put a header in using PHP:
}
} include(“header.php”);
}
} To put a header in using Rails:
}
} Generate a rails application
} Create a layout
} Create your controllers
} Create your views
} etc.
}
} The point is that Rails is a framework for building web applications,
} and PHP is a programming language. You don’t need the large overhead
} of a framework for putting some headers and footers on a few pages.
} Instead, use a single line of PHP and forget about it.
}
} Does that Help?

I now understand what you mean by PHP being better than Rails for this.
I’m
not clear on how PHP is better than straight .rhtml files, however.

} Josh
–Greg

8

Please explain WHY and HOW PHP is better than Rails, to somebody who
doesn’t know PHP.
If it’s really better, then it may be worth learning but so far, nobody
has explained why they think PHP is better.

Beauty is in the eye of the beholder. There are lots of programming
languages today, and there will be many more in the future. At the end
of
the day the tools we are discussing end up producing some type of HTML
or
equivalent. How you get there is up to you.

Better is a very subjective term. I think it is an apples and oranges
comparison as Rails is a Framework and PHP is a language. I have used
PHP,
ASP, ASP.NET, Java, and perl… Lately I ride the Rails. The diversity
of
my toolbox allows me to see value in the Rails framework. If you have
never
used PHP, and don’t feel the need to… don’t.

~ Ben

9

On 2/6/06, Gregory S. [email protected] wrote:

I now understand what you mean by PHP being better than Rails for this. I’m
not clear on how PHP is better than straight .rhtml files, however.

I’m not sure .rhtml file will run without the framework… not too
sure about that.

Josh

10

Josh

 > To put a header in using Rails:
 > 1/ Generate a rails application
 > 2/ Create your controllers
 > 3/ Create your views
 > 4/ Create a layout
 > 5/ etc.

Well No: you just need to 1,2 and 3

 > 3/ Create your views

Fair enough, it’s the content, as in PHP

 > 1/ Generate a rails application

Yes, that’s required.

 > 2/ Create your controllers

You wouldn’t need this step if ‘rails myapp’ would create a controller
by default.
I’d also prefer the empty Rails app to come with a index.rhtml, instead
of index.html.

 > 4/ Create a layout
 > 5/ etc.

No, nothing else is required.

So, all it would take is for ‘rails <your_app>’ to generate a controller
by default, and replace ‘index.html’ by “index.rhtml”.
Maybe we’re still here because core people don’t feel this pain, as
they keep using PHP for those “trivial” tasks.

Alain

11

On 7/02/2006, at 5:38 AM, Alain R. wrote:

Please explain WHY and HOW PHP is better than Rails, to somebody
who doesn’t know PHP.
If it’s really better, then it may be worth learning but so far,
nobody has explained why they think PHP is better.

PHP is not ‘Better’ than Rails. PHP is just easier and less resource
intensive for some tasks. Take putting a standard header in every
file for instance. You can do this with Rails, it isn’t hard, but
then you’re running a Rails application for a two page site. Rails
takes substantial amounts of RAM, especially compared to PHP, and
once you have 10-20 customers on one machine you’ll see. (based on a
memory usage of ~15MB per application instance)

PHP shares the engine between multiple sites, one block of memory for
all customers. You can then put hundreds of sites on one machine.
Also you only need two files - the content page and the header page,
plus mod_php installed. Rails needs a whole bunch of support files
and a fastcgi runner.

If I have to create a database driven web application I’m leaping
straight to Rails, it’s much nicer. If I need to do 5 pages with
common headers and a contact form PHP is easier.

Plus there are many more PHP programmers than Ruby/Rails programmers.

–
Phillip H.
[email protected]
http://www.sitharus.com/

12

Phillip H. [email protected] wrote: Plus there are
many more PHP programmers than Ruby/Rails programmers.

I don’t think that will stay true for long.
Frank

13

On 2/6/06, Alain R. [email protected] wrote:

Well No: you just need to 1,2 and 3
The Layout is the most important part, as it mimics the header a
footer bevahiour that we were discussing, which was the whole point of
my message. If you just have a few static pages that require headers
and footers, of course go with PHP, because it’s alot simpler.

Rails is an application framework which means (gasp!) it’s meant for
building web applications. For simple header and footer work, Rails
is too much. It’s like using an abrahms tank to kill a horse fly.

So, all it would take is for ‘rails <your_app>’ to generate a controller
by default, and replace ‘index.html’ by “index.rhtml”.

Actually, it would be a little more than that. It would mean removing
index.html completely and letting dispatch.cgi do it’s magic.
routes.rb would need to be able to connect to this automatically
generated controller as default. Replacing index.html with
index.rhtml doesn’t gain you anything as rails would never be invoked.

Josh

14

softwareengineer 99 wrote:

/Phillip H. [email protected]/ wrote:

Plus there are many more PHP programmers than Ruby/Rails programmers.

I don’t think that will stay true for long.
Frank

I do… Rails may be “the best thing since sliced bread” for building
web apps, but 90%+ of the web aren’t actual web applications. If all you
need is some dynamic server-side stuff sprinkled around your largely
static web site, you shouldn’t be using Rails. That where things like
PHP, ColdFusion, what-have-you, will always be better tools. And that’s
not a bad thing.

Leave the web application building to the web application developers.
Leave the simple dynamic stuff to the web designers and “HTML coders”
out there. Division of labor, at this level, is a good thing, IMO.

-Brian

15

PHP and Perl/CGI have the advantage that they are there on every web
server.
For many small applications it is a requirement to run on an existing
server
without a lot of installation and administration effort. Or it is a
requirement
to pick a hosting provider without being bound to the additional
constraint
of having rails running.

Sometimes it is much better, to run a perl script to add certain headers
and footers
to a web page of static html. This can even be done by a cron job. Why
worry
about recalculating the page for every viewer?

I would not consider it a good idea to build a complex application in
PHP,
but it has been done successfully, just consider wikipedia.

How is this scaling issue: Would it be an option to write such a
heavily used
application as wikipedia in Ruby on Rails or would it require so much
hardware
that wikipedia could not exist like we know it now?

Best regards

Karl B. <bk1 at …>

16

Brian
> I do… Rails may be “the best thing since sliced bread” for
building

web apps, but 90%+ of the web aren’t actual web applications. If
all you
need is some dynamic server-side stuff sprinkled around your
largely
static web site, you shouldn’t be using Rails.

Once again, it’s not an explanation, just a fact stating:
“Rails is less good at this because PHP is better at this”.

I don’t think that PHP is too complex, but it’s one more tool to
install, configure, optimize, maintain and master.

Honest technical question in search of an honest technical answer: can’t
Rails be optimized in that area too, or is it just a “we don’t feel like
it because we use PHP for those cases, and it just works for us.”.
Just imagine if Rails would not handle web services efficiently and you
needed it. Would you be happy with a “use Java, it’s better at web
services”?

When working in Java, I would used to use Tomcat as an app AND as a file
server. It was not the fastest, but it was fast enough for my needs.
Over time it improved. Why would I have bothered putting Apache in the
equation?
Same story here: “Two tools good; One tool better”.

Alain

17

On 7/02/2006, at 9:13 AM, softwareengineer 99 wrote:

Phillip H. [email protected] wrote:Plus there
are many more PHP programmers than Ruby/Rails programmers.

I don’t think that will stay true for long.

Lets hope you’re right :slight_smile:

–
Phillip H.
[email protected]
http://www.sitharus.com/

18

On 7/02/2006, at 10:06 AM, Alain R. wrote:

Honest technical question in search of an honest technical answer:
can’t Rails be optimized in that area too, or is it just a “we
don’t feel like it because we use PHP for those cases, and it just
works for us.”.

Rails is opinionated software. Rails does web applications, it does
nothing else. It doesn’t do the simple cases, you can use eruby
direct from mod_ruby, you can use SSI, you can write your own Ruby
CGIs. This is what makes Rails such a pleasure to work with, the
domain is chosen and it won’t expand, unless you use plugins.

PHP is a mess because it tries to be everything to everyone. It just
won’t work. The language is clunky and the class system is appalling,
but it handles the basic cases well.

Rails works with full-blown applications. It does it well. Running a
small static page with Rails is slow and a waste of resources, but an
application that has to be maintainable and makes sense for a MVC
architecture works very well.

Think of what you’re doing, choose the tool. There’s a reason why
POSIX compatible systems have a whole heap of tools but don’t have
one tool to do everything.

19

On Feb 6, 2006, at 2:10 PM, Phillip H. wrote:

Plus there are many more PHP programmers than Ruby/Rails programmers.

This may be great if you’re trying to hire a programmer, or get help.
But then again, maybe not. If RoR is as productive as people here
claim, then hiring one good, hard-to-find RoR programmer would
actually be better than hiring three good, readily available PHP
programmers. I seriously doubt (s)he would command three times the
salary of a PHP programmer, so I should save money. Secondly, there
would need to be less corroboration with the smaller team, so (s)he
would get more done. (The Mythical Man-Month effect)

Sometimes less is more. Less code is definitely better. If anyone
thinks more is better, remember that roughly 94% of the world uses
the Windows operating system. Okay, maybe that IS the better option,
if you’re into writing viruses. :wink:

Doug

20

On Mon, Feb 06, 2006 at 11:09:34AM -0600, Josh C. wrote:
} On 2/6/06, Gregory S. [email protected] wrote:
} > I now understand what you mean by PHP being better than Rails for
this. I’m
} > not clear on how PHP is better than straight .rhtml files, however.
}
} I’m not sure .rhtml file will run without the framework… not too
} sure about that.

Under Apache, you need mod_ruby (and appropriate configuration), but
then
they do. I have used it with Apache2.

} Josh
–Greg