Ruby On Rails Rules The Universe

One of the ChangesSinceWikiFellOffTheScope is RubyOnRailsRulesTheUniverse now. Well, okay, maybe if you're working some place that has nothing whatsoever to do with the web, you may have escaped. Otherwise if you're not working with or influenced by RubyOnRails, you oughta watch out for that chugging noise coming up behind you real fast ...

If WardsWiki hadn't been in the doldrums this might have made a fine place to talk about things like:

Oh, gosh. Frankly, I'm glad WardsWiki has not gotten run over by RailsWeenie?s. I encounter enough in the wild, and I receive enough "Dear Sir: We have opportunities for Rails developers!" messages. "Dear Sir" my foot. Last time I checked I was a gal.

Indeed. If anything, the most significant thing about Rails isn't the annoyingly breathless non-objective Rails hype, Rails itself, or even RubyLanguage -- it's the influence of Rails on the enhancement of other WebDevelopment environments and on Web programming style; in particular, the value of the ModelViewController pattern.

Yes, something like that. I ran across this fascinating article last week: "7 Reasons I Switched Back to PHP After 2 Years on Rails" (http://rubyurl.com/E94). Derek Sivers of CDBaby.com hired one of the core Rails developers to convert its system from PhpLanguage & StructuredQueryLanguage to RubyOnRails. Well, after 2 years of this other guy's hacking away making little progress, Sivers decided to toss out Rails and rewrite his existing mess of PHP.

Sivers says, "I threw away 2 years of Rails code, and opened a new empty Subversion repository. Then in a mere TWO MONTHS, by myself, not even telling anyone I was doing this, using nothing but vi [ViEditor], and no frameworks, I rewrote CD Baby from scratch in PHP. Done! Launched! And it works amazingly well. It’s the most beautiful PHP I’ve ever written, all wonderfully MVC [ModelViewController] and DRY [DontRepeatYourself], and and I owe it all to Rails."

The point is, Rails taught Sivers a clean architecture... which can be implemented in other languages... which doesn't require a spiffy framework (that locks you in).

Sivers's particular problem there was BigRequirementsUpFront - 2 years of fun with a new platform, but without FrequentReleases. Any project would have gotten in trouble, while laying the groundwork for a successful rewrite. See http://www.oreillynet.com/onlamp/blog/2007/09/big_requirements_up_front.html

That assessment appears to be speculation. There is nothing in Sivers' article that says he did BigRequirementsUpFront. It's entirely possible that FrequentReleases were done internally. And, of course, there are plenty of projects that succeed despite BigRequirementsUpFront. The reasons for failure were quite clearly delineated: RubyOnRails needed to be heavily modified to suit the requirements (multi-lingual, and integrated with an existing database); technical emergencies drew the developer away from the new project; and the RubyOnRails philosphy (SQL deprecated) was contrary to the primary stakeholder's philosophy (SQL promoted). The point of the article was not to level a criticism at RubyOnRails; indeed, RubyOnRails was the inspiration for the good qualities of the PHP implementation. What we learn from this is that Ruby and Rails are not special. There's certainly no innovation in Ruby or Rails at a theoretical level -- RoR is simply a good framework on top of a rather nice language. What is important is that good Web software is possible -- and can be developed relatively quickly -- without frameworks (frameworks == YAGNI?), Ruby, or Rails.

Read my paper. It speculates that BRUF _happened_, entirely by accident. And Sivers _states_ that FrequentReleases was _not_ followed - meaning releases all the way to production. Danger, Will Robinson!

I think you over-estimate the significance of both BRUF and the failure of Sivers' project. Sivers clearly states why the project failed. However, why the project failed wasn't the point. It could have failed because someone hung the office pictures crooked on the walls, for all that it matters to the point of the article. Again, the point we can take from the article is that good Web software is possible -- and can be developed relatively quickly -- without frameworks, Ruby, or Rails. Thus, RoR may be interesting to its adherents, but it is of no broader interest than that.

[Slightly related: RailsVsPhp]

Postscript to the Sivers/CDBaby fiasco (which, when you read Sivers' original article, clearly had very little to do with Rails): DerekSivers? is now (December 2010) once again using Rails and wrote the foreword to MichaelHartl?'s excellent http://www.railstutorial.org. So who has the last laugh? :) --MarnenLaibowKoser

I think what should be done is to identify and document "WebFrameworkPatterns?" rather than focus on specific brands. For example, document the different ways to deal with RDBMS and SQL, screen form generation, reporting techniques (such as QueryByExample), validation, content managment, etc. Unless there is something truly magical about Ruby or insert-your-fav-language/framework-here, these ideas should be implementable in other languages, hopefully in a mix-and-match style such that one does not have to buy into a full package to use just some of it.

As CTO at a previous startup, I had the chance for a direct comparison of Ruby and Java. For several reasons, we built a web product in Java first and released it. Eventually, our reasons for staying Java went away, and I tried an experiment. My team volunteered to rewrite everything in Ruby while maintaining the Java site. There were no changes to the model, and the feature set was the same. In fact, the Ruby version ended up with a few additional features, but my rule was a direct port to start with. Some things we found:

Since we used Scrum to track projects, it was pretty easy to compare our velocities. After a couple of sprints, the dev team's velocity improved by close to 40%. I expected some gains, but close to 40% was beyond expectations.

If you have a well-architected web application, I see no reason not to use Ruby. You may need a few more CPUs to scale well, but that cost is nothing compared to the development savings. The key is "well- architected." You can develop junk in any language or framework.

But Java is known to be bloated no matter what you compare it to. It's as if Sun gets paid per lines-of-code. JavaIsTheNewCobol, and is verbose like COBOL.

Is Java really bloated? or it is more like J2EE is bloated? or even the JDK? or a particular framework? Rails seams great, but I wouldn't say that is better than JbossSeam... or WebObjects... why do we keep blaming the language for the sins of the some of the frameworks built on top of it? BlameTheFrameworkNotTheLanguage

One thing about Rails which really bugs me is, some people are so psyched up about it that they're dying to use Rails for something which it's totally inappropriate for.

I'm in an ExtremeProgramming hobby group (XpNewYorkCity) which is developing a desktop app in RubyLanguage. The app looks for duplicate files on your computer (and in a couple weeks, we should have it looking for partial duplication). Just to make sure you're clear on this (duh), the app crawls your local file system and reads your files. Got it?

Well, we have a new gal in our group who has just started to learn Ruby. So far, her Ruby nuby skills consist of calling an object's "to_s" method. Okay, fine. But now that she's learning Ruby, she's dying to do our dupe detector app in Rails. "Wouldn't it be great if this were a RubyOnRails web app!" she carried on awhile. One of our guys looked her right in the face and said, "This is a desktop app. When a web app accesses the local file system, that's normally considered a security flaw. This is a desktop app." To which she replied, "But I think it needs to be a web app that reads your files so we can use Rails!"

Sigh.

In fact, a lot of the newer people who discover we're doing a Ruby project wonder why we didn't come up with a project that involves Rails. Or they wonder why we aren't using a different language, such as PythonLanguage or JavaLanguage, because Rails is inappropriate for our project. As if there's no point in learning/using RubyLanguage unless you're going to learn/use RubyOnRails.

Sigh.

-- ElizabethWiethoff

Unleash her enthusiasm on any of Ruby's fine desktop GUI offerings, from hoary RubyTk to newfangled RubyShoes...

Once we factor in the partial dupe code mentioned above, we'll be creating JavaSwing in JayRuby. Swing might be old and hoary, but at least JRuby is a new fad and I'm not aware of anyone (but myself) doing both. So we might be cutting edge there. At least one of the Artima.com guys says, "Very cool, Elizabeth," about the combination. Cooler still would be ScalaLanguage with Swing. I think I'll have us dump Ruby and switch to Scala just because I want to learn Scala. (kidding) No, on second thought, we should use compiled Scala for the search algorithms and JRuby to control the Swing. There. That would be cool. And not absurd. -- Eliz

Alternatives to R&R

(Borrowed from http://developers.slashdot.org/article.pl?sid=08/06/01/2247232)

RubyOnRails is so out of fashion. Case in point: RubyOnRailsForDummies? ISBN 0470081201

27 Jan 2009: I believe Rails enthusiasm settled down since Zed Shaw posted his "Rails Is a Ghetto" rant at the end of 2007.

Here is a very general summary of the primary criticisms about Rails I've encountered over the years:

It seems optimized for producing lots of simple-to-medium-complexity websites in a short amount of time. Thus, if you are primarily a web-development shop (website sweat-shop) that must produce many sites for many "typical" customers as quickly and cheaply as possible, R&R may be just the tool (as long as you use something else for the outlier projects). The high volume allows one to compensate for the long learning curve. KnowTheToolsNiche.

-top

It would be interesting to know when TopMind posted that. As of December 2010 (current Rails version 3.0, with many people still on 2.3), none of those criticisms is particularly accurate when applied to the Rails framework. There are lots of bad Rails developers who don't know anything beyond generated CRUD and can't write a decent SQL query (perhaps attracted by the hype), but the framework, in the hands of someone with a clue, is excellent. (Part of the reason is the RubyLanguage itself.) --MarnenLaibowKoser

That's certainly true. Likewise, any tool in the hands of unskilled practitioners will be ineffective. What I'm getting at is that the criticisms of Rails you posted are apparently based on the misperceptions of unskilled practitioners (or non-practitioners, for all I know) -- they're not even applicable to the current state of the framework. At this point, I think they start moving over into the category of FUD rather than being valid, considered objections. --MarnenLaibowKoser

If RubyOnRails rules the universe, then why has it been so difficult to find serious work with it? (By serious, I mean with disciplined developers in non-fly-by-night orgs for decent money.) I don't care if it is or isn't the best framework or lang combination - just wanted a quiet life having fun trying to help people by developing software - PissedOffOfTunbridgewells?

You should of learned PhpLanguage

{You should have learned proper grammar.}

You should nevar assume a computer programmer's mistakes in human language aren't intentional.

{And you should never assume a computer scientist's admonishments don't fully recognise that.}

OctoberZeroSeven FebruaryZeroEight

CategoryFramework, CategoryWebDesign CategoryRuby

EditText of this page (last edited September 6, 2013) or FindPage with title or text search