Slashdot Mirror
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."
Fact is that Rails template (rhtml files, the views) are scripted directly using Ruby (there is no specific view/template language). This means that they can be abused, not that they should.
When used well, Rails views are actually quite clean due to the high readability of Ruby itself and the ability to rapidly create so-called Helpers (Ruby methods that you can call from your views, to build specific HTML structures from generic datum, since you come from JSP land think Taglibs, but much simpler to define & use)
Seems like DHH found Ruby simple enough to just use it as a templating language (and it works quite well), that's his choice, other frameworks in other languages picked a different one (Python's Django has a template-specific language for example, much simpler and less powerful than full blown Ruby but much less prone to abuse either)
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
As far as I've seen, there isn't that much actually new in RoR. But it's obvious that someone has had a great idea how a whole bunch of known stuff should fit together, in a way that encourages best practices (like a lot of testing, and code reuse). It has near perfect design.
The language Ruby wasn't new; Active Record wasn't new, nor was the idea, but it fits with Ruby really well. MVC was old, but the tiny bits of boilerplate needed makes it look like magic now and then. Everybody knows testing is essential, but I hadn't seen it integrated into a web framework so well before. The idea of "sensible defaults" can't have been new, but the switch from reams of XML (in Java web programming) to near invisible config is great. The object-oriented Javascript libraries it uses weren't new, nor are template languages, but the way in which they're added together is pretty seamless. Et cetera.
No wonder every web programming language community out there is rushing to put together it's own version of Rails... but the libraries don't always fit together as seamlessly. I think that Hansson's main achievements are recognizing that all the known best practices can be put together really well, and that Ruby and its libraries were a great fit for that.
I believe posters are recognized by their sig. So I made one.
(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:
The opposing reasons:
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.
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.
[Everyone gasps.]
Hermes: No!
Fry: Ah, so the real gift Spargle gave you was confidence. The confidence to be your best.
Farnsworth: Yes, ordinary water.... Laced with nothing more than a few spoonfuls of LSD.
Shop as usual. And avoid panic buying.
1. It's easy to build hash tables in Ruby- At any level of a hierarchical structure like HTML you can have an arbitrary number of child elements or attributes, all identified by a type tag. This happens to map perfectly onto ruby's hash tables, so to create an HTML link you can say:
:id => 'add user', :class => 'shiny button', :action => 'add_user'
link_to
2. Lack of superfluous syntax It is very elegant how every programming idea in ruby seems to require only a single syntax concept at a single location to put it into practice- For instance, if you need a class member variable, you just create a name starting with "@" (like @firstname) without having to declare the variable in a separate location in the file. This is taken advantage of very cleanly by the ROR system, so that programming web pages has a very "WYSIWYG-ish" feel- Every concept in you web site has a clear, understandable equivalent embodiment in the Ruby code
3. Dynamically detects missing methods- I don't know exactly how it works, but ruby classes are able to know when a method on an object is called at runtime that doesn't exist- So you can essentially enhance the functions an object supports at runtime... this allows Ruby toolkits, such as Rails, to essentially shoehorn their own custom language ideas into ruby (not quite at the level of Lisp's "defmacro", of course)
4. It was scalable from day one- Right from the start, ROR was designed to scale- In fact, it was already part of a commercial app before it even existed as a stand-alone product. This means it already overcame the greatest hurdle of any web-development framework from day one- Most Scheme/Lisp frameworks, for instance, still haven't achieved the level of scalabilty that ROR had right from the start.
5. It has a whiff of that mystical Scandinavian software guru-ism in it that make for seriously powerful software Creating a comprehensive web development system is a messy undertaking- ROR is the product of an obsessive Northern European fanaticism that somehow manages to combine an incredible pragmaticism and also manages to handle all of the many ways that web frameworks fail with the utmost of effectiveness. It isn't brilliant because it makes it easier to do complex things, as other frameworks try to- It's brilliant because it makes things that are already easy so much easier that all the complexity, though still complex, floats to the surface of your code and isn't obscured by the many "easy" parts.
6. No pre-processor Many of the more advanced web-frameworks, as in JAVA, require pre-processing of HTML templates with embedded JAVA- The dynamicity of Ruby makes this step hidden- Explicit preprocessors are practically and cognitively difficult for programmers to deal with.
These, I think, are some of the non-obvious reasons that give ROR the edge over other web frameworks.
Nice comment. Too bad its stolen verbatim from the article AND the summary.
So, for now, it's Java or Python, and associated frameworks for me. But not RoR.
Actually, I think the vast majority of developers out there are far more interested in getting their damn job done, and couldn't care less if Sun GPL'd the Java sources. 'course, you'll never hear that because they're too busy *getting their damn job done*, instead of bitching about licenses on Slashdot.
RoR is a good OS product that helps people solve problems that really bug them. It doesn't - contrary to lot's of other OSS projects - have a website that looks and works like crap . It's lead developers actually have social skills (and running businesses) and can talk coherently in a way that normal people actually understand them. They are tight with the blogging community and are smart enough not to be arrogant and thus convince even the most fanatic Java people to check out their toy. They started the whole webcast thing and built RoR for an actual real life business project they wanted to do (www.basecamphq.com) before going OSS.
Technology wise there is not that much new. Zope is still lightyears ahead of everything else (including RoR) but only last year did their website stop looking and acting like a total pile of doo-doo. Yet still Zope.org's Navigation is somewhat '99ish and much more intimidating and overwelming than the friendly and straightforward RoR Site.
Then there's Django. Which is very neat, partly even better than RoR (and friends with the RoR project), but went OSS a little later than RoR and thus needs to catch up on awareness a little. Symfony is PHPs late answer to the RoR induced MVC frenzy and still to new to gain awareness momentum. CakePHP and P4A seem ok but don't have the marketing stance to be of any significance anytime in the future. They're both so nineties it hurts and thus will wither and die.
Bottom line: RoR are a OSS project that isn't just good at coding or using exotic technologies, they actually have the skill to market it aswell. And they were the first in the framework camp. It's that simple.
We suffer more in our imagination than in reality. - Seneca
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.
.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.
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.
Regards,
Ross