What's the Secret Sauce in Ruby on Rails?

An anonymous reader writes "Ruby on Rails seems to be a lightning rod for controversy. At the heart of most of the controversy lies amazing productivity claims. Rails isn't a better hammer; it's a different kind of tool. This article explores the compromises and design decisions that went into making Rails so productive within its niche."

Comments

That or TurboGears.

[cduffy]

(Django has been in use on high-volume production websites longer than Rails has existed, incidentally -- something which might be worthwhile when bringing it up in this kind of context).

After evaluating Rails and Django, my company ended up going with TurboGears for some of our toolage (our main product is a Java Servlet-based application, and that's not changing). The reasons:

• Rails and Django are very tightly integrated -- whereas with TurboGears the toolkit is loose enough that one can easily pull just one piece out for a project which doesn't need the framework as a whole. Our department does a lot of small and varied projects (many of which aren't webapps but which still could use an XML-based template engine or a simple OR mapper or a simple servlet-like API for handling requests independent of any content generation), so this was important to us.
• We have more people in-house who know Python than Ruby.
• TurboGears appears to be under more active development than Django.

The opposing reasons:

• Django and Rails have more high-volume production sites using them.
• The OR mapper used by TurboGears, SQLObject, lacks some functionality and useful design attributes provided by others. This doesn't impact us for our little in-house projects, and is less relevant now that TurboGears 0.9 is adding support for using SQLAlchemy as an alternative to SQLObject.

Anyhow -- Rails is nifty. Django is nifty. TurboGears is nifty. Quite likely all three of them have a place; I'd just like to urge people not to get so caught up in the hype over Rails that they forego evaluating other options.

Rabid IP Hoarders and their Sauces

[nead]

It really is tiresome to see people constantly ask "what's the special sauce" when in many instances it is clearly "nothing".

Sometimes good people use good methods to build well conceived applications that work precisely as their audience expects they should. Because these well-formed applications do not fail randomly, scale well and are easily supported marketing and business types presume that there absolutely must be something patentable in the mix.

One of the reasons I loath the term "Web 2.0" is because people presume there is some new wave of innovation occuring in application development when every Slashdot reader know's this isn't true.

Technologies mature, standards mature and hopefully people mature. The result is better software, not an abundance of new and novel special sauces.

Re:Relentlessly applying best practices

[I Like Pudding]

AJAX is based on technologies with extremely poor design and implementation, such as browsers, JavaScript, and HTML (poorly designed for this application, perfectly ok for marking up documents)

The only part of that I'll give you is the poor IE implementation of CSS. Browsers' main problem lies in their non-compliance with standards. Solution: test in multiple browsers. WOW, THAT WAS HARD. Next up: JavaScript. Poor design? I was shocked at how powerful the language is when I finally started digging into it after years of avoidance. Poor imlpementation? Not really - just many different implementations. Of course, this can and has already been worked around with libs that abstract the differences away for you. HTML? It still is used as a basic markup language, with all the heavy lifting being pushed into the CSS. Now, CSS is nowhere near perfect, but it does function admirably in the scope of AJAX (when not using IE's broken ass implementation).

Rails takes lessons learned from a decade of server-side Web development, as well as the catastrophe that has become J2EE through over-engineering, and simplifies it to the essential mechanisms.

I half-agree. You imply a minimalism that isn't present. The framework is quite complicated in places and does a lot of tricky things. You see, programming with just the essential mechanisms sucks; you've gone back to CGI.pm. What Rails does is provide a massive lever with which to move your problem. The Actual Work Done Per Line of Code metric exceeds any other framework I have used before. Code efficiency is the watchword, not simplicity.

Built on top of Ruby, which is itself a pretty thin simplification wrapper over C++,

No it isn't. Ruby's implementation is a big, slow VM that doesn't act much like C++ at all. Really, the poor performance is the only thing I dont like about the language.

it combines the simplification of Web site development best practices (MVC, proper tiers, etc.) with the power of an high level development language overlaid directly on top of a low level near-assembly language, with the ability to perforate the abstraction layer (first through modifying Rails source in Ruby, then through C extensions) if needed for performance or other reasons.

That sounds like marketroid speak, and is about 3/4ths BS. Perforate the abstraction layer? Jesus. And just who is running around writing C++ extensions for web apps? Almost nobody. Takes too damn long, and isn't as safe as running through the VM.

Short, brutal version: AJAX built on crap by script kiddies, Rails on bedrock by software engineers.

DHH is something closer to a hacker, not to mention the fact that rails utilizes AJAX and, more generally, javascript all over the place. Does that make AJAX apps built on top Rails rock? Or does all that terrible, awful AJAX stuff diminish Rails? Maybe they, I don't know, utilise the same foundation technologies and standards and complement each other quite nicely? Maybe you are an idiot?

Re:It's multiparadigm.

[rossifer]

In fact, every time I look at Ruby, all I see is a pale reflection of Smalltalk. I've yet to see anything new it brings to the table.

Deliverable packaging. Extracting a Smalltalk program from the development environment for distribution is, to be generous, annoying. Which is one of the reasons why Smalltalk works so well in an academic environment, but never caught on for commercial work. Ruby, on the other hand, is about as tough for someone else to deploy as Perl (it isn't).

This is one of the places where Java really changed things and is IMHO, the big reason for why Java has become so popular. .jar files (and the variations on that theme: .war, .ear, etc.) can package up lots of different things, and as long as people know what VM version to run it on, they're good.

Regards,
Ross