If you build websites, you have no doubt heard about Ruby on Rails (RoR). But if you’re a designer or front-end developer or you’re using PHP without any application framework, it may seem like a big leap to adopt the Ruby on Rails approach. In this article, I hope to demystify Ruby on Rails and convince you that you can make the leap—and that it is a leap worth making if your needs fit within the Ruby on Rails “sweet spot” detailed below.
It does take time to learn new ways to do all the things you already know how to do, and to learn some new concepts and techniques at the same time. In the short term, switching technologies, even to Ruby on Rails, will destroy your productivity. Nevertheless, I’m convinced that many web developers would be more productive, produce better sites, and even have more fun if they took the leap and began using Ruby on Rails.
Fun for the whole family#section2
If you’re a web designer or front-end developer, you can learn how to use the Ruby on Rails template system, and how to write little bits of embedded Ruby code in your view files. This will make you a much better partner for a back-end developer, since you can work directly on the Rails application files instead of delivering HTML and CSS that someone else has to integrate.
So whether you’re approaching Ruby on Rails as a front-end or back-end developer, on which projects should you consider using it?
The “sweet spot”#section3
Ruby on Rails is at the heart of diverse web applications and sites such as Basecamp, Blinksale, 43Things, Odeo, Revolution Health, Twitter, YellowPages.com, and A List Apart. The enthusiasm for Rails extends to many of the largest web companies. Yahoo, eBay, Amazon, and AOL all have Ruby on Rails projects, and ThoughtWorks is creating enterprise applications in Rails. But for all the diversity of Ruby on Rails applications, the ones that are best-suited to the framework have a few key things in common.
A website or web service is most appropriately implemented with Ruby on Rails when it has the following three characteristics:
- It is a database-backed website or web service large enough to justify the overhead of a powerful framework.
- It has unique needs that aren’t well met by a typical CMS. (If Joomla or Drupal does everything you need, such systems may be a better choice.)
- It is a new application, allowing developers to start fresh with the database and software architecture.
This is the “sweet spot” for Ruby on Rails applications. Applications that share these characteristics can probably be built much more quickly with RoR than with PHP, .NET, or Java, once the investment required to learn Rails has been made.
One of the main reasons Ruby on Rails increases productivity is that it makes building new applications, adding features, and making tweaks much easier. The combination of the language (Ruby) and the framework (Rails) means you can do more with less code. Less code—and better-structured code—means changes are relatively painless, so you can iterate and experiment more readily. This leads to better sites, and, hopefully, more fun building them.
Of course, adopting a major new tool requires an investment of time that can’t be taken lightly. If you’re focused on a single project, it often isn’t justifiable. But if you expect to keep building websites for some time, and you’re building sites of significant complexity, a short-term investment in learning Ruby on Rails will pay off in the long term.
To understand why I believe you can do more with less effort using Ruby on Rails, let’s start with a quick look at Ruby.
Ruby is a modern, object-oriented language. In any Ruby program, everything is an object. Ruby is also a dynamic language, which means a variety of things:
- Ruby is interpreted dynamically (like PHP), so there is no compilation (as there is with C or Java.) This speeds up iterative development.
- In Ruby, variables are dynamically assigned a type when they are used, eliminating all the code you must write in most other languages to define and set up variables.
- A Ruby program can generate code dynamically, modifying itself as it executes. Rails uses this capability internally to deliver its “magic,” which you can simply enjoy. (You don’t need to understand how these techniques work.)
Ruby is a wonderfully clean language to read and write, but its benefits go beyond that. Because Ruby can be powerfully extended, the Rails framework is able to turn it into a sort of special-purpose language for building web applications.
While Ruby (a language) and Rails (a framework) are separate things, they complement and depend on each other in many ways. All Ruby on Rails applications are written in Ruby, and the character of Ruby has a big influence on Ruby on Rails applications. There are frameworks, such as CakePHP, that bring many of Rails’ ideas to other languages. But the power and flexibility of Ruby makes Rails cleaner and more flexible than many other frameworks. If you’re going to make the investment in learning a framework, learning Ruby while you’re at it isn’t that big a hurdle, and the payoff is considerable.
The Rails approach#section6
Many websites are built without any application framework at all: you just write the code you need and borrow bits from various places when you can. That’s fine for small sites, but it can quickly get out of control, resulting in reams of messy code that is hard to understand and to maintain.
With a framework such as Ruby on Rails, a lot of decisions about how to structure your code are already made for you and you also have a powerful set of libraries at your disposal.
Another important characteristic of Rails is that it organizes each application around a model-view-controller (MVC) structure. MVC, a well-established pattern for organizing software projects, gives all your code a consistent structure, which helps a lot when you’re working on multiple sites, or bringing in someone new to work on a site. It also provides separate files, with clean interfaces, that can be split between front-end and back-end developers.
Databases and objects#section7
Ruby on Rails is designed to be used to build database-backed applications, and many of its core components focus on interacting with databases. The heart of Rails is a library called Active Record, which implements something called object-relational mapping (ORM). With ORM, you can work with software objects that represent your data and let the Active Record library take care of communicating with the database.
This may sound mysterious in the abstract, so let’s make it concrete. Even without knowing any Ruby—or anything about object-oriented programming—I bet you can make sense out of the following code examples, which are pieces of actual Ruby on Rails code.
Suppose you have a bookstore site and you want to add a new book. You could write:
newbook = Book.new
You’re telling the “Book” class that you want an empty book object, named “newbook.” You can set the title, or any of its other attributes, in an intuitive way:
newbook.title = “Angle of Repose”
newbook.author = “Wallace Stegner”
At this point, you have an object in memory. All it takes is:
…and your new book has been written to the database. Active Record generates the SQL to tell the database to insert the record. You can add validations on all the fields and generate descriptive error messages with just a few more lines of code.
Now you want to find that book out of the millions in your database. Just write:
angle_of_repose = Book.find_by_title “Angle of Repose”
…and you have an object, which you’ve named “angle_of_repose,” that has all the information from the appropriate database record.
There’s a little more to it, but not that much; working with software objects that reflect the information your site deals with is a natural and powerful approach. In RoR, you have a rich set of software objects that correspond to your database tables, and these objects make up the “model” layer of the model-view-controller system.
Your code interacts with the model objects, and Active Record creates the SQL to make the database do what you want. You don’t have to write any SQL to work with the database. And since none of your code communicates directly with the database, you can switch from one database engine to another by simply changing a configuration setting.
Views and controllers#section8
To create web pages, Rails provides a template system that makes it easy to use consistent page structures, to insert common components without repeating their code, to render information that comes from the database, and to display and process forms. These templates constitute the “view”? layer of the model-view-controller system.
If you’re a front-end developer, this is the part of Rails you should focus on. You can simply assume that your “view file” will be handed variables that contain whatever information you need to display. Just as PHP files are a mix of PHP code and HTML, a typical Rails view is a mix of Ruby and HTML. Continuing with our bookstore example, here’s a snippet of view code that displays the title and author of a book:
<h1><%= book.title %></h1>
<p><%= book.author %></p>
The Ruby code is marked by
%>; the rest is HTML. The HTML and the output of the Ruby code are combined to create the web page.
A “controller” is a piece of Ruby code whose primary job is to communicate with the model to prepare the data needed by the view. Any information that the view needs is assembled by the controller in a set of variables before invoking the view. The controller also responds to Ajax requests after the page has loaded. Controllers provide a variety of other functions as well, from user authentication to error handling.
“Convention over Configuration”#section9
Rails tries hard to provide reasonable defaults for almost everything. Following a philosophy called Convention over Configuration, Rails almost entirely eliminates configuration files.
If you follow the Rails conventions, an amazing amount of stuff, from routing requests to the correct controller and view, to validating form data and displaying error messages, just works. Compared with most other languages and frameworks, it takes less code to accomplish most common tasks.
The Convention over Configuration approach is sometimes frustrating for newcomers, especially if they try to learn from an existing application, because there are hidden assumptions behind much of the code. The assumptions are what make the code simpler, but they can be confusing when you don’t know them. After you learn the Rails conventions, though, everything in Rails makes more sense. And when you’re building a new site, you have the wind at your back, because so much is already defined for you.
It’s not perfect#section10
Rails does have its drawbacks. These weak points are minimized for applications that fall within the Rails sweet spot I described earlier, but they can be big issues at the fringes.
Ruby is slower than most other languages. This is likely to change this year, but for now, it is a disadvantage—for those few applications in which processing time is actually an issue. In reality, this is a non-issue for the vast majority of websites.
The overhead of the MVC framework can also slow things down. With a little attention, though, most Rails applications can be made to perform very well. Model requests often need tuning to reduce the number of database accesses required. You can often eliminate database requests entirely: Rails includes a powerful caching system, so pages can frequently be created once and delivered many times.
Rails applications are also more trouble to host than PHP applications. Because of the size of the Rails framework code, it has to be kept in memory all the time, not loaded in response to a request. You need 100–200 MB of dedicated RAM to host even a low-traffic Rails application. With PHP applications, in contrast, you can host hundreds of applications on a single server, because they don’t occupy any memory when they aren’t being accessed.
Because of these server requirements, shared hosting of Rails applications is generally problematic. A VPS (virtual private server) is usually the best choice. Setting up a Rails server can be more complex than for PHP. This was an issue a year or two ago, but now there are many Rails-oriented hosting companies that provide turnkey solutions.
Another result of these server requirements is that Ruby on Rails hosting tends to be more expensive than for other platforms and languages. If you’re in the Rails sweet spot, your application is significant enough that the incremental hosting cost is insignificant compared to the value you get from using Rails.
The learning curve#section11
The complexity of Rails can make it hard for a beginner to get started: it takes months to become familiar with all of Rails. But you can get started by first learning just enough to build a basic Rails site. As you begin working with it, you’ll pick up new skills and knowledge as you need it.
People come to building websites in various ways and from different backgrounds, but most of them fall into one of two categories:
- People who have an idea for a site they want to build and learn just enough technology to build it.
- Programmers who see websites as just another kind of program.
Ruby on Rails was built by programmers, for programmers. So if you come to it from a professional software development background, it will feel a lot more familiar than if you come from web design.
If you’re not a software developer, there’s more to learn, but it’s not beyond your reach. Learning the parts of Ruby, and some bits of object-oriented programming, that you need to know to use Rails is not difficult. To start building applications using the Rails framework you only need to know how to use a limited subset of Ruby’s capabilities.
You can leave the advanced Ruby coding to those who work on the framework itself. You don’t need to understand much about how the internals of Rails works, or the techniques (such as metaprogramming) that it uses internally.
The Rails ecosystem includes many practices that come from the software development world, including use of source-code control systems, an automated testing framework, documentation tools, and deployment scripts. If you’ve been doing ad-hoc web development, these may be foreign concepts, but they can bring a lot of sanity into your work life once you become comfortable with them.
What to learn when#section12
The art of learning Rails is figuring out just what you can ignore at which stage of your education so you can grapple with a few things at a time, instead of with all the diverse technologies that make up a Rails application. (One easy way to get started learning Ruby on Rails is with the “free online course”:http://www.BuildingWebApps.com/learning_rails produced by the author of this article.)
Start by learning the basics of Ruby. You don’t need to go too deep, but you need to know the basics before you can effectively develop with Rails. Rails code looks almost like markup, and it is tempting to think of it as such, but you need to make the shift to thinking of your site as a program that emits web pages, rather than as a set of files that are web pages.
If you’re focused on the front end, learn how layouts, view templates, and partials work. If you’re working with a back-end developer, they’ll take care of the model and controller layers and provide your views with variables packed with just the data you need.
At first, you can ignore Ajax; it’s a largely separate layer that can make a big improvement in the user experience, but it really is optional. So you can put RJS, Prototype, and Scriptaculous aside when you’re learning Rails. Add on a layer of Ajax sophistication once you’re comfortable with the basics.
If you’re a back-end developer, concentrate on learning how to model your application domain as a set of resources, create your database tables, and use the resulting objects. The Rails framework is wide and deep, so it takes time to learn thoroughly, but you don’t need to use very much of it to get started.
While you’re learning Rails, you can ignore testing and all its associated complexities, even though it gets a lot of attention in discussions of Rails. When you’re further along, come back to it—but don’t let it slow down your initial learning or add to your cognitive load.
And you’re off!#section13
Once you’re up to speed, Ruby on Rails will become an old friend. With this powerful set of tools at your fingertips, you’ll be more productive than ever.
By being able to do more with less code, you’ll build better sites and have more fun doing it. There’s no looking back.
25 Reader Comments
Rails articles constantly make this mistake: they tell you how great Rails (framework) is by comparing it to PHP (language). This article seems to be no exception.
All though I agree that Ruby is an awesome language and that Rails is a pretty cool framework (they are my preferred tools), I think alot of developers who already know PHP would probably be just as well off with something like Symfony, which is basically Rails for PHP (or CakePHP as you mentioned, haven’t used it).
Same thing for other languages: MVC frameworks Rails-style is popping up all over, and even though Ruby brings alot to the table, you can be very efficient with these kinds of frameworks for other languages as well.
I did quite a bit of RoR research for a website intended for a client. I found the language’s elegance and simplicity very refreshing, and once I’d got my head around the Ruby language, I found things to be quite natural.
It was good to see that this article contained some of the negatives of the framework. Many people point to the performance argument, stating that it is too slow for larger sites, but there are many examples where it has worked. I was also interested to hear of the some of the big names on the web (Amazon, eBay for example) taking a large interest too.
Might as well go the whole way and get continuations going! http://www.seaside.st
I’ve been looking for more information on RoR and these two articles provided me with exactly what I was looking for. I was deciding whether to expand my PHP knowledge or delve into Rails. I have already started to increase my understanding of PHP, however, after reading this, I will certainly start to learn rails sooner rather than later.
Really awesome introduction into what RoR really is. I’ve been struggling these past few weeks trying to learn more and more about CakePHP, and this article definitely cleared a few things up pertaining to the MVC methodology of web development.
I wish to pick up RoR soon, but probably will stick with a PHP framework for now.
I’m ecstatic to see the negatives presented. I haven’t deployed any RoR personally, but I’ve worked on several sites, and found it to be a real mess. Requiring 200 mb of Ram to simply run a small site for a small audience is not appropriate, and the vast majority of articles I have read on RoR gloss over this.
The size & scope of my work means I probably won’t ever use RoR: it’s not worth learning it, to me, because my average client isn’t going to spend the money on the VPS required to run it.
It’s still a nice, elegant framework, and I wouldn’t complain if I ended up working in it, but right now it just doesn’t seem feasible.
One on the things I love about Rails is how it has popularised well structured code for the web developer community.
PHP, much like HTML, can be written as shambolic or as elegant as you wish, with the latter becoming more prevalent–following the same cleanup crusdade that the “web standards” movement had on HTML.
I really like Rails although I think there’s a missed opportunity with it currently: the ability to have a set of well structured, inter-locking modules (content updating interfaces, blog, shop, etc) so that each project done by the millions of people out there doesn’t duplicate a lot of their work.
SilverStripe solves that issue, and is written in the easy-to-host language of PHP5.
See http://www.viddler.com/siggy/videos/1/ and http://www.silverstripe.com
I’ll be brief Ruby has nice features.
Mongrel ( the de facto Ruby on Rails Application server) does not The link below is from the head Mongrel developer.
IMHO he must be smoking some serious stuff to even think this is worth using in production.
Outside of that perl is better suited and more mature for general purpose coding. Stay far away from RoR unless you are willing to deal with a new language and a new framework.
In my humble opinion, Ruby on Rails is not quite 100% there yet. It’s best-suited for that “sweet spot” mentioned in this article, but even then there are drawbacks and complications, such as hosting, that come into play. And this type of problem is dramatically magnified if YOU are the one maintaining the Web server. 🙂
The constant comparison of Rails to PHP is also getting old; it’s like Hilary vs. Obama. If Rails could stand on its own without having to try to downplay PHP’s “less elegant” ways, it would spread much faster.
Anyway, I built a few Rails applications for a few clients. I really like Ruby on Rails (it’s some of the most fun I’ve had coding), but PHP, for now, is just the better solution for 99% of the tasks out there, so I’ll stick with it.
Let Rails take a few more steps, and we’ll start seeing it become more prominent.
Christian, I appreciate the difference between languages and frameworks, and I’ve tried in this article to be clear about this. Most PHP apps are built without a framework, so there is some meaning to comparing a PHP app to a RoR app. As I noted in the article, there are indeed MVC frameworks for PHP, and they are far better than using PHP without a framework.
But I don’t think PHP is as good a language for writing object-oriented programs, and it just isn’t possible to build a framework that fully matches Rails without the metaprogramming and object features that Ruby has. The differences probably aren’t consequential for small apps, but as apps grow in size, they become more important.
If you want to leverage your PHP skills, frameworks such as CakePHP are a good solution. But I believe that Rails is even better, once you invest in climbing the learning curve.
Micheal, i’m interested in your thoughts about DHH’s comment other platform/languages.
i can’t comment on RoR simply because i’ve only used php/asp.net. however, i’m not quite sure if RoR is a fad or it’s going to stay here for the long term. DHH’s tone certainly didn’t help.
Mark S., I don’t know what the issues are you have with Mongrel. It is by far the most widely used app server for Rails, and is used in sites that deliver hundreds of millions of page views a month. Do you have any specific criticism to make?
Zed’s rant is amusing, but I’m not sure it’s relevant. Zed wrote Mongrel, and he’s a fine programmer. Clearly he has become angry and feels alienated from the Rails community. I don’t know what all was behind that, but I’m pretty confident it has more to do with interpersonal issues than with technology.
(To those of you who have no idea what this is about, read the article linked in Mark’s post and make your own assessment.)
As for Perl, it is a fine language in the hands of skilled programmer for system hacking, but I don’t think you’d find many people recommending it for building substantial web sites. If you don’t like Ruby, Python is probably the best alternative.
JY, David (DHH = David Heinemeier Hansson, the original developer of Rails) is an opinionated guy, and he can undoubtedly piss off people who don’t like his views.
The article you point to is mostly about Windows vs. Mac as a development platform. I think David overstates his points, but I have to agree that the Mac makes a better development platform. Ironically, this has little to do with the Mac’s vaunted usability, and everything to do with the fact that underneath the skin, the Mac is Unix.
Because Unix lies just below the Mac skin, it’s a lot more compatible with the software that runs on most Web servers. Most Ruby developers use Macs or Linux, so everything works on those platforms, but there are things around the edges that no one has bothered to make work on Windows. You can make (almost) everything work on Windows, but it’s more trouble.
I’ve used both platforms extensively. I was on Windows for most of the past decade, but switched back to the Mac early this year. There’s “lots of good things”:http://blog.buildingwebapps.com/2008/1/31/back-to-the-mac and some “not so good things”:http://blog.buildingwebapps.com/2008/4/12/macbook-pro-frustrations about the Mac.
In any case, all the stuff about Mac vs. Windows really has nothing to do with Ruby on Rails. And David doesn’t act like an evangelist, because that’s not a role he wants. He built this technology for himself, and for others who share his views. If you like it, great. If not, he’s happy for you to use something else.
Recently there was an Apache module released called “mod_rails”:http://modrails.com/ that makes it very simple to deploy Rails applications. It’s a great alternative to Mongrel.
Coming as I do from a Java background to web design and development I have found that the Grails framework (http://grails.org) is more natural fit for me than RoR. The advantages to me are that I can re-use all of my existing Java knowledge.
The more general advantages are that Grails leverages a lot of existing infrastructure and frameworks in the Java space. It is suitable for projects with existing databases due to its support for the Hibernate OR mapping framework. It also leverages many existing Java application servers meaning better relability and up time for customers.
“The complexity of Rails can make it hard for a beginner to get started.”
So it’s not like PHP which is very easy to start coding small scripts with? Isn’t the whole idea of RoR its simplicity, not complexity? Or is it only simpler once you have mastered the whole package?
I love PHP as I can only learn what I need to get a task done, and the syntax is easy to learn.
The comparison is fair, I think. PHP is essentially a templating language, and you won’t find many people writing Ruby web apps from scratch. But PHP gets the benefit of the doubt initially since it can be further extended with the many available frameworks. Clearly, Symfony, CakePHP, etc. are closer to Rails for comparison’s sake.
For those who haven’t, I recommend this article: http://terrychay.com/blog/article/php-ruby-evil-good.shtml
From the article:
“I used to tell people that Ruby is where Java developers went to lick their wounds after getting schooled in the first boom by an ugly POS language like PHP. They had dreams of Ruby on Rails rising up like a phoenix from the ashes of J2EE and teaching these (often) drunk PHP developers that Web Development can be just like the Ivory Tower that taught them Java (or Ruby)”¦and justify their overpriced salaries.
Oh yes, I’m on to you. If Derek had written this article two months earlier there would have been nary a peep out of you.
Because I was wrong. The J2EE developers are still around; We’ve just added a bunch of high school “entrepreneurs”? to the mix. And they’re finally back from summer camp to lecture us on how to run a “real-world”? website.”
For the record, I don’t think Rails is particularly viable for any but a small group of developers. Its stack is far too large for small projects, let alone on shared hosts. Its scalability issues make it unfavorable for large projects as well. So Rails really only fits well for developers who want to build a medium-size project with the associated overhead of a large project, but who don’t expect stupendous growth.
By the way, my last post may have been unclear. The final paragraph is my own opinion, and the second to last paragraph is the last one that I included from the linked article.
Thanks ALA. I have read both articles today and will definently be giving ruby a bash. But as i’m also learning PHP, it makes sense to keep an open mind and give both a try. I have the time to learn both, so why not. The only concern i have with ruby is the restrictive hosting.
1. The restart issues are real I have seen them first hand. No reasonable application frame-work should have to be restarted this often. Look on rubyforge for monitoring apps. if ROR was so well written why the hell are there like 20 some odd monitoring apps for ROR and Mongrel.
2. The idea of running a cluster of mongrel instances on on a single host, is garbage. If Mongrel_cluster was designed to be setup this way they there should be a simple way to restart each instance and not the entire cluster. This is not the case.
3. Your comments on Zed’s rant “. Clearly he has become angry and feels alienated from the Rails community.” Last time I check Mongrel biggest consumer/abuser is the ROR community. What will you all do when he decides to stop coding in Ruby ?
4. Ruby the language, has issues. Its a fork of perl and still has major issues with threading support like perl. Any no running it on OS X vs Linux vs FreeBSD makes no difference .
5. I think web developers should stop looking for “Magic Beans”. While ROR has a great rapid application development framework for people who have not coded before; it will not prevent you from making very crappy code. It in my head is like writing banking software in LOGO
6. Why not look at Apache Struts , Cocoon or MyFaces
Chris, when comparing PHP and Rails, remember that PHP is a language, while Rails is a framework. So there is a lot more to learn with Rails. It is a complex framework, whose goal is to make it simpler to create significant web sites, but you do have to climb the learning curve. If you just want to add some small dynamic capabilities to an otherwise static site, PHP is a better choice.
Thomas, I agree that Rails is best suited to a “middle range” of sites, but perhaps we disagree on how wide that range is. The scaling issues have been overblown, and there are some quite sizable Rails sites. YellowPages.com does more than 170 million page views per month; the Facebook app Friends for Sale is doing more than 300 million page views per month. RevolutionHealth.com gives an example of a quite complex site with moderately high traffic.
I recently posted a article on “how Friends for Sale has handled the scaling challenges”:http://www.buildingwebapps.com/articles/23-selling-friends-scaling-a-high-traffic-rails.
Hey A List Aparters,
I’m an Interaction Designer at ThoughtWorks and we’ve been working with Ruby on Rails A TON lately. The developers here love it, and they’ve worked hard to help it scale to our enterprise clients’ needs.
As a designer, it has been fabulous. Never before have I had so much control over the end product we create. I don’t have to worry about breaking back-end code, and have almost full control over the view. I’ve enjoyed it a lot.
Thanks for the great article, and best of luck to everyone out there.
Great introduction to an important concept. I will check out more to see if it is worth the switch.
I don’t know whether it’s just me or if perhaps everybody else encountering issues with your website. It appears as if some of the text on your posts are running off the screen.http://www.xtremewalls.com
Got something to say?
We have turned off comments, but you can see what folks had to say before we did so.
More from ALA
Personalization Pyramid: A Framework for Designing with User Data
Mobile-First CSS: Is It Time for a Rethink?
Designers, (Re)define Success First
Breaking Out of the Box
How to Sell UX Research with Two Simple Questions