The first thing I have to say is that (imho) you are not right because you started with the output ("I want to do this in Rails"), and now you are looking for an excuse.
Worse, this attitude borders on negligence, because you have an ethical, if not legal duty to care for your client, and these are their needs, which you must first and foremost solve, not yours.
The same problem arose in Continue the classic ASP site or insist on changing the language?
The important point here is that with Rails (usually it means Ruby on Rails, although it could be Groovy, etc.), you are comparing the framework with the language (PHP). There are many frameworks, so many coding speed problems are reduced if they do not disappear at all, if you are comparing Ruby on Rails with PHP + some frameworks or frameworks that you are equally familiar with.
From experience, I can tell you that non-technical users will deal with some or all of the following:
- Development cost;
- Host cost;
- Look and feel;
- Site functionality;
- Ability to search for developers;
- Sustainability;
- Existing functions; and
- Risk.
(1) is controversial. Ruby on Rails is probably very fast if you do Ruby things, but can become very difficult if requirements force you to cancel your reservation. Interestingly, Microsoft stacks tend to work the same way (although they usually have more redundancy for the further dissemination of this metaphor).
This appeared in 7 reasons why I switched to PHP after 2 years on Rails . Agree or disagree, such a post makes points that you, at least, will need to consider and / or an address.
(2) I think this is a victory for PHP. PHP hosting is unusually cheap, but not so much. If the site receives a moderate amount of traffic or serious security problems arise, you will either post it on the site or use some form of VPS or dedicated hosting, after which the problem will be erased.
(3) actually no different. Ruby is an oblique two-way prototype (being integrated), etc., while PHP is more open to any Javascript infrastructure (which has advantages and disadvantages), and both can do anything in HTML and CSS.
The same applies to (4). There you cannot do anything in one that you cannot do in another.
(5) - a clear win for PHP. You can’t hire hundreds of developers, but fat, which if you switch or replace, which is easy to find other people with relevant experience is important for non-technical people (and should be important for technical people too).
(6) is either perceived or real gain for PHP. By that I mean Ruby on Rails - at least in my experience - a reputation for resource instability and / or wastefulness. Examples include publications such as Zed Shaw, the famous Rails Is A Ghetto . This is obviously rant, but there are some valid points.
(7) is interesting. Relay mandates (or rather, "have") are the basis of ORM and, like many ORM structures, they can have real problems when working with "outdated" data. I put this in quotation marks because ORM has the unpleasant habit of declaring something that has not been done as a “legacy” (for example, compound keys).
If you have full control over the data model on this site and there is no existing data model to support, then this problem is probably a win for Rails, but the more restrictions you have, the more this will be a gain for PHP lightweight (usually raw SQL).
Can you take a look at Using ORM or plain SQL?
(8) really summarizes all of the above. The company will be very concerned about how predictable the end result is, and a more predictable, less sexual end result often wins.
The last thing I will say is that if you have both Rails and PHP (as you think), and you need to ask what (non-technical) advantages of Rails, maybe you need to reconsider what you do and why you do it are doing.