I am working on a project for a client of the IT company I work for and I am convinced that Rails is perfect for it. I have a meeting in the next day or so, where I am afraid I am going to get bombarded with "why Rails?" type questions, and no doubt, a whole bunch of rhetoric like "Rails doesn't scale", "Rails is just a CMS" and the thousand other myths people seem to have about Ruby on Rails.
We have all seem the arguments about how Rails doesn’t scale, it’s hard to deploy or that it will explode in your hands at any given moment. For those of us that use Rails on a daily basis, we know that just like any other language or framework. It seems like there is a lot of misinformation about RoR and often Rails gets a bad wrap. To help me with this meeting, I was hoping to compile a list of myths - perhaps one myth per answer - and we can vote for the myths we've heard before - to eliminate the Fear, Uncertainty and Doubt that often clouds the truth about Rails.
After some googling I found this blog post which is exactly the kind of thing I'd like to collate here. As David Heinemeier Hansson says in the post:
So I thought it would be about time to
set the record straight on a number of
unfounded fears, uncertainties, and
doubts. I'll be going through these
myths one at the time and showing you
exactly why they're just not true.
This is not really to convince you
that you should be using Rails. Only
you can make that choice. But to give
you the facts so you can make your own
informed decision. One that isn't
founded in the many myths floating
around.
Let's Clarify!
Myth: "Ruby on Rails doesn't scale"
Bust: That is not a specific, answerable question. Please clarify.
Saying that whatever-technology "doesn't scale" sounds very professional and very enterprisey - but it's not a clear question. It's just a lazy way of dismissing the unknown/unproven I'd ask for clarification:
"What precisely do you mean by 'scale'? and how do you measure it at the moment?"
It could mean:
Maximum user sessions
Average response time given load
Throughput of given concurrent scenarios per server in a fixed time.
... difficulties organising the project so a large team of developers could work on it.
There are lots of ways of dealing with "scale" but until you know which one you're dealing with it's not always obvious what to do about it.
There are loads of ruby-based solutions, including
caching fragments of HTML
sharding the application across multiple databases
pre-computing work that's shared between users
pushing lots of view-rendering work off into AJAX/Javascript land so it happens on the client
using a front-end web server more efficiently
just use more hardware (i.e. developer time is expensive & hardware prices fall) but this approach depends on a shallow rate of growth in demand
doing less interactively and having more batch work
doing only part of the work in ruby - e.g. existing legacy backend+rails frontend, or maybe the transactions through a functional programming system+rails frontend
If the challenger can't come up with a specific meaning of "scale" then it isn't a valid concern.
However if the challenger does come up with something specific and measurable, then I'd use a timeboxed, spike solution ( http://c2.com/xp/SpikeSolution.html ) to come back with some numbers - and possibly a few options on how to do it.
Make the argument from the only perspective the client understands, money!
Show how long you think it will take to make in Java, JSP, or whichever is their current technology, together with the pros and cons, such as easier to obtain developers. Then, state the timescales in Ruby, which for sure will be lower development costs, but also at a cost of the admins having to deploy a different system, possibly harder to recruit staff who know Rails, etc. Its their money, so give them the facts and let them make the decision.
In response to the specific criticisms a company could have against Ruby on Rails compared to their own systems there are many reasons a company can give, some of them not specific to Ruby or Rails, such as they already have many Java develops in house, or existing infrastructure written in Java, which will always be easier to use with a same language system such as Java. Anyway, to answer your specific points:
1) Why Rails?
Simple, Rails is "designed " for building web sites, and does an efficient job. Find some statistics to back you up (I'm not saying the statistics in the link are accurate but numbers will always impress a client)
http://www.theserverside.com/news/thread.tss?thread_id=33120
2) Rails doesn't scale
http://trak3r.blogspot.com/2008/03/rails-doesnt-scale.html
3) Rails is just a CMS?
If they are building a CMS then recommend Drupal, not Rails
I guess you will have to think on your feet when you answer your clients questions, and they will want someone who understand other frameworks apart from just Rails, kind of like using the right tool for the right job
Myth: Rails is not mature enough to have the plethora of hardened open source libraries built around it that one needs to pull off a large scale project quickly and reliably.
Bust: In fact, there are a ton of gems and plugins available to the RoR community, many of which have been tried and found true by the active community. Not only are the resources there, but they are simple to manage with 'gem' and Rails' built-in plugin architecture. Worst case scenario: you can't find that perfect gem or plugin. In that case you can easily write your own or borrow from the Java world if you use JRuby.
Myth: it is hard to hire a good Ruby on Rails programmer.
(Actually, I can't bust it, that's just an idea of a potential myth. Who can, please, edit this one or create another answer)
Related
I have some (I think) really great ideas for an online strategy game similar to Travian. There's some content that I haven't yet figured out and some other challenges that I don't know of yet.
This is quite a big project and perhaps too heavy for one person that isn't a skilled web developer (yet). I'd still like to give it a shot, but I'm having trouble choosing a platform. The world "scales" has been thrown around a lot lately and I've seen Ruby on Rails being bashed because it doesn't scale well, so I've come here to get some answers.
I like Ruby on Rails, both Ruby and Rails. I'm certainly no expert at it but I love working with it. I have also worked with Python + Django before and also with PHP (which I am not fond of.)
Ideally the game would have, let's say, 7000 players per server, presumably a lot of data to be processed per second. Would RoR still be a viable platform?
I'm sorry if this question is vague, I guess I'm looking for a "RoR is fine, go at it!" kind of answer. Anything you might want to add is fine.
Thanks!
So if I were you, I would be looking into non-blocking servers like node.js, just because they are MUCH more suited to keeping many connections open for long periods of time, which is what games need to do, compared to traditional web servers.
That being said
There are 3 main things to worry about when you are scaling a web app; memory, execution speed, and io (hd and network) in that order.
For memory, things are much better then they used to be. Phusion Passenger uses copy on write to fork its workers, so the rails environment will get shared among all the workers on a given slice, which is pretty significant. There have also been huge improvements to the way ruby manages memory compared to "the dark times", if you are using 1.8.7 then you want to be using the patches that make up Ruby Enterprise Edition (the difference is like night and day). 1.9.x was pretty much a total rewrite of the runtime, so if you are using that the memory issues ruby had have already been addressed.
For execution speed, 1.8.7 is typically "fast enough" (at least after tuning garbage collection settings). 1.9.2 is actually around the same speed as python, which puts it on the faster side of interpreted languages. How important this point is completely depends on the nature of your application.
Last point is IO, which isn't really a concern of rails, but more your persistence strategy. Rubyists tend to love new things, so you will find first class support for things like redis and mongodb, with loads of people talking about using them and their wins/gotchas. I would look into mongo if I were you and see if the durability trade-offs are acceptable.
I was in java/.net before going to rails, and at the end of the day you are going to pay more for infrastructure, but the amount will be completely dwarfed by what you save in development time.
build it in Rails, host it on Heroku.com - job done. Almost infinite scaling that you don't have to worry about how it works (it just does) and it hosts a lot of highly trafficked Facebook apps so can more than handle it.
I think Ruby on Rails is a good choice for what you need. Actually, we recently created a platform for an online gaming tournament, where players and their gaming bots were playing a logic game.
We used Ruby on Rails and Sidekiq on the backend, ReactJS and WebSocket on the frontend. And it worked well for a quite massive number of players. Here is the tutorial based on what we learnt while building it: How to Write a Game Engine Using Ruby on Rails
As you said yourself, you already have the answer and you are only looking for encouraging words:). I am not RoR expert myself, but I don't think scalability is still such a great issue on this platform. I would advice you to do an architecture spike (XP terminology). Write a test with 7000 clients and method which would perform similar operations to what you intend to create. For example you might load files, render views or even just wait... The point is to test only the thing you are worried about. Good luck!
This is a bit of an impossible question to answer because in order to know whether rails is suitable for what you want to do we would need to a lot more about what you are trying to do. The best advice I can give in the absence of information is for you to check out the railslab scaling videos in order to work it out for yourself.
I want to make a community based site, which is Drupal's strength. However I also want to try other frameworks, especially Rails.
One of the best things about drupal is its huge modules library. If I were to switch to Rails, would I be able to find similar functionality freely available as plugins, or would I have to rebuild?
Does Rails have the equivalent of (as plugins or gems):
CCK/Fields?
Node Reference?
Views / Views Relationships?
PathAuto?
Threaded Commenting?
Multisite Functionality?
Apache Solr (or equivalent) Integration?
Thanks.
I'm afraid you'll probably hear this answer a lot, but it's not a suitable comparison.
Drupal is a ultimately a CMS, Rails is a framework. Apples to oranges, or perhaps even Apple Juice to oranges. Out of the box, you fire up Drupal and it does 'things': it has a database structure, the concept of nodes, interfaces blah, blah. If you fire up Rails you have an empty project.
As far as I know there isn't a "Drupal-on-Rails" project that would be a suitable equivalent. However, I can attest to the fact that there is an awful lot of Ruby/Rails community and O/S work out there and you might find something suitable. I'd also say that the level of modularity in Ruby and Rails tends to mean that the range of plugins/modules/gems one can use is much greater.
My personal $0.02. If Drupal does what you need, just use Drupal: it's mature and has a great community. It's never a good idea to try to port Project X over to a new language as a learning exercise because you'll inevitable fall into the "Well that's how it's done in language X!" trap and become disenchanted with the new system.
If you're wanting to learn Rails (which you should, it's awesome) I'd suggest you'd be best working on a small project and seeing what the ecosystem offers before deciding if it's suitable for the needs of your bigger projects.
I have to second what Govan said, but add to it.
With Drupal, unless you really want to get into building your own modules and extensions you are really interacting with an application. Even when you start using CCK, all you are really doing is flipping switches, filling in forms and defining new options for content on the site.
Ruby on Rails is two things, and neither of them bares much similarity to Drupal. You asked "How hard is it really?". To answer that you need to understand what both Ruby and Rails are. Ruby is a programming language designed to make the life of the object purist programmer simpler and more pleasant. So, the first part of how hard is it is simply to answer "how long do you feel it would take you to learn a completely new programming language, like PHP but different".
Rails is an 'opinionated' framework. It's opinionated in that it lays out how a Ruby web project should be structured, as well as providing multiple APIs for everything from database access to web presentation. To answer the "how hard is it" question for Rails then (assuming you know Ruby by this point), you have to answer how much do you need to learn about cacheing, database design, page design, RESTful programming etc etc.
It's not a short journey. you asked if there is an equivalent to CCK for Ruby and Rails which implies to me that at this point your knowledge of programming is somewhat limited. Ruby and Rails interact with the database. CCK lets you define things in a database. Thus, with Ruby and Rails you are effectively bypassing the wonderful dialogs and forms that CCK provides you with and doing the data definition bits yourself, by hand, in code.
From experience, when I've hired experts in another programming language and framework into my Rails teams, it has taken them between 1 and 3 months to get productive, and a further 3 to 6 months for their productivity to start to raise and approach that of the Rails experts on my team.
Thus, in your particular case, I would not recommend a switch away from Drupal to Ruby on Rails.
Drupal (core) on ohloh (130k lines of code) is estimated to be 34 years of work worth.
Drupal (contributions) on ohloh (modules for Drupal 4-6 (7M lines of code)) is estimated to be 2113 years of work.
That is the power of a community, and that is something that you can never replicate. I remeber there was a guy, who tried to port Drupal to python calling it drupy, but that project died before something useful ever came out of it. Even if you copy the code, you can never copy the community.
The thing you need to realize, is that each community is different. So even if you find a project that can solve your code needs in a RoR or a different language/framework, it will never be like Drupal and vice versa.
So don't try to find a replacement for Drupal, but go explore and try new things. You might end up learning new things, that you can use for your Drupal projects.
I've read this times and times again that people saying comparing drupal an ror is comparing apple to orange which is wrong.
I think the saying itself BS. Yes we want to compare apple to orange and find out which is better. We even want to compare apple to steak. Said that, they are different. Yes, we all know. I have limited experience with either. I first thought Drupal was great and can help me build the website I wanted overnight (or over a week or month) then it didn't happen (not blaming Drupal).
My impression is that, Drupal maybe still great but it has a learning curve and needs a lot of other knowledge or talents to use it well and tweak it. RoR on the other hand is a more general framework and needs programming (Drupal needs too actually).
If you are more of a web designer person with a little PHP maybe Drupal is better fit.
If you are more of a web developer type don't want to spend time looking for modules and make them work but rather do them yourself (not really from ground up) then maybe RoR is for you (with the same amount of learning). So yes they are both good for different purpose, background, etc.
For now I will go with RoR (or dJango and other ORANGEs). My 2 cents.
Rails, since version 3.0, has officially adopted the once-controversial engine way of incorporating third-party apps. this is roughly the equivalent of Drupal's modules/plug-ins, from a 10k foot perspective. To build a community-based site, you could make use of an engine called, appropriately enough, "Community Engine." http://communityengine.org/features.html"
The Rails ecosystem doesn't have anywhere near the same number of modules Drupalists have available to them, but there are enough good quality ones to cover the chief basics.
Drupal has so many strong areas, its hard for just one or two people to recreate it in a decent amount of time with any language. PHP, Ruby, Python, etc.
You have the core node system, taxonomy, aliasing, menus, users, permissions, and modules, the database api, and form api, among others.
You'd have to know how to assemble all these pieces independently and create the structure necessary for it to all work together.
It would take more than 'a few hours'. I would say, even if you are a ROR master, you're looking at a year to two years of solid consistent work to get the best parts of Drupal for a new system.
What is your favorite Rails admin tool and why? By admin tool, I'm referring to those that let some users add records for all the tables, like the tool shipped with Django.
This question is subjective and I believe the matter is subjective, but I think it would still be nice to be able to read other people opinions and gather data on the strength of each tool. Feel free to also comment on why you are not using a particular tool.
Looking around I've seen these ones:
Streamlined
Typus
admin_data
active_scaffold
full list
I think it would be excellent if there was one answer for and one answer against each tool and we just add information to each of them, in a very encyclopedic way, but I'm not sure if that's doable. Of course, this question is a community wiki.
In my experience Streamlined, Active Scaffold etc. often ends up limiting you and slowing you down in the long run, although it can be very efficient in the short run.
By combining the Inherited Resources and Formtastic plugins you can produce controllers and forms for your models just as fast as with a full-stack admin tool plugin, and it will leave you with greater flexibility and extensibility.
The tradeoff, however, is that neither of these plugins will give you the fancy lists that the admin tools give you. So as you say, it is indeed a matter of taste.
I've been using admin data in my last few projects and find it far superior to ActiveScaffold. When I used AS, it was always trying to do too much and that led to some problems. Admin data is completely non-intrusive. When it can't handle something in your data, it just displays a message instead of breaking your app.
I've been using ActiveScaffold for awhile. I feel that I have pushed its limits fairly far and it reacts pretty well (i.e. it's pretty robust). I customize it considerably so that non-technical users can jump in and manage their own websites with it. Those who take the initiative to work with it seem to like it. I do find the default interface confusing at times but you could change that completely if you wanted. AS is very customizable. On the downside, I've definitely grappled with my fair share of AS bugs, but the project does improve and I'm satisfied with its results. I have never even heard of the other admin systems you posted, but Typus and admin_data look nice. My biggest concern would be how easy I can customize them for use by non-techs.
I myself have used active_scaffold quite a bit and like it for certain tasks but I believe its niche is for power users not for mortals per se.
Streamlined was an interesting option but is officially unmaintained now which sucks. It really was a beautiful product but it never really seemed to get a lot of attention from the community so maybe they gave up on maintaining it publicly.
I've also not used Typus and admin_data but I ran into some references to Typus last night so clearly some very smart people are looking at it very hard.
On a last note, I think this blog post really summarizes an opinion I've come to recently after working with a Drupal firm for a bit. I believe that the reason admin interfaces haven't received the same amount of love is that Rails is built primarily for applications rather than content, which means that the people looking at backends are typically not mortals or can stand to look at an ugly backend.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a boss who is convinced learning Rails is too steep a learning curve and not cost effective from a labor standpoint when straight Ruby running as a CGI app on Apache is available. He is proposing, for our rewrite, that we use straight Ruby w/ no framework rather than Rails (or Merb, Sinatra, etc.) I believe in my heart that this is a bad idea but I'm having trouble putting my case into words. Some ideas I've come up with so far:
Rails promotes better code reuse and better separation of concerns via MVC
A shop running rails will look more attractive to the qualified job seeker, since Rails looks better on his/her resume, is more fun to work with, etc.
(I may be wrong on this one) Rails will have better performance on Passenger because Passenger automatically pools connections to the database where as a handrolled CGI app would have to manage that itself or not at all resulting in worse performance.
Rails is a proven technology, at least certainly more than a handrolled CGI framework
Are there any reasons I'm missing or wrong about? Are there valid tradeoffs I'm not aware of?
There are occasionally good reasons for a company to roll their own framework instead of using a standard Rack-compliant framework. But "Rails has too steep a learning curve" is not one of them.
Doing it brute-force is actually more complex, rather than less. If your boss is really worried about learning curve, he should use the standard framework that has documentation and articles and screencasts and entire hosting companies dedicated to it.
Besides, Rails is dead easy to develop for. I've taught one-day workshops on Rails, and even people who have never programmed before have a working, deployed app by the end of the day. Experienced developers have an even easier time of it.
If your boss doesn't understand Rails, and rather than figure it out, he's giving you this line about Ruby over CGI...be careful. Technology left him behind 15 years ago, and he's no longer qualified to make technical decisions.
He should be moved into marketing without delay.
Does your boss have any reasons for his conviction? Other than "a feeling"? What are his real concerns - you won't have much success in changing his mind until you have worked out what his underlying concerns are. Don't be surprised if they turn out to be substantially different to what he's currently saying. He may have an irrational fear of Danes, for example.
Do you have any concrete reasons for disagreeing?
As a boss, I wouldn't be too swayed by the reasons you list so far: good design/coding practices don't need a framework, recruitment isn't your concern, performance optimisation? Don't do it? How more proven than CGI? (He might say, not me: I drink the Rails Kool-aid every day).
Is he technical in a current sense? I mean, will he be involved in coding the rewrite? If so, might he be open to a challenge? Pick a subset of features, buildable in a day or two and try it both ways. If he's not technical, why does he think your opinion is less valid than his?
If he's concerned from a cost/effort perspective, why does he believe that writing less code (and getting thousands of lines of useful, tested framework code for free) is more costly and/or more effortful than otherwise?
Someone else has already mentioned "managing up" - I suggest Googling for resources on ways to work on this.
Are there other members of a team involved? How do they feel?
Martin Fowler famously (in the Agile world at least) said something like "if your organization is not doing what you think it should, you should change your organization". There are at least two ways to read that...
I think a potentially great idea would be to use parts of RoR(Cough ActiveRecord) and roll your own stuff if it simplifies things... I'm not a framework kinda guy, I prefer libraries and a certain degree of code abstraction, which is why I could never be mistaken for a RoR fanboy... but I think getting him to use certain parts of rails, might turn into using all of rails.
Only other point I would like to make is that MVC isn't rails only and if you rolled your own then you could very easily follow that design pattern... besides rolling your own can have benefits... for one thing, you'll know exactly what everything does and how it works, self rolled would mean a leaner system, that you can modify more easily...
My final answer is meet in the middle... Ruby is EXTREMELY powerful in the hands of creative programmers... in fact, I'm in the process of re-rolling my 2 months of rapid "throw-together" php/jquery prototype into a erb/jquery site...
--Thinking out loud--
Not trying to crap on Ruby on Rails... but Rails are what trains go on... and trains do go fast... but they only go where the tracks take you. I'm more in favor of a "Ruby off Road" environment. Less speed, More control.
Using Ruby on Rails versus just Ruby is the difference between buying an automobile and welding a unicycle out of a single tire: both will get you where you are going.
At heart though, I think this is less a technological issue and more an issue of "managing up" as the decision NOT to use Rails is so laughably bad at this point as to be nonsensical.
I think you have two options:
Sort out a way to make it seem as if using Rails was your bosses idea all along. You might say something like: "Boss, I've heard what you've said and so instead of using full blown Rails, I'm just going to use it as a basic framework and do most of the work in straight Ruby."
Take the initiative to do a prototype of the development over a weekend, give your boss something provable that says: "This is clearly the way to go".
Good luck.
It's not a very steep learning curve. You might want to ask him to walk through a tutorial before making a decision.
Also, a big advantage is that RoR is a pretty popular system right now. Installing plugins is trivial, there are many deployment options already figured out--basically a lot of the work that isn't directly "Programming" will probably be easier.
And active record--it's so useful that it's difficult to imagine doing a web/database app without it any more.
Tomorrow, I will meet a client that is not working in technology but might ask if RubyOnRails is the right choice for his site. He might think that there's not enough RoR programmers and that he will be "hostage" of the language.
I have good reasons to use RoR and the client has good reasons to like it (it costs less!).
Do you have "official" sources I could show them?
Using a framework ensures that the "next guy" can pick it up quickly
Rails has reduced my workload by 80% over hand-coding.
Huge, active, friendly community to draw upon
Self documenting testing frameworks
It uses Ruby, which is super easy to learn in a pinch
Open source language, framework, and database that uses an open source OS. FREE sells.
This is, in some sense, a variant on the "bus hit factor" problem. Any app, once developed, is pretty much "hostage" to the language, the question is whether it is also "hostage" to the single developer who wrote the app. I think that RoR is a perfectly reasonable choice for development, but the issue is really how many developers in your local area are available to take this over if you happen to "get hit by a bus." If the customer is willing to work with someone remotely, this becomes much less of a problem. To reassure him, though, I'd first look to the local scene and find out about local Ruby developer groups. The presence of active, local developer groups is one measure that might convince him.
If, on the other hand, he's concerned that RoR will not continue to be viable in the future that is a slightly different issue. Again, I think you're ok -- you may want to point out other applications that are written using RoR as an indication of continuing pressure to improve both the language (Ruby) and the framework (Rails). You can find a lot of this information at http://rubyonrails.org/.
"might ask if RubyOnRails is the right choice for his site. He might think that there's not enough RoR programmers and that he will be "hostage" of the language."
Have you considered the possibility that these are valid concerns that should be taken seriously?
"I have good reasons to use RoR"
How does that help your client, though?
"it costs less!"
Does it? Do you have any specific evidence to support that assertion? Have you factored in hosting costs? Rails on MRI uses a lot of RAM. You're probably in Java territory or worse. Depends on the app and the load of course. Phusion Passenger (mod_rails) has improved the situation somewhat, but it's still an issue.
As mentioned by others documentation is a "HUGE" issue. Ruby and Rails official docs are sparse, to put it kindly. The community tends to rely on paper books which become outdated and misleading in a matter of weeks, thousands upon thousands of unreliable, contradictory blog posts, and screencasts which also suffer severely from the "quickly-outdated" problem. Don't think PeepCode is going to save you.
I would still consider advising a client to use Rails because the claims of programmer efficiency are more or less true, sort of, but I'd do so with extreme caution and I'd let him know the downsides.
Documentation is HUGE when it comes to open-source projects.
One thing you could do would be to explain to your client that it will cost them much more to have you and your developers spend hours and days searching for documentation on some other open-source framework that is less used and supported. Explain that there may not be as much ROR developers out there as there are PHP developers per say, but the fact that there's such a great amount of documentation and information about ruby and rails makes it exponentially easier to for any open-source developer to learn and use the framework.
There would be some things I would try to convince the client-
Ruby Community is huge
Ruby is mature enough
Ruby works with most database systems.
Rails is a product based on an Idea(MVC) most other platforms have embraced.
Improved readability and testability of code.
COSTS LESS!!
Migration methodology in RubyOnRails
If you want you can even target the Java Platform using JRuby and Java Platform is a pretty respectable platform.
Show some cool RoR applications.
Explain how you could be Agile!
I know so well clients not agreeing when you dont have a big company backing a technology.
The "cost less" feature of RoR is debatable, I agree with you. But in my case, I have a complete RoR-ready environment and I know that I can charge less for a RoR app than any PHP app that I could do.
The hardware/software environment for PHP and Rails are almost the same... so is the price of it. What will cost less for the client is the robust environment that we built.
That's the "cost less" feature. I'm not talking about about memory comsuption or anything else. It all can be bought for almost nothing.
This depends a lot on location. If RoR developers are plentiful and work for prices comparable to other programmers then you can use that to help sell Ruby.
For a client one of the main concerns is cost. Perhaps he is concerned about maintenance costs of finding and paying for a RoR developer, not the cost of the technology.
I know a web shop who was bitten by the relative 'newness' of RoR. They hired a developer to make a site and that developer use RoR. After the project the developer left. In our area RoR developers are not only scarce, they charge more than any other type of web developer. In this particular case the web shop ended up losing their client. The last I checked their client's web site is in PHP.
I'm not trying to say RoR is bad and I think that's an extreme case, but make sure to consider the client's concerns. The cost of maintenance is a very valid concern.