Why Ruby on Rails won't become mainstream http://beust.com/weblog/archives/000382.html Kind of interesting, but didn't convince me. Though, yeah, I can imagine a lot of naive programmers sticking with PHP and VB (the type of crowd that also doesn't run their own servers, so they're dependent on hosts offering Rails for them). Rails DOES have an IDE - soon to be two, and there are many other alternatives. The JUnit comparison is kind of worrisome, but I think there's competition from frameworks like Django. Joe
on 2006-04-07 13:14
on 2006-04-07 13:45
I don't think the JUnit comparison holds much weight at all. I'll admit that I'm not entirely aware of community when JUnit first came out, but I'm willing to bet the majority of users were developers already committed to Java that were pleased to find a usable testing framework. Compare this to ROR users, who are developers that are looking for a better way to write webapps. When it doesn't apply well to a given situation, we'll be more willing and able to seek out better solutions. When those better solutions don't exist, we'll be better equipped to roll our own. Rails is not in the same boat as JUnit, simply because the users' mentalities are so different. Perhaps Cedric is right though - perhaps Rails will never make the mainstream, if by mainstream we mean adopted by ISPs and "enterprise" users. Who cares? I'm not writing basic scripts that I intend to offer to thousands of people, so I don't need ISPs to support it. I certainly don't need the software community approval to write apps in Rails. I might be wrong, but I have a feeling that Dave would take a Get Real approach to the "Rails will never..." arguments: "It just doesn't matter." Pat
on 2006-04-07 14:06
> "It just doesn't matter." I will have to agree. It should not matter to us (Rails fans). One very good and important point in that article is that Rails offers the biggest advantage when you're a *talented* developer. I don't know if you guys will agree, but I don't believe Rails is "easy"; it does assume you know about about most of the design patterns popular in web development. I gave up trying to convince my peers to use Rails when I realized that a lot of them simply didn't know about or at least recognize the usefulness of things like MVC, automated testing, or even just an ORM layer like ActiveRecord. PHP is popular not because it's better than Rails or any other specific development platform, but because it lets you type <?= print "hello world" ?> without requiring you to set up configuration files or write unit tests. PHP allows you to be stupid. The most successful PHP application out there -- a certain very popular weblog engine -- happily ignores all the things most of us learned over the last couple of years, and even goes as far as using globals inside functions, and similar atrocities. It's constantly broken, but the developers patch things up fast, and things keep moving, somehow. Voodoo programming. Many of the plugins available for said weblog application were developed by designer types who had never before developed any kind of software. Maybe that is PHP's single biggest strength; it lets you get started cheap and hack things together that, more often than not, work. Without thinking too much about what the heck you're doing. So maybe it's only the 5% of us who know their MVC and ORM and TDD and WTF who can really see the beauty of Rails. How should it ever become mainstream? And who would want it to? - Hendrik -- http://www.mans.de
on 2006-04-07 14:34
I read this a bit ago, and while I don't think his points are far off I think the title might better be "Why Ruby on Rails isn't Mainstream Now". Almost all characteristics he has issues with have been seen in every other platform that today is "common" or "established". Considering that Rails has really only hit the mainstream (and 1.0 release) in the past YEAR, these kinds of arguments don't hold a lot of water. ...this coming from a Java and JRuby developer, too.
on 2006-04-07 14:34
"It just doesn't matter" I for one, really don't give two shits if Ruby or Rails goes mainstream or enterprise, as I have absolutely no desire to build something in these arenas. Mainstream or enterprise is a euphemism for "really crappy, mediocre stuff masquerading as important." Ruby and Rails are not about being easy and as such they really aren't. You have to be willing to get up off of you fat ass and do something towards advancing your learning if you want to be good at this stuff it takes a lot of effort, maybe even more effort than what can reasonably be expected of your average Joe IT department worker bee. At a party surrounded by PHP and Java community I'll make a show of being a proponent of Rails going mainsteam and do my best as a fanboy to get defensive when they beat dead horses again like scalability, but secretly I have more to gain if Rails doesn't go mainstream, it helps separate the wheat from the chaff, I charge a premium for quality. Mainstream comes with a lot of baggage. Ruby and Rails are the new hot chicks in the room, and don't be surprised if yesterday's news doesn't like all the attention they get. Tim C. firstname.lastname@example.org
on 2006-04-07 20:08
One point of his that I sort of agree with is that rails may be so popular that it snuffs out interesting projects like Nitro/Og, camping, etc. I really hope that the legions of aspiring new Rubyists attracted by the bright lights of rails will discover and help improve these other options. It would also be really interesting to try porting Og into rails! b
on 2006-04-22 23:46
Joe wrote: > Why Ruby on Rails won't become mainstream > > http://beust.com/weblog/archives/000382.html * First of all, Ruby "But it's a complex language that contains a lot of advanced idioms which will be very hard for PHP and Visual Basic programmers to absorb." :: shrug :: I routinely see people trying to nail 2x4s together with Hickory Farms Smoked Sausages. I don't mind, I eventually get their business (or someone else talented does). * Ruby on Rails itself "Ruby on Rails is just too advanced. I'm serious. It has an incredible amount of slick features involving a lot of magic (both Ruby-related and invented by David himself)." Meh. DHH, unlike David Copperfield, allows you to get at the underpinnings of the magic. I don't care about the *core* of the magic. I admit I'm curious, but I really don't care how everything is routed, etc, as long as it follows my directions. One day I'll probably download the source code and take a look at some of it (go ahead and do that with PHP, or VB.NET--we'll see you in a couple of weeks in the case of PHP, and we all know what we'd see for the latter case). As far as the app itself goes, my pattern is to run a generate scaffold command on everything... Hey look! The magic is gone... :: shrug :: * Still no credible IDE. :: blink :: I've been coding Java, PHP, and RoR code in the same editor along with my source code repository (both CVS and SVN) integration, and database stuff. It's called Eclipse... Use it. You'll thank yourself for it and want to hunt down the developers in the afterlife so you can buy them a drink. Eclipse works on all major platforms I can think of, apparently there are some issues with RadRails and OS X (which makes me sad because I'm wanting to switch). But it looks like there is a good alternative on that platform too. Hell RadRails even makes it easier to manage your "WEBrick" servers and use code generators. You get terminal output right in the damn IDE! Bah! Humbug on this point. * Fanaticism Yes, be nice, don't *always* insult the narrow-minded. :: cough :: RoR is not itself a holy grail in an "enterprise" sense. In combination with core Ruby, it may be. There's nothing preventing you from doing some complex stuff on an application server level with J2EE, C, C++, C# or anything else and integrating it with RoR. All you have to do is write to a database...you *do* have a database server, right? JBoss Application Server - processes incoming files with a timed MBean - generates reports (using OpenOffice UNO -- xls, doc, pdf, ...) - drops complex detail and summary information into database - drops rows into a database notifying users of the results RoR Front End - makes it all pretty I expect the initial part could be developed in pure Ruby, but I have no experience with it. I *do* have experience with Java, C??, and such. It would be *easily* done and very powerful. I want to gut the core of one of our major J2EE apps and refactor it to use this methodology. It would be much faster overall and easier to maintain. * Crowd of a single mind "For all the flak that Java receives because you can count at least a dozen different Web frameworks, there is something to be said about plurality and the constant chase for something better and different." Yup. A lot of lost time, revenue, and a ton of Google AdSense accounting from all the web searches trying to figure out what the hell is wrong with said framework and which framework would be a better idea to switch to. It's true that questioning and innovation are great, indeed neccessary. But I don't need 12 frameworks. I need something that justworks. Time is money. Fast development means I can spend more time doing other things. Although it is fun to develop in RoR. :) I think DHH has laid the groundwork for innovation. I don't think that will end... * Enterprise capabilities and scalability unclear. Bah. Java 1 was slower than molasses in an antarctic blizzard. It's now dubbed as the #1 enterprise language (by most people that aren't in the Microsoft camp). I wouldn't code everything for an enterprise app in RoR. I would code the web interface in RoR. Everything else would be provided via backend apps (Java, Ruby, whatever...see above) or available via Web Services (utilizing the same backend stuff). All you need is data in the database for RoR to get it. You can get it there quickly by about three hundred eight different methods. Again, pick up your Sausages everyone, we have ten houses to build and each one of them is completely different! But that doesn't matter, if the sausage fails at least you have lunch...while you try to find a slightly different-looking sausage that will work better! :: shrug :: * Lack of support from Internet Providers Somewhat valid. However, this is where consultants can help. There are plenty of RoR compatible ISPs. This is something you ask your client up front. "Well, we use a different technology that allows us to develop applications in about a fifth of the time as a standard web application. It may require you to switch hosting servers; we would be happy to help you with the details of that adjustment. Yes, it will probably cost you about two more dollars per month. Yes, about twenty to thirty dollars per year. Oh, did we mention that you'll probably make about a hundred times more back by not paying us for the extra 4/5s of the development time?" Yes, you can't download a CMS and install it on any old web server (not that that is exactly easy anymore either...and many CMS packages have shut down servers therefore suspending hosting accounts). So if you want to do that, I guess RoR isn't for you. But those clients hunt for developers in the $0-100 range anyway. I'm well beyond that range. :) Smart people pay a premium for good software. And they are rewarded for it. My Summmary: I think that RoR "replacing" PHP in the "mainstream" does boil down to ISP support and integration on a more wide-scale basis. That's not exactly RoR's target market though. I see it much more likely to replace JSP and PHP front-ends in "enterprise" development. And the mid-level of client-based web apps. I've helped a few friends get a PHP fansite or something up... It would be just as easy to help them get a RoR one up.
on 2006-04-23 05:23
Hendrik M. wrote: > One very good and important point in that article is that Rails offers > the biggest advantage when you're a *talented* developer. I don't know > if you guys will agree, but I don't believe Rails is "easy"; it does > assume you know about about most of the design patterns popular in web > development. I gave up trying to convince my peers to use Rails when I > realized that a lot of them simply didn't know about or at least > recognize the usefulness of things like MVC, automated testing, or > even just an ORM layer like ActiveRecord. I have a bit more input on this point... My background is in hardware design, signal processing, some coding theory. I decided I needed to develop a web-based application after realizing I needed a *database* application. I hadn't done anything with web-based programming since circa 1994 when Perl was on top. I started reading a book on PHP and MySQL and quickly came to a *lot* of nice realizations. I had read about this Rails thing and decided since I was a newbie I might give it a shot. I quickly realized that I could develop 10x faster than I could under the PHP stuff I had been working with. (caveat: I learned about the availability of frameworks *after* moving to Rails, so I don't quite know how using PHP frameworks would have affected me) I leared a lot about web development from my into to Rails. So I wouldn't say that only experienced *web developers* "get it". I would, however, agree that the Rails advantage is best understood by those that have been burned by particular "not best practices" in the software world. I'm not a software pro, but I wouldn't put myself at the top of the pack. Just another datapoint. Jake
on 2006-04-23 05:59
Really, folks, if it becomes mainstream, then we lose a good deal of competitive advantage. I dread the day when RoR becomes common enough that everyone is doing web apps the smart way. After that, I can't claim 10x faster development, can I?