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."
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
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.
No, it really doesn't, and to claim it does is to ignore the wide range of uses of object persistence. What it has is a great design for getting web interfaces up and running quickly on databases. It has a very poor design for long-term maintenance and growth of applications.
The ActiveRecord pattern is of limited use, especially as implemented in Rails. Your code is not isolated from major changes in the schema, and the dynamic nature of Ruby means that the consequences of such changes can't be tracked by compilation or refactoring tools; especially as the model classes don't even exist as code. Tests are a good way to help with this, but try and design tests to deal with potential schema changes for a large application that may have transactions involving thousands of records...
To see what a good persistence system should be like, take a look at Kodo or Xcalia - very high performance persistence system that allow exactly the same code and queries (which are automatically highly optimised for the particular database - not some minimal portable subset of SQL as in Rails) to be run on small embedded databases and high-end clustered systems. Unlike Rails, these systems can handle transactions of hundreds of thousands of records (something that is not that uncommon for commercial work) without thrashing disk or memory. You can also use the same code to persist and read to XML, LDAP and many other types of store. And yes, these systems also have 'convention over configuration' like Rails - they got there first, and had it years before RoR.
RoR has some great ideas, and definitely has its uses, but to claim it has near perfect design is way out, and sorry, but best practise in data model design in object oriented languages like Ruby does not involve basing things on non-OOP relational tables!
-Dom
Yes as to hype, no as to technical merit.
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). 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. Built on top of Ruby, which is itself a pretty thin simplification wrapper over C++, 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.
Short, brutal version: AJAX built on crap by script kiddies, Rails on bedrock by software engineers.