The Joel on Software Discussion Group

After all those talk about Ruby on Rails, I got curious. Can someone give a brief rundown of what really makes RoR so great? What features make it shine so much in comparison to others, and what doesn it have that the others don't?

Well, the obvious one is Ruby itself, but please avoid that -- every language has its pluses and minuses, and while Ruby is better then some, it is still in the hands of the programmer in the end. I'd really like to know what is it -- in terms of architecture, design and usage -- that gives RoR an edge above existing and proven frameworks and platforms written in Java, PHP, Python and other languages.

Ask yourself what would make a good web framework in your opinion. Rails has a lot of what makes a good web framework. Take one by one, Java, PHP, ASP.Net, etc, and compare them to Rails.

Is Rails perfect? Nope. What is perfect in this world anyway?

Could Amazon be entirely written in Rails? Maybe.

Could EBay be entirely written in Rails? Maybe.

But you won't start a business or a project with the need to support the load of the top sites. Before you can conquer the world, you need at least a dedicated server on the web. :-)

Convention over configuration, no deployment step during development, ActiveRecord O/R mapping...

Why not take a look at the 15 minute intro video at http://www.rubyonrails.com/media/video/rails_take2_with_sound.mov

Thank you both for your replies, but I muste have not managed to express myself clearly enough.

Agent Smith, perhaps I made the impression that I want to bash RoR and that I'm trying to be ironic about it. I assure you that it wasn't my intention -- I would really like some answers and opinions, preferrably by someone who used to an extent. I would like to check it out by installing and trying it myself, but I don't have the time.

John, thank you for the short list, but I am not sure how exactly those features give RoR a real edge. What do you mean by "convention over configuration" and "no deployment step during development"? Also, there are other frameworks who use ActiveRecord...

As for the video: I might take a look, but I would really to hear about RoR from people outside its creators, with some real experience.

The Rails framework is good for CRUD operations. The video that is linked shows something called scaffolding. Scaffolding is cool, but I doubt you'll use it for a finished, commerical product because you'll end up rewriting a lot of the scaffold code to fit your application's needs.
I've previously used PHP and I see it as a great improvment over PHP in many areas due to its ease of CRUD operations. Rails also has some cool things for database table relationships and has built in AJAX support. I'm stil a newbie for rails, and there are some annoyances that I couldn't figure out how to do with the framework yet.

Well I've only just started learning Rails myself but I like the fact that I can get up and running quickly because Rails favours convention over configuration. My background is J2EE, which is architected to be massively flexible - there's indirection and XML configuration files everywhere. The Rails approach is different, it says up front that most of the time you're going to be doing the same sort of thing and you probably don't need this much flexibility, so it gives you lots of sensible defaults. Rails saves you time by mandating certain things. For example, even something as fundamental as the directory structure you use for your projects is fixed by Rails. The creator of Rails calls it opinionated software.

The Rails scaffold command generates a basic web UI which lets get up and running and able to test your model classes and database schema straight away. The beauty is that you can gradually replace this scaffolding with the real UI.

When I'm developing a J2EE application I have to go through a stage of deploying it to a J2EE container (server) before I can test it. This can take a few minutes. With Rails I can make a code change and then hit Refresh in an already running browser instance and see my changes instantly. That's because Rails re-compiles the code for every request. Note that this behaviour is automatically turned off when deploying to a production environment. That's another thing: Rails has built-in support for separate development, test and production environments.

Note that Rails is the only framework that uses ActiveRecord because this is Rails' own flavour of O/R mapping and it doesn't require a single line of XML configuration unlike (for example) Hibernate in the J2EE world.

There is a good interview with the creator of Rails that should give you a flavour of the ideas behind it: http://www.oreillynet.com/pub/a/network/2005/08/30/ruby-rails-david-heinemeier-hansson.html?page=1

Could Amazon be entirely written in Rails? Maybe.

Could EBay be entirely written in Rails? Maybe.

I think this would be very unlikely considering that connections are managed thread/connection with fastCGI.  IMHO it would nearly impossible to scale this to level of Amazon. 

It might be possible to render some pages with Rails, but I can't imagine any of the database stuff would be useful for the site the size of Amazon.

RoR's makes AJAX drop dead simple.  You essentially avoid all of the Javascript crap and cross-browser headaches and just pass it which DIV tag to update.  It's honestly just as easy if not easier to write an AJAX based website in RoR vs a convential submit/query/return type site.  This support alone is enough to perk my ears up.

Generally speaking, you won't ever write a select statement or worry about directly interfacing with the database.  All of this crap is taken care of and all you have to worry about is the logic behind displaying the webpage, reacting to user events, and any business logic.  RoR ties everything together very seemlessly.

Can RoR handle stored procedures easily?

I don't think RoR (or more specifically ActiveRecord) support sstored procedures.  The founding author seems pretty opposed to them here:

http://www.loudthinking.com/arc/000516.html

"RoR's makes AJAX drop dead simple.  You essentially avoid all of the Javascript crap and cross-browser headaches and just pass it which DIV tag to update."

In the RoR tutorials I saw there was no mention of any Javascript libraries, but if what you're saying is true, then someone else basically already wrote "all of the Javascript crap" required and took care of the "cross-browser headaches" (but remember the Law of Leaky Abstractions.

I originally wanted to post my impressions about RoR here, but they turned out to be so long that I decided to start writing my blog in English (instead of in Croatian), and it became the first post originally in English there (I later translated some of the earlier ones). So, if anyone's interested, my response can be found at http://www.lopsica.com .

The AJAX support is part of the Rails standard distribution.  I am pretty sure that all of the Javascript libraries were implemented in-house and that this isn't some 3rd party add-on.


http://www.onlamp.com/pub/a/onlamp/2005/06/09/rails_ajax.html
http://www.loudthinking.com/arc/000428.html

link_to_remote is your friend.

Berislav, on your own words:

"I did my homework, and while I really didn’t have the time to try RoR myself, nor even to watch the video, I read the interview, as well as the tutorials linked to from RoR site, and some other articles on the Web."

And later:

"...as I have seen literally all of the RoR features implemented in various PHP applications and/or frameworks..."


Rails has too many features for one to simply try to read about them. Maybe if Rails had a "spec" you could read about all its features. Maybe the book on Rails has most of them:
http://www.pragmaticprogrammer.com/titles/rails/index.html

What if many of the features that you think are interesting were included in one framework? What if many of features that many people think are interesting were included in the same web framework? What if it's not just about features, but about books, examples, tutorials, articles, community, etc?

Stuff like link_to_remote and form_remote_tag are useful, but just like the Web components in ASP.NET this approach abstracts the reality of Web duality with a potentially extremely leaky patch.

I'll probably write a full blog post about that someday, but briefly, an oft overlooked fact is that each Web application actually consists of two applications, one running on the server and the other within the browser. "Ajax" may change how the two communicate, but it doesn't change that fact.

Agent Smith, I am not attacking Rails. In fact, I found it very complete and useful, so there is no need to defend it.

It's only that I'm personally not sold on it -- actually, it inspires me to try some of its ideas with other technologies.

"What if many of the features that you think are interesting were included in one framework?"

Nothing -- I'd surely find at least some little bit I didn'like and go off making my own implementation.

"What if many of features that many people think are interesting were included in the same web framework?"

Nothing -- most probably, neither will all those features be used by everyone, nor there would be a single feature used by all.

"What if it's not just about features, but about books, examples, tutorials, articles, community, etc?"

Nothing -- are you aware how many of the above there is about Java-based technologies? And you'll agree that it doesn't make those technologies any better.

Berislav, in your own words again:

"A runaway train"

And several "low blows" on Rails through out your post.

If this is not attacking Rails, I don't know what it is. :-)

Like, you criticize Ruby with a "Perl-like swearing", but you use PHP which has its own flaws.

So, should one use only the "perfect" language (Python) or what?

You see, the more frameworks there are the merrier. I wish you good luck on creating your own.

Maybe a better question is: What problems with traditional web application development (via Perl/ASP/PHP/Java/ColdFusion) are solved much more elegantly with RoR?

I think it's a little misguided to talk about these systems in the abstract. For example, PHP alone isn't nearly as impressive for web development as it is when you use Smarty. .NET just looks like another big library of functions until you get your head around the CodeBehind architecture. I suspect RoR is very much the same; there is something "to get" that is hard to describe and not really easily described.

Agent Smith: "If this is not attacking Rails, I don't know what it is. :-)"

I agree, you don't.

Robby Slaughter: "For example, PHP alone isn't nearly as impressive for web development as it is when you use Smarty."

Actually, Smarty is a good example how *not* to do things in PHP. It has its own interpreted template language, implemented in another interpreted template language, and there is nothing Smarty can do that PHP cannot by itself.

The biggest issue I have with RoR is that it doesn't seem (according to their site) to translate to mod_ruby that well.

http://wiki.rubyonrails.com/rails/pages/mod_ruby/versions/1

(I'm not sure what reducing the safety level to zero means, but I don't like the sound of it. And what do they mean by "one application"? The equivalent of a single cgi script?)

If you're going to build a site that you think will have an appreciable amount of traffic, and run cgi's in an interpreted language, you definitely want the possibility, long term, to stop the host from having to recompile every request. Maybe there are other ways to achieve this with RoR that I have missed?

revert,

Safe Level 0 in Ruby is no "sandbox" during the script execution. For example, Level 0 means that the external (to the script) Strings aren't protected against dangerous  evaluations (runtime execution of code in the String); also, the Script can access external files freely. It's not really a problem if you use Standard Rails the way it should be used or if you know what you are doing. :-)

About the mod_ruby, the issue is that mod_ruby loads one Ruby interpreter which can get messed up by more than one application. In a shared environment a user could try to mess up with the application of another one. Also maybe two instances of Rails could be problematic. Hence the advice to use only one instance of Rails with mod_ruby.

Rails works with FastCGI and WEBrick too. FastCGI is the recommended approach for high performance. WEBrick is generally used for development, but it could be used through a proxy from Apache or Lighttpd. I'm not sure about it, but maybe several instances of WEBrick+Rails could be used for load balancing and redundancy from the main HTTP server.

Thanks Mr Smith. I didn't realise that FastCGI actually enabled you to handle multiple requests in one process. I'm glad to be made more aware of it.

The goodness of FastCGI is that it allows many processes of Ruby to handle the load. Some setups of Rails may create up to 20 instances of Ruby this way.

Ruby generally isn't good in a multithreaded setup, hence the need for more processes.

Ruby 2.0 is scheduled to have native threads and a bytecode virtual machine, becoming a little closer in functionality to Java and Python.

Garret Dimon, an experienced .NET developer, explains why he loves Ruby On Rails:

http://www.garrettdimon.com/archives/why-i-love-ruby-on-rails

What makes Rails so special is the results.

Another experience here:

"I finally got to sit down and take a look at Carol's Rails application. It was written by Todd in his spare time after my visit back in July. Until that moment I fully expected to be helping them with some experimental code. To my joy and amazement, it's actually a good-looking time and project tracking application that they deployed internally and have been using to generate reports back to Accounting at HQ. It's also one of the larger, more complex Rails apps that I've seen.

I was stunned for a minute, but Carol and I went ahead and paired to fix the issue. A little refactoring, a little explanation... Result: less than 10 minutes to figure out and fix the problem."

http://www.jroller.com/page/obie/?anchor=rails_rails_rails_rails

It's like the difference between a regular MP3 player and an Ipod.  Very obvious when you use it, but difficult to quantify and explain to others.

Form over function?

You cannot change the battery in an iPod.