Andrew Shebanow has a good post about this tradeoff in relation to Twitter, which is powered by Ruby on Rails. Alex Payne, of Twitter, has talked about their experience with the massive scalability explosion that the site has seen and some of the "friction" that they've encountered trying to refactor the abstractions out.
I worry about this in the context of most every framework I use - and there's certainly been plenty of noise on mailing lists and blogs over the years about the performance of frameworks. One of the reasons I've settled on Fusebox for the Scazu website is that it compiles all the circuit files down to inline CFML on the first request so the abstraction is compiled out (this is one of the core messages in my "Extending the language of Fusebox" presentation - see slides and sample code under 'SOFTWARE' on my blog).
I've also been a fan of Transfer for ORM, lately because of the TQL - Transfer Query Language - component that lets me write complex database queries using an object / property abstraction. It looks much like SQL but lets you use the terminology of your application instead of the terminology of the database. It does add overhead but refactoring methods that use TQL into methods that use the underlying raw SQL is pretty straightforward and can be done on a method by method basis (and, in fact, I recently refactored one performance-critical method in exactly this way).
Going back to Andrew's post (and the underlying comments from Alex), I'd say that Transfer has a low friction coefficient that contributes to why I like it so much.
While CF is my platform choice, I find Rails very interesting because I think it represents a shift in acceptance for full-scale abstraction of a programming language in web development.
Not that the capability is new, mind you, but now the "cool factor" that ROR has right now gives some added momentum. IMHO, this only benefits a compiled and loosely typed language like Coldfusion, which is very easily abstracted.
To your points above, I think one of the strengths that I've seen in most of the CF Frameworks I've used is the ability to remove or "peel back" those layers of abstraction when bottlenecks are exposed or workarounds are required to meet the needs of the application.
That shows a good deal of forethought on the part of the developers of those frameworks and, I think, speaks well of the Coldfusion community at large.
Sean you really think anything you're creating couldn't be done in Rails, but could in CF, scalability-wise?
@Jon, not *all* of the frameworks but, yes, definitely some of them.
@railsguy, it seems you've fallen foul of exactly the sort of defensiveness that Andrew mentions in his blog posting...
http://www.pbell.com/index.cfm/2007/4/19/Friction-and-Frameworks
What I mean is that you're comparing the wrong things. Rails is the *framework* and Ruby is the language. CF is a language.
You can totally go your own path in *Ruby* -- Camping is an excellent example. It's a *micro*framework that uses the killer part of Rails (ActiveRecord) and about 4k of VC custom code. Wesabe is an example of a site that used Camping instead of Rails. They picked what they wanted from Rails (ActiveRecord) and picked what they wanted for the VC components from another framework -- just like you can use Fusebox and Transfer, or MG and Reactor.
One enormous difference between CF frameworks and the hot new web frameworks in other languages (Python, Ruby, PHP, Java) is that none of the CF-based frameworks have an *integrated* model layer. The major CF frameworks are all focused on controller and view while the ORMs (Transfer, Reactor) are independent. Not saying it's good or bad, just different.
As the Camping framework shows, you can get some benefit from cherrypicking what you need from another framework (Rails::ActiveRecord) and peeling back the VC layer and rolling your own.
Heck, I use ActiveRecord all the time purely for database scripts b/c it's so much easier than pure DB development work in Ruby.
There still, IMHO, a huge vacuum in the ColdFusion world for a framework (or several) that integrate a CV tool with an ORM, add in a supported AJAX library, and then write some scaffolding code. The pieces are all there -- right now everyone just rolls their own from those pieces which _can_ improve performance and maintainability (see Brian Kotek's blog about replacing the model using IoC) at the expense of standardization and speed of development -- both areas where Rails excels.
Actually, I either didn't make things clear or you didn't understand what I meant, because I was saying the same thing. The confusion might have been that I said "CF is a web development language before being a framework" when I really meant "instead of a framework". And yes, I know you can do whatever you want in Ruby, I was just saying that the moment you start doing a lot of stuff in Ruby outside of the Rails scope, there's a line you'll cross where you'll be developing in Ruby and not in RoR.
Question as Hamlet phrased it. "Whether 'tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing, end them."
So would you use rails to build an amazingly successful website like Twitter (agile, fun to build, maintainable code and ajax ready, ORM...) or to use a language that will scale easily but may not produce the outrageous success of Twitter.
Could Twitter have used any other language (YES of course) but would they have been able to build it in the time and been agile to the constant changes that "may" have ultimately lead them to the current explosion of traffic they have today?
MySpace was built originally with ColdFusion. IMified is built with ColdFusion. People have been rapidly building wildly successful sites with ColdFusion for over a decade...
Of course they *did* choose to scale their *platform* using Solaris 10 and containers (Joyent is their host) and thus they chose a partner with deep expertise in the hardware/application stack scaling. So their overall choice was fast, lightweight development (RoR) and a deployment platform that can scale both horizontally and vertically.
Seems like the broader point is still relevant about the friction in your framework, but there's also a hidden friction in the *deployment* as well that's rarely looked at by software developers. No matter how frictionless your framework is, you still can run into friction with scaling outside of all of that thanks to network, hardware, and OS concerns.
I mean if we *really* wanted a performant site, it would be written in Python, right? :) :) :)
If only we all had the problems of success -> scaling that a Twitter had.
The real moral is "Don't show your cool stuff at SxSW until you've figured out a way to scale it". And monetize it. ;)
As for cost, yes, if you are offering a completely free service without even advertising revenue, you may be cost-sensitive for your infrastructure. I don't know how many users IMified has so I don't know how they've handled scalability but they are using ColdFusion Enterprise for IM/SMS integration.
Just an interesting followup since the whole Rails/Twitter thing has been getting so much play in the wider Rails world -- there's a great post at Joyeur (the Joyent site) about how they sat down w/ the Twitter guys using DTrace (one of the key debugging pieces of magic in OpenSolaris, and now ported into MacOSX Leopard as XRay for all of the Railistas and the rest of us) and found some of the primary performance problems specifically for Twitter, submitted patches, and now Edge Rails has the fixes.
The article is a great example of how to *handle* a scaling issue -- identify the core problem, isolate it, fix it. Turns out that this improves Rails as a whole. If you follow the list to the changesets, it's pretty interesting how some minor code choices lead to scaling problems but only under specific situations and usage patterns. That's pretty cool!
Me, I'm even more jazzed about my move to OSX with DTrace coming in Leopard. Not that we can get patches into CF as easily, but it should help folks identify problems in CF *frameworks* that extend beyond what FusionDebug/SeeFusion can produce.
http://joyeur.com/2007/04/24/solaris-dtrace-and-rails
