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: * TestDrivenRails * DistributedRailsDevelopments * EnterpriseRailsProjects * RailsFilesystem * ... ---- 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. * HypeStorm: The marketing buzzword sharks smell blood and go in for the kill. ''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: * The Ruby code base was about 2/5 the size of the Java code base. * We built it 5x faster. This one isn't fair though because I had a hard rule that no feature changes could be made. The goal was that the end-user had no idea anything changed. * The dev team was a whole lot happier not dealing with all the extra "stuff" you have to deal with in a Java, Hibernate, and Spring app. * What a surprise. Ruby executes a whole lot slower than Java. 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) * CakePHP [http://cakephp.org] Framework (supports PHP5 & PHP4), Version 1.2 Stable due any time soon. * Symfony [http://symfony-project.org]. PHP 5 Meta Framework using Propel and other layer components. The accompaning book (free PDF, buyable dead-tree) is a very good documentation. * Prado [http://pradosoft.com]. Event-Oriented PHP 5 Framework. Very interesting. * Code Igniter [http://codeigniter.com]. Lightweight PHP Framework for smaller stuff. Neat website. * DjangoProject [http://djangoproject.com]. PythonLanguage Framework. * TurboGears [http://turbogears.org]. Python Meta Framework using some 3rd Party stuff like Templating layers and such. * ZopeApplicationServer [http://zope.org] Web Application Server. To date unmatched. What Rails wants to be when it grows up. * Merb (MongrelEeRuby) - all that RubyLanguage and eRB (EeRuby) goodness left in, all of RoR's opinions which are incorrect taken out, and everything is optional. ModelViewController and ActiveRecord if you want them. * MerbAndRailsMerge (December 2008) ---- 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: * Doesn't scale well in CrudScreen complexity outside of existing defaults and conventions * Can be difficult to set up and configure R&R web-server * Doesn't scale well in performance for high-traffic sites * Anti-SQL: Tries too hard to hide SQL (which may be part of the reason for the above criticism) * Fairly high learning curve, partly because of poor existing documentation * When things go wrong, it can be hard to track down the cause. 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 * ''Almost any tool in the hands of the most skilled practitioners of the tool will generally be quite effective. There are some fast and furious COBOLers out there, for example. Thus, I don't necessarily disagree with your statement, but do otherwise consider it a UselessTruth, as far as comparing tools.'' -t : 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 * ''Neither position is scientifically testable at this stage. Anecdotes are about the best we have right now. The default is not that Rails is objectively better or worse. Is your position that nobody say anything about Rails until the point they can present an OfficialCertifiedDoubleBlindPeerReviewedPublishedStudy? Otherwise, I don't understand exactly what your complaint is.'' * Also, sometimes something that works very well in ideal conditions may not under "junky" conditions. The AK47 is prime example: not the most accurate, but when kicked around and dirtied up from war and use, is far more reliable than "precision manufactured" weapons. And it's easy to train on. ---- 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