Comparing Rails vs. PHP to a non-technical audience

Question

I recently had an interview at a small company that wants to greatly increase its web presence, including re-writing their Flash homepage and opening an e-commerce site. If given the position, I would be the sole developer on staff.

I've been working with Rails for a number of years, and haven't looked at PHP in quite some time. However, if I was to get the job, I would be in a position to recommend the framework, as there aren't any development-savvy people already on staff.

I think for many non-programmers PHP still has huge name recognition out there as THE language for building sites, so it acts as logical default for many companies.

If I was offered this job, how could I compare the pros and cons of Rails vs PHP (with an appropriate framework) without getting into technical terminology? A key consideration here is that there are probably a lot more LAMP developers in the area than Rails developers, and I don't want my own personal preferences to impact the long-term sustainability of the code base.

Or should I just accept that a PHP/Zend site is just as good as a Rails site, even if it's less fun to develop?

(Please no religious arguments!)

Answer 1

The first thing I have to say is that (imho) you're approach is wrong because you've started with a conclusion ("I want to do this in Rails") and you're now looking for a justification.

Worse, such an attitude borders on negligence as you have an ethical if not legal duty of care to your client and it's their needs you should be addressing first and foremost, not yours.

This same issue came up in Continue a Classic ASP site or insist a language change?

An important point to make here is that with Rails (typically meaning Ruby on Rails although it could be Groovy, etc) you're comparing a framework to a language (PHP). There are many PHP frameworks so a lot of the issues of speed of coding diminish if not disappear altogether if you compare Ruby on Rails to PHP + some framework or frameworks with which you're equally familiar.

From experience I can tell you that non-technical users will be concerned with some or all of the following:

1. Cost to develop;
2. Cost to host;
3. Look and feel;
4. Site functionality;
5. Ability to find developers;
6. Stability;
7. Existing functionality; and
8. Risk.

(1) is debatable. Ruby on Rails is probably very fast if you're doing things the Ruby way but can get really difficult if requirements force you to go off the reservation. Interestingly, Microsoft stacks tend to work the same way (although they usually have a bigger reservation to further extend that metaphor).

This came up in 7 reasons I switched back to PHP after 2 years on Rails. Agree or disagree, that sort of post makes points you'll at least need to consider and/or address.

(2) I think is a win for PHP. PHP shared hosting is extraordinarily cheap but there's not a lot in it. If the site will get a moderate amount of traffic or there are significant security concerns you'll either end up hosting it at the site or using some form of VPS or dedicated hosting at which point the issue becomes a wash.

(3) isn't really that different. Ruby is slanted twoards Prototype (being integrated) and the like whereas PHP is more open to any Javascript framework (which has advantages and disadvantages) and both can do whatever in HTML and CSS.

Same applies to (4). There's nothing you can do in one that you can't do in the other.

(5) is a clear win for PHP. You may not be hiring hundreds of developers but the fat that if you move on or are replaced that it's easy to find other people with relevant experience is important to non-technical people (and should be important to technical people too).

(6) is either a perceived or real win for PHP. By that I mean Ruby on Rails--at least in my experience--has a reputation for being unstable and/or wasteful of resources. This is exemplified by such postings as Zed Shaw's notorious Rails Is A Ghetto rant. It clearly is a rant but there are some valid points there too.

(7) is an interesting one. Rails mandates (or rather "is") an ORM framework and like many ORM frameworks they can have real issues in dealing with "legacy" data. I put that in inverted commas because ORMs have the nasty habit of declaring anything not done their way as "legacy" (eg composite keys).

If you have complete control over the data model on this site and there's no existing data model to support then this issue is probably a win for Rails but the more constraints you have the more this will be a win for PHP's lightweight (typically raw SQL) approach.

You may want to take a look at Using an ORM or plain SQL?

(8) really sums up all of the above. The company will be greatly concerned with how preditable the end result is and a more predictable, less sexy end result will often win out.

The last thing I'll say is that if you have both Rails and PHP experience (as you seem to) and you need to ask what the (non-technical) merits of Rails are perhaps you need to re-examine what you're doing and why you're doing it.

Answer 2

I wouldn't argue that Rails is better than PHP or anything like that, because to these people they don't really care. What they do care about is:

1. that they get a good site (hence, use Rails because you're better with it), and
2. that it's not going to be a burden to maintain (hence, use PHP because it's easier to find programmers)

Just let them know these facts, and argue your point along these lines to let them decide. Also worth mentioning is that Rails is a growing community (if I believe blogs...) and the availability of developers will get better over time.