There's been a lot of discussion out there about how rails is great for small / quick CRUD projects, but not for larger projects. I've been working as the primary developer of Odeo since mid december. I've had a few people contribute parts of the code here and there, but it's mostly been my baby.
I figured i'd explain a little more about the development and where we are at. Right now we've got at web application which provides a folksonomy style directory, publishing tools, web services, feed parsing, and integration in to back end media processing. My hope is that odeo can become the flickr of audio.
Currently we're running a pretty standard LAMP style setup but with Ruby on Rails and fastcgi. We've looked in to lighttpd and plan to experiment with it at some point in the future. We've got 3kloc of code and 2.2kloc of tests. The are 37 tables in the database, 21 model objects, and 72 AR relationships defined. We average 6 lines of code per method. Most of the development has been done using agile techniques.
So the question comes up. Does rails bog down in big projects? Does the speed improvement / benefit continue when projects grow? The answer is both yes and no. No because the core odeo rails app is done. I've had to focus my time on the rest of the development. In our case that is media processing, feed parsing, bot's, deployment servers, etc... That stuff isn't any faster because we're using rails. We're using a combination of ruby and python for non-web scripting. Ruby's a good language, but we're getting about the same functionality / hour of coding as we would with perl or python.
On the other hand the answer is also yes, the productive gains do scale. When I do get back to doing the rails development it goes fast. To fast. It's like, add this feature, ok, done. Then it's back to making the html tweaks, javascript to get ajax working, and other tasks. It makes it feel like I'm not doing much with rails, because when i need to make a change it's fast.
Another thing which i think is important when looking at web app frameworks is learning curve. I've had 4 other people pick up and contribute to the code base. Three of those people working remotely. They've all picked up and be able to understand the system quickly. The learning curve was very short and the code was generally readable. This contrasts to my experience with zope, perl frameworks, and java. All three of those technologies had steep learning curves which required lots of face to face collaboration to bring people up to speed. With the exception of Florian, nobody had previous experience with rails or ruby beyond building a weekend example app and reading the tutorials.
That says a lot to me. Experienced web developers can pick up ruby language quickly. The defaults and standards which are laid out in the framework encourage the best practices of agile web development. Instead of making the concepts of test driven development difficult, as was my feelings using zope or maypole, it is the path of least resistance in rails. It's clear how to organize and find templates, where things can be found, where to put images, javascript, stylesheets, etc... It's easy for us to make a single step deployment which depends on those tests.
The reasons for this intelligent defaults and best practices philosophy are two fold. First they reflect the work of DHH and 37signals who are developing simple usability and standards focused web applications. They get it, and build in the best practices of web development in to their framework. DHH was a php developer who spent a lot of time reading about design patterns and he was able to use those patterns to improve his applications.
The second important source of the rails philosophy can in part be traced back to Ruby. With Python you have a philosophy of 'batteries included' which means they try and include all the libraries most python developers need. Php everything is thrown in the core language. With perl you have 'there is more than one way to do it' which has created a great selection of modules in CPAN, but also a community which shies away from promoting best practices. Ruby draws on the traditions of both perl and smalltalk. It has a culture of encouraging things like design patterns and best practices in software engineering. In Ruby there might be many ways to do it, but one of them is better than the others. Ruby has a much smaller community than the other scripting languages. It's cpan is not unified, but rather a directory of libraries RAA and a package management system gems.
Ruby helps to make rails work. But what everybody forgets is the cultural baggage which each community brings to it's work. Rails works because it's a product of standards and agile focused web developers working on web 2.0 style apps who have adopted ruby which inherits from the smalltalk community's legacy. Rails doesn't succeed because there aren't other ruby web frameworks, or because ruby is the perfect language. It works because it's the right combination of two traditions with some hype and an open and cooperative community supporting the framework.
I specialy like the last paragraf where you point out the importens of cultur.
Posted by: Anders Carlsen at April 8, 2005 07:10 AM