Ui Designing with Rails opposed to PHP

I’ll restate the obligatory: PHP is a language; Ruby is a language; Rails is a Web App framework. So…

Up until recently, the deployment story for PHP was stupid-simple because it was on almost every shared Web host running in mod_php and you could sign up and have “Hello World” serving up Web pages in 5 minutes. PHP is (debateably) a bit more Windows-friendly as well. CPanel on the shared hosts set up .conf files for Apache that made everything work nicely for a PHP app and you really didn’t need to know what was going on under the hood.

Rails started out with a bleak deployment story, but quickly Switchtower, renamed Capistrano changed that. But ever-changing recommended “Rails stack” has made deploying much more of a decision-making process than pushing out a PHP app. Things were beginning to settle down with all the cool kids setting up nginx servers proxying to mongrel (or thin or evented-mongrel) clusters and along came Phusion Passenger. That’s mod_ruby. Now Rails deployment is stupid-simple.

But in either case, you really do need to know something about what’s going on under the hood. If you’re doing anything that matters, you’ll want to get it right. Repeatably right. Testably right. Not so easy for Rails, even harder for PHP.

Since s.ross talked about deployment differences I'll skip over them
here.

If you are just talking about writing a PHP app from scratch as
opposed to using Ruby (the language) with Rails (the framework) then
there is NO advantage to using PHP. Rails gives you so much help with
the little annoyances that you no longer have to worry about the
little things and can concentrate on the big things.

Now, if you prefer coding in PHP there are frameworks out there such
as CakePHP and CodeIgniter that are open-source MVC frameworks for PHP
that work similarly to RoR.

I was a PHP coder long before I switched to RoR and have tried both of
those frameworks. They are pretty good, but I didn't *get it* with
those frameworks like I did with Rails. IMHO Rails makes much more
sense, as in 'common sense.' I find that I don't have to look up as
much in documentation because my first 'guess' as to what a function
is called, what the syntax of a particular feature is, etc. is usually
correct.

However, it's all personal preference so I would suggest trying out as
many different frameworks as you can and decide which one is best. If
you have any python experience try Django, if you are a Microsoftie
try ASP.NET MVC, and try out the PHP frameworks I mentioned. Decide
what you are most comfortable with.

However, they are very different kinds of language.

PHP basically starts with HTML and adds syntax to add logic.

Ruby starts as an object oriented programming language and adds
library code to produce html and other stuff. Ruby provides powerful
features to aid modularity and the implementation of domain specific
language extensions which can be implemented just with Ruby code.

A more direct comparison would be between PHP and erb, which embeds
logic written in Ruby within HTML.

Many people starting out may find that PHP is easier since you can
start with HTML, and add a little UI logic, and a little database
access right there.

The problem is that, as your application grows, you can quickly end up
with a complex beast which is hard to understand and maintain.

I've seen too much PHP code which has reached this point, and I've
turned down a few consulting gigs which would have involved living
with that.

It's possible to write nice modular maintainable PHP code. One good
example, at least the last time I looked at it, is mediawiki which is
the engine behind Wikipedia. But it takes a certain expertise to
start out, and a lot of discipline to keep the code under control.

The advantage of Rails is that you start out with a nice modular
maintainable structure, and as long as you don't fight it, your code
will stay in a "better place."

Steve Ross wrote:
[...]

along came
Phusion Passenger. That's mod_ruby.

[...]

I agree with everything in your post except this factual error.
Passenger is also known as mod_rails. Mod_ruby is a different, much
older module; it was not designed for Rails, and is in fact useless for
Rails deployment (it's meant for Ruby CGI scripts).

Best,

Although at this point it would be more accurate to call it mod_rack,
since it support rack apps in general, not just Rails

Right. Sorry about the mod_* reference. Right now, I have a Sinatra and 5 Rails apps running under Passenger. The point is that Passenger runs as a module under Apache, which is one of the most widely used http servers in affordable hosting contexts. For the OP, if you aren't already familiar with the problem that's being solved here, many of the interpretive languages, Perl, PHP, Ruby among them share the limitation of a bit slow to start. Thus when a Web server such as Apache gets a request, it's a two-step process: load the interpreter, then process the script. This is the old CGI model, but it's both slower than mud and resource intensive.

The solution was to load the interpreter into a module under Apache (or a DLL under Windows IIS) and then direct that instance to process the script. That made the request/response more of a one-step process because processing the script typically takes a fraction of the time loading the interpreter does.

There were significant problems with the original mod_ruby, so people just didn't use it for Web applications, preferring instead to use a variety of different Ruby wrappers that loaded the interpreter and some Rails infrastructure and then served proxied requests back to Apache.

Given that mod_php has been around way longer than mod_rails, there has been a version of PHP that performed acceptably for a good deal longer than Rails. That's no longer the case, but there still is an expertise gap, if you will. As was mentioned earlier, plenty of PHP programmers are out there and plenty of good software is written in PHP. And plenty of dreadful software. Most people who try Ruby and Rails simply enjoy programming with them so much more than PHP that they just don't want to go back. I had to maintain some of my old PHP work and found myself in syntax hell. At this point, Ruby does what I expect and I can write expressively.

I can't emphasize enough the strength of the testing tools available to the Ruby (hence Rails) programmer. These are so insanely cool that it would be irresponsible not to take them into account when comparing language/frameworks.

There's really not much more I can say except to recommend you try creating a simple application with both and see how you feel about the code you're writing.

Out of curiosity, why do you ask. (Again, to the OP)

Steve