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.
Related
I consider myself a well trained WordPress template developer, and i recently started to read books and documents about web app frameworks, particularly Django and Ruby on Rails. I didn't know any of the two languages, but i have no problems to learn another one or two. I really don't get the real benefits of using a framework, because i feel very confident about the power of WordPress. So, can anyone tell me the real benefits of using a framework? For example, Pinterest is made using Django, but i think that i can achieve the same results with a WordPress template using Javascript and CSS3. Can anyone tell me the differences/benefits of using a framework in that particular case?
You can achieve the same frontend with Wordpress, but what you will not be able to achieve is the speed and scale - and most importantly, maintainability - of an application based on a more application-oriented architecture.
Wordpress is highly flexible, but it's also slow, and needs an awful lot of TLC to be able to operate at any kind of significant scale. Its design allows for very flexible runtime modification of behavior, but this is also a bit of a Pandora's Box, since it means that code can end up running all over the place for any given page, which makes maintenance a nightmare.
Wordpress is extremely good at being a CMS, but once you start to push it outside of those bounds, you get into trouble, and find yourself having to write your own more abstract framework that runs inside of the context of Wordpress to be able to fulfill your application's needs.
That said, if you have an application that you can build in the context of Wordpress, I'd say go for it! Wordpress can be a wonderful tool for building a proof-of-concept or MVP. If it gets you up and running, then it may be the right choice over writing a full application. However, just be aware that you're going to hit some brick walls as your product design matures and your audience grows, unless your application fits within a rather narrow set of design requirements, so long-term, you may find yourself having to move to a custom application.
Credentials: I've spent the last couple of years maintaining a Wordpress install that served over 25 million monthly uniques, and we had to get very clever to keep it running. We've since replaced it with a Rails application that serves pages somewhere on the order of 10x-30x faster, and is significantly more extensible as an application, allowing us to start exploring application potential that we really couldn't get with Wordpress.
I once made the decision while working in some start-up to choose WordPress for an advanced e-commerce, community-driven marketplace.
It was an awful decision
This is how I was feeling:
At the beginning, it was looking good - you have an amazing community, plugins for everything etc. But sooner than later I hit the wall - at it's root - WordPress is a blogging platform!
Every piece of content technically is a post.
It's really hard to create advanced item relationships
Functionalities are not consistent. Some functions work one way, while others that seems to be very similar work in a different way. Sometimes you need some weird hacks to achieve task that seem to be simple. It makes you read the docs very often to see how a function that you're using for the 1000th time is working. (However, to be honest, I need to say that the WordPress documentation is great!)
The WordPress community is doing a great job, but compared to any regular Framework there is one main difference - Frameworks are just frameworks - they're a set of tools and those tools are there to help you do your project. WordPress already is trying to be something that you might then change.
I'll never again use WordPress for anything that needs some organised, custom functionality.
I'm actually quite impressed with what people has created with wordpress - so if you want to, it is possible and good luck!
It however often feels like buying a truck and rebuilding it to be a house. There are better ways to build a house.
I want to offer a dissenting opinion, even though I upvoted the top answer.
Is Rails really special?
Rails was created by David Hansson who extracted it from Basecamp, software that's replicated in a free Wordpress plugin, WP Project Manager. I think that's a pretty good indicator that Rails developers are underestimating PHP and Wordpress.
MVC and WP
True, it doesn't follow an MVC pattern. But if you use hooks, separate logic (in plugins) from views (in templates), then you'll have good code separation. (Also hint: custom post types are like models.)
Framework vs Application
As you can see, Wordpress can be treated like an application or a framework. It is an application, with all the components you'd expect to find in a framework. Right out of the box you have security, authentication, and extendibility. And it's meant to be extended.
Scaling
WP powers 18% of the internet's websites, including TechCrunch, Smashing Magazine, and (parts of) CNN. Seems there are ways to make WP scale. Disclaimer: I have no experience working on megasites like these, so I'm offering mere conjecture.
WP Future
The current abition of the WP community is to shift WP from a CMS to a framework. I think it's a natural progression considering that all the pieces are in place. And the Wordpress community is going strong.
Not really an answer, but a hint:
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
As if you can replace it completely... I think it is mostly a matter of logic flow. It depends how much imperative (Ruby on Rails) vs. descriptive (WordPress) programming you intend to do.
I don't think wordpress can replace rails, because wordpress have limited set of API and support as you compare it with RoR. Though wordpress is powerful tool for blogging application, but the same effect can be achieved with rails using gems like,
Radiant CMS,
Refinery CMS,
Locomotive.
Adding the power like ttd that can be done vary easily with rails is very difficult with wordpress.
Same with authentication and authorization mechanism like devise and cancan. There is no easy option to do the same with wordpress.
Rails make the programmer's life easier. For whole web app I will always prefer to go with the rails.
Wordpress cannot replace X framework, but the two can certainly complement each other.
For example a WP front end serving up CMS content with an attractive theme is pretty hard to beat; proxy to a back end server for custom content and voila, best of both worlds. Otherwise, WP will inevitably fall short of meeting every requirement and you'll find yourself going down the square-peg-round-hole rabbit hole, a painful place indeed; that's where X framework comes in, filling in the WP gaps.
The notion that WP does not scale may have some truth to it, but for the general case, the 95%, it will handle whatever you throw at it, particularly with WP Cache or other caching plugin thrown into the mix.
Some may say, well, you can build WP with Django or RoR! Heh, heh, you first ;-)
FWIW, I avoid dynamic language frameworks in favor of their statically/strongly typed counterparts. Use WP for the bling, and static X framework for the speed/scalability/safety. Of course, that's a matter of preference, clearly some prefer runtime flexibility over compile time safety. I'm fully in the latter camp these days...
In the simplest term,, I always want to put it like this...
You can use a framework to make WordPress it self and better
But you can't use WordPress to make a framework
Wordpress is a great CMS any way
Pros
1. We can easily set up a website using free themes and plugins
2. There are numerous number of plugins to extend our website functionality
3. Excellent Community support
4. The CMS uses PHP and MySQL, somewhat easy to lean
Cons
1. Updating plugins and themes regularly.
2. Slow
3. Malicious files can be easily injected.
thanks for opening my question :)
I am a university student in Computer Engineering, and I've always done class projects in Java (apart from C, and Assembly, but for very specific things). Apart from that, I have worked for quite a lot of time on a web app done in ActionScript 3, contained in .jsp files and deployed onto a Google App Engine site.
Having that said, I now pretend to do a prototype of another web app, which will have registered users with blogs and a messaging system between them.
My question is, having time as a restraint (I have month and a half), and needing just to build a working prototype, could anyone tell me, in his/her opinion, what would be the best framework for me to start learning and use? (Take into account my Java & ActionScript background) I believe RoR is the most common in these cases, as its easy and quick, but I have no Ruby knowledge at all, and maybe it would be quicker for me to learn Scala (which coming fromJava shouldn't be that different) and Lift, and do it with them instead.
Many thanks in advance!
Pepillo
Last year I found myself in a very similar situation for creating a web based relationship browser for a computing science class. I would highly recommend RoR. Granted you will need to spend some time getting up to speed with Ruby, but it is well worth the small amount of time to learn. There is excellent documentation available and a ton of good tutorials.
Rails can generate much of the core code and database schema with the generator functions in seconds (see scaffolding generators). Considering your time constraint, I think this alone makes rails a good choice.
In terms of learning Ruby, you should not have much trouble with this if you are comfortable with any dynamically typed scripting languages.
Anyway, that has been my experience with rails. Good luck on your project!
I think I'm going with Play! Not only is the easiest for me, as I am a Java guy, but it's also the quickest when in conjuntion with Japid, according to a benchmark I saw.
I used Java for about 7 years now, mostly for web applications, and recently started using RoR. I must say it was really easy to pick up and get started. After only 2 months of working on my own project I started using it for a customer projects and it was far more easier to deliver production code then I had anticipated. So yes I can recommend Ruby and it was not hard at all to pick up.
However, RoR does require a nix platform like apple os or linux. I stated out with windows but there are simply too many drawbacks and bugs.
If you decide to go with ruby I can higly recommend Agile Web Development with Rails (Pragmatic Programmers) to get you started.
I am about to start a new project and I am hung up on which language/framework to use. I've been a PHP programmer professionally, but it wasn't on the scale of this project. I've played around with RoR and i've been very impressed so far. Right now, the two leading candidtates are RoR and Symfony2.
My major hang ups with RoR:
- i don't know ruby, or i hardly do. i can read it ok, but get stuck writing the code.
- i've read complaints about it being slow, and it seems to be slow just at the CLI.
My major hang ups with Symfony2:
- there's practically no documentation for it. Symfony1.x? sure..but not symfony2
- there's also little support. the BB on their site is like 80% spam.
- went to install it on a local dev enviroment haven't been able to even get that running (see my first hang up)
this project will be fairly complex and go beyond the basic CRUD operations. it isn't under a super-tight timeline, but there is one. ~3 months for milestone1 which is basically a calendar, some financial organization stuff (not transactions with financial institutions, just personal finance organization type stuff), and a project manager/cms.
also, i'm open to using other frameworks, but symfony2 seems to be the best right now. if symfony2 had RoR's support/documentation/tutorials/etc it would be a no brainer.
i'm really interested in hearing what the stackoverflowverse has to say on the matter. im constantly impressed with the quality of the answers/replies on this site.
some other sub-questions (that are in my head right now):
- if you recommend a different php framework, why?
- what are you biggest gripes with any of the options mentioned?
i know CakePHP is the closest to RoR, but i've been reading that the models are a bit wonky (Many to many relationships and such).
right now, i'm leaning towards RoR. Simply put, i really want to learn it and it could do the job. i just don't know ruby and i've ready a lot of good about symfony2.
any advice you could offer will be greatly appreciated. thanks!
Personally, I'd recommend that if you're starting a new project which happens to be the largest project you've ever had to do then you should stick with what you know best. This happens to be PHP.
I've used Ruby or Rails. In fact, we have some production apps at our company that use RoR. The best way I learnt RoR was to work on small projects. I would never have considered to choose a programming language which I'm not familiar with and then on top of that learn a new framework to start coding a big project.
As for Symfony2, we started using it a couple of weeks ago. Symfony2 is an excellent framework and looks very promising. It's clean, nicely decoupled and fast. However, we ran into too many bugs/headaches/inconsistencies in Symfony2 to continue using it. We will start working on it again once it has matured and the documentation grows (lots of the docs are now out of date). Hopefully, they'll release some sort of Jobeet tutorial but for Symfony2.
Moving on to CakePHP. CakePHPs code base is old. In fact, it works fine on PHP 4.3.2. It doesn't take advantage of all the goodness that PHP5 has to offer (absract classes, interfaces, private & protected properties, exceptions, magic methods, annotations, pass objects by reference etc.) CakePHPs database abstraction layer, whilst it has had improvements, is not incredibly efficient once your database structures becomes too complex (many joins for example) it crumbles quite badly.
Moving on to Symfony 1.4 which I've used for many large projects
I enjoy using because:
PHP5
Event system
Dependency Injection
Caching system
Forms (nice integration into Doctrine 2) In fact, this is my favourite feature.
Many plugins (sfGuard for user management, for example)
Twig (nice templating language)
Highly configurable
Scalable (although not as fast as Symfony2)
A lot of documentation (Jobeet tutorial is great)
If PHP is for the moment your forte and you need to start working on a large project then start using a PHP based framework as you know the language syntax and functions the best.
Move onto RoR when you have a small project to do.
Just my 2 cents.
Best of luck.
To me Symfony2 has been great so far. Documentation is scarce compared to Symfony1.x but it's much easier to get started in Sf2 and, with things being very explicit, requires less knowledge of how the framework works internally.
There's an app/check.php script that will warn you of any dependency needed to run it, and support mostly happens in their mailing list which is very active (didn't even know there was a BB). Some components, like Twig, also have their own lists.
This is an old topic but things have changed a bit and I would recommend Symfony2. Their current documentation is great (symfony.com) and its much easier to learn for newbies. I did try RoR but with symfony I just got into it much quicker.
I'm amazed of how no one has mentioned the super rich GEM community for Ruby and therefore for Ruby on Rails, there is simply just so much functionality out there, so many people working on some many MIT/open source projects. To me, community is what drives me to go choose one framework over another. The amount of configurations and different template engines, there is just so much out there for ruby on rails.
For a comparison chart check this out:
http://vschart.com/compare/doctrine-php/vs/ruby-on-rails
At the end of the day it all boils down to whatever you know, but do not overlook the community and the functionality that has been written for you already, free of charge...
I'll echo solarc's comments about Symfony 2. I used it for a couple small projects, and am starting something more ambitious with it this week. I would like to see a complete Jobeet-style tutorial, but the main documentation is good enough to get started with IMHO. I'm giving that a thorough read, and have learned a few things that I missed using the documentation as a simple reference.
Finding bundles was my biggest frustration, but the documentation mentions knpbundles.com, and that seems like an excellent resource.
I'm about to start building a tumblr clone that handles multiple users (so premade clones like Gelato won't cut it) and I'm not sure which framework I'd like to build this is.
Right now, I'm only intending to build a prototype. Something I can get a dozen friends on to test the concept and grow to maybe a couple hundred users to prove the market, so I'm not worried about long term scale. My biggest concern right now is quick deployment. I'd like to get from zero to signups in as short a time as possible, with as little customization to the framework of choice as possible.
I have experience with PHP, but not Ruby. However, I don't think the learning curve would be too steep so I'm not ruling out rails. I just want the framework that is most appropriate for a system like a multi-user tumblr clone so that I can build it with as little hassle, and as quickly, as possible.
If anyone has experience with a similar project, or with these frameworks and can offer an insightful perspective, I'd be very appreciative.
Thanks for taking the time to read.
Cheers,
~Jordan Feldstein
Definitely Rails. It'd much faster to develop project like this in Rails.
As far as I saw, PHP is lightyears behind from Rails in ORMs. And Rails routing is much better than any PHP framework's as well.
I have been developing in PHP since 2000, and still have a bunch of PHP systems in production (using both CodeIgniter and CakePHP).
I have found Rails to be incredibly more efficient to develop in ... easily 50% more productivity, depending on the use-case. Faster, higher quality. Easy choice for me.
+1 for Rails.
I can't speak about Codeigniter. My general understanding echoes the above statements. Lightweight and no fully object oriented.
I have developed in CakePHP since Jan 2006, after trying to get Rails deployed on my own server and failing badly. Rails was not easy to deploy back then...at least not for me. At the time Cake was the best alternative, and still is in many ways.
Cake is a very competent framework. However, I agree with the statements that it is in many ways far "behind" Rails. Some features are not as well designed, less integrated or simplified in comparison.
A few months ago I spent a couple of day porting one of my Cake apps to Rails2. Just as an exercise. The learning curve was very shallow for someone like me (with a decent grasp of the concepts that Cake and Rails are built on). We recently started porting one of our apps at work to Rails (also from Cake) because we found that support for a lot of things that are important to us are available in Rails or Ruby but not available or as complete in Cake and PHP.
If you are unsure about switching to Ruby you might want to look at Lithium (previously CakePHP v3). It is PHP 5.3 only and still a good way from 1.0 but the community is active and generally it looks like what Cake might have been if it had been started today and not 2005.
CodeIgniter is very lightweight, which is probably to the detriment of this project if you want to code as little as possible.
CakePHP is pretty much an attempt to port Rails to PHP, so choosing between those two frameworks will depend on other factors.
One factor would be whether you want to learn Ruby or not. I have dabbled in it, and feel it is superior to PHP, but more practical concerns keep me from experimenting with it more (have to use PHP at work).
Another concern would be hosting. I use Dreamhost, and the fee is the same for PHP and Rails. However, a friend of mine just got a GoDaddy hosting account, and he actually has to pay a higher monthly fee to have a Passenger-enabled host.
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)