Ruby on Rails is a web framework first released in public beta form in 2004. The developer, David Heinemeier Hansson, extracted the framework from a 37Signals project called Basecamp. As of this writing, Rails is on 1.0 release candidate 3.
Facts like these are important. Rails is incredibly overhyped, due to a confluence of factors ranging from the high standing of Ruby in programming language geek circles to the sycophantic adoration of all things 37Signals by a large swath of the web developer blogosphere. But don't judge a product on hype.
Criticism
Unfortunately, most criticism of Rails comes in one of three forms:
- Ignorant PHP/ASP programmers who insist nothing could be better than what they currently use. Worthless.
- Slashdotters who are sick of the hype but actually probably aren't even web developers at all. Completely Worthless.
- Serious web developers accustomed to big full-featured web frameworks. Fair.
"Rails is immature"
Because Ruby has only recently taken off outside of Japan, and because Rails is so new there are definite maturity issues here. For one thing, Ruby is slower than Perl or PHP. Partly this is due to the power and flexibility Ruby affords the programmer, but its also due to a lack of optimization.
The Rails platform itself can be unstable at times due to a lack of widespread testing. This is changing quickly. Thousands of web developers are digging into Rails, and as a result, the first wave of web hosts has already started offering Rails hosting. Even so, any professional developer would be well-advised to spend a while working with Rails before recommending it to clients.
"Rails lacks industrial-strength features"
This criticism often comes from J2EE or .NET developers who judge the quality of their web framework by the size and quantity of available libraries. Rails simply can not compete on this criteria. If you are writing a focused web application with large chunks of functionality requiring libraries that aren't available for Ruby or C then Rails is likely to be unsuitable.
The Rails Way
The founding principle of Rails is Don't Repeat Yourself (DRY). The second (probably more important) principle is that of Convention Over Configuration. The first principle allows your code to change easily by reducing the number of interdependencies. The second principle allows you to get things done with a terrifically small amount of code.
The principles by themselves would do little without a sensible architecture, and Rails gets in done in flagrant style. A lot of web frameworks use the Model-View-Controller design pattern, but Rails elevates it to an art form.
Default Mappings
If you have a model class named "Order" and a database table named "orders" then the class will automatically be populated with accessor methods based on the row types from the table. You can get most common operations done with the built-in methods, yet Rails does not restrict you from descending into SQL yourself or overriding the default mappings if need be.
Likewise, a controller class named "Product" called with an action "List" will automatically use a layout template "product.rhtml" with a content template "list.rhtml" which will have access to methods in "helpers/product.rb".
This is just the tip of the iceberg, but this type of automatic mapping extends to every area of Rails, making things come together in a smooth and natural fashion and eliminating the need for superfluous require statements. The true beauty is that these are just defaults which can be overridden any place you like.
Scripts
Rails gives you a series of very powerful yet easy-to-use command line scripts. The generate script can quickly set up controllers, models and scaffolding (among other things). The server command is a built-in web server for local testing. The breakpointer allows you to do live debugging on your application code as it runs. This last one in particular utilizes specific features of Ruby that just can't be implemented in most other languages.
HTML Niceties
Rails offers a wide array of helpers for generating clean HTML. When you use these helpers you get a lot of flexibility from your application. For instance, the link_to helper will generate a link to a given controller and action. If you later change how URLs map to controllers in your application these links will not break.
Generating forms is particularly nice with Rails. Form helpers easily generate persistent, error-corrected forms, including specialized but common field formats such as date or country select menus. For anyone who has developed their own method of creating robust forms from scratch using PHP or Perl, this facility alone can save dozens of hours in a typical web application.
Database Associations
Rails can handle the majority of common database relationships automatically by means of simple declarations such as has_one, has_many, belong_to, and has_and_belongs_to_many. These declarations create a series of methods that make multi-table objects just as easy to manage as single-table objects in the simple case. As always, Rails gives you convenient defaults for the common case without restricting you from digging deep into the database with your own SQL for advanced functionality or optimization.
Callbacks, Filters and Observers
Its easy to register methods to be called at any stage of Rails processing whether it be in the controller or the model. This gives the programmer hooks into Rails without having to understand the internal complexities. Using this facility you can easily guarantee that certain code always gets executed at critical junctures with a single declaration.
A perfect example would be a site-wide authentication system. In Rails you could define an authentication function once, and in the global application controller you add before_filter :authenticate which would guarantee that the authenticate function is always called before any action is executed. In one line of code. Without polluting actions.
Flash
Nothing to do with Macromedia, the flash is a temporary storage location that persists for exactly one subsequent request. This simple concept makes it easy to do things like redirect a user after an error or a successful form submission while still letting them know what just happened in a standardized way.
Unit Testing
Unit testing is integrated right into the framework, making them easier to define and run than in any system I've ever seen. Running all the unit tests is as easy as typing rake.
Misconceptions
Rails has a number of impressive demonstrations on the website that are a double-edged sword. The infamous scaffolding shows how easy it is to set up a simple Create, Read, Update, Delete (CRUD) application for a database without writing a single line of ruby. Unfortunately many people think Rails is the scaffold command, which couldn't be further from the truth. scaffold just generates some code which is easily modifiable and a good example of simple rails code to get you started.
Another misconception is that Rails is slow. Since Ruby is slow, and because Rails does so much magic this is absolutely true if you run Ruby as CGI. However, if you run Ruby under FastCGI all the code stays loaded in memory which gives it a considerable advantage over unoptimized Perl or PHP applications. Furthermore, by means of the new Lighttpd server with automated load-balancing, Rails apps have the potential to scale to large server clusters quite easily.
Learning Rails
As you can probably tell, I'm unabashedly pro-Rails. I don't want to pretend that Rails is perfect. But I encourage serious web developers to spend a few hundred hours learning Rails to make a true evaluation. There is a massive reality-distortion field around Rails that makes it hard to get straight information. After 6 years of growing frustration with design flaws in the PHP language, and growing interest in the elegance of the Ruby language, Rails was a no-brainer for me. If you are interested please see the following resources: