For all the flak I've fired at the old boys doing J2EE, it at least appears that they got one lesson down that escapes many PHP programmers I've had words with. Ben Curtis demonstrates this disconnect exceedingly well as he labels Rails to be in its infancy:
Finally, there is youth. Rails is still in its infancy. While that’s a great opportunity for getting in there and being able to make contributions to the core product (I have more ideas than I do time), it’s not so great when you have to do deal with significant changes happening to your framework.
This is a charge I would expect to hear from someone flaunting the use of "industry standards", such as Struts on Hibernate or whatever the flavor. But get this, Ben Curtis is comparing Rails to a home-grown soup of hack'a'heel with a dash of ADODB, spiced with some unpolished generators, and then he's "...a little hesitant to use something at version 0.11.1".
Woah?! There's a contradiction if I ever saw one. So Rails is in its infancy with 9 months of rapid improvement by hundreds of contributors, used across hundreds (or thousands?) of applications of various size. But the home-grown dish is the pillar of stability and vintage quality?
Please. Don't be silly now. Your arguments of inertia and a sense of investment might have appeared silly (read up on sunk cost), but at least they were beliveable.
Challenge by Andres on April 15, 16:54
I switched from years of Java development to Rails BUT I almost ignored the framework while looking for alternatives in the dynamic languages world, why?
The version number: 0.1
When I saw 0.10 I thought it was the very first "release" of the framework, thanks to the alignment of the planets and their magnetic fields I digged a little more looking for information and found out that: 0.1 ... 0.9
I wasn't saying my stuff was better, only more familiar and more predictable about how it's going to change (since I'm the only one changing it). In fact, I specifically said my home-grown code wasn't better! That comment came about as I read up on RoR and found a few people saying things like "well, then the new release came out, and now I should really go back and redo such and such". I'm all for improvement, and I know you don't have to tweak your working code every time the underlying framework makes something better, it's just a niggling point at this stage in RoR's development.
So, I hope my comment wasn't taken as a recommendation not to use Rails, as that certainly wasn't the intent. I was just stating some reasons why I haven't switched yet.
Challenge by David on April 15, 17:41
You frequently respond to people's criticism of rails with lame jedi mind tricks like "Woah?! Please. Don't be silly. There's no way Rails could have any problem other than you not liking it. Rails is perfect." You're flaming someone who sounds to me like a Rails supporter. He gives only one reason for not switching to Rails: "[my framwork] works well and Iíve gotten comfortable with it." To a reader who doesn't have a home-grown framework with which he's comfortable, that's an argument to start using Rails! I hate to break it to you, but first of all filling your prose with meaningless loaded statements and attacks is a real turn off and second of all you're wrong about Rails's maturity being a non-issue.
I was playing around with Rails maybe three weeks ago and yes I enjoyed it, yes I woud be interested in using it again, and yes I encountered two bugs in newly-added parts of Rails as well as unexpected behavior by a clever "feature" that can't be turned of all of which were annoying and wasted my time. Although I do commend you for responding in less than 24 hours with "fixed in version control," the bug I hadn't figured out how to fix or workaround myself was actually still there.
So yes, David, Rails is not as mature as older software, in part because patches from two days ago might be in rubygems today. I don't mean that as an insult and I would still be willing to recommend or use Rails for commercial software. I mean that as someone who has seen great potential go down the drain when people get overly defensive and argumentitive.
I think Ben has a valid point and it is a concern all of us weighed when jumping into Rails.
Like the last two commentators noted, I don't think Ben intended to infer that his homegrown framework is somehow better than Rails.
In fact, Ben said "Itís certainly not as polished as RoR".
Rails still has alot of room to grow, which is great, and you guys are improving it daily. I love all this.
However, with such frequent improvements and adjustments, it can leave a developer with a feeling of instability in his own product. When investing our efforts in Rails, we must weigh the fact that we will very likely at some frequency need to adjust significant portions of our application to make use of the latest framework.
I (as I think Ben was saying) do not put forth this fact as a deficiency of Rails. It's simply a factor we all must account for when using your framework, or any framework that is still less than 1.0.
Ben's homemade framework is not as polished as Rails, but he knows its assets and its limitations, he knows whats changed when a revision is made because he implemented the change. An application developed atop his framework is entirely 100% his code. There is comfort in that.
It may be true that some comfort should be sacrificed for the benefits and finesse of Rails. No question there. Fact is though, that is a sacrifice.
We can use for example the development of Backpack. Overall consensus in #rubyonrails and elsewhere is that many of your improvements in 0.11 are a direct result of your experience in developing Backpack. This is great. We love that you put real world experience into rails.
This is also great for you because you know every bit of Rails through and through, you can adjust it to suit your needs.
The downside for the rest of us pedestrians is that we do not have such an easy luxury. We cannot make significant revisions to rails on a whim. We have to code around it, only to adjust our application again when Rails is capable of meeting the need.
This same case can be made with every framework, every library, even every language . However, with Rails still in its infancy, this is the case more frequently than otherwise. So Ben has a point. I don't think it was anything personal.
For me, the bigger feeling of 'risk' when jumping into RoR is not Rails itself, but the underlying stack.
PHP has been around so long and is installed on so many machines by default that it's really a non-issue at this point. Your PHP install will work, and scale. Admins, ISPs, and software distributors know how to set up PHP well.
By comparison, the Ruby->FastCGI->apache/lighttpd stack is very young, not widely understood, and sparsely documented. I think the popularity of Rails is changing that, and quickly, but there's still a ways to go. A major memory leak in the Ruby FCGI bindings was plugged just this month.
I've just built my first largish client app with Rails, and it was a joy to work with. I'm pretty confident that the code I've written is OK, because Rails made it small and simple. I'm pretty confident Rails will do its job. The part I'll lose sleep over is wondering whether or not all of the underlying bits will stay afloat under heavy strain, and whether I've set up and configured FCGI properly.
Perhaps at some point a development process similar to lots of other software, with a 'stable' branch only getting important fixes or updates, and a 'current' branch that is continually released like Rails overall is now would work well?
Similar to Debian Linux, FreeBSD, etc. or as a contentious example, Tomcat (java!)?
I'm finally (after many months observing in the distance) getting my hands dirty with Rails, and it's as fantastic as claimed.
Getting started on top of such a fast-changing codebase is not for the faint of heart, however. The API documentation is good, but many of the 'popular' tutorials don't even work on the current version (for instance, the code in 4 Days on Rails breaks around the beginning of Day 2). Sure, it's possible to figure out for the determined, but it's tough when you're in the 'Monkey See, Monkey Do' phase fighting to conceptually knit everything together for the first time.
In this particular case, what's your argument? That a guy is an idiot because his hand-rolled framework makes him more productive than someone else's potentially better, fast-changing framework?
I think you do a great job of evangelizing Rails, but at times it seems like Prison Newbie School of Marketing: on the first day, you walk up to the toughest guy you can find (usually one of the J2EE guys) and beat him senseless so everybody else knows how tough you are.
You should make up a 'WWMD' (What Would Matz Do?) bracelet and look at it everytime you want to open up the flamethrower on someone with a different opinion.
I'm with Sean Porter on this one. I absolutely *love* Rails, and have been finding numerous ways to use it to save myself and my employers time, hassle, and money. I've also been very impressed by the quality and quantity of the documentation and code, as well.
One thing I've *not* been impressed with, however, is the heavy use of the aforementioned "Prison Newbie" philosophy. When responding to somebody actively attacking Rails, it seems like it could potentially be appropriate. In this case, however, the guy was actually being pretty complimentary towards Rails! Was this smack-down absolutely necessary? In the long run, things like this give the whole Rails community a bad name, which is a shame- it really is an incredibly open and supportive development community.
Anyways, DHH, please keep up the fabulous work with Rails, but please consider dialing down the flamethrower to a lower setting.
As a development community we strive to represent our ideas with greater clarity and less code. We support patterns that promote reuse and allow us to be agile.
I think generally we can all agree that maturity is a representation of stability, loosely linked to age. Just like people, code can mature rapidly or slowly.
I think we can all agree that expressing concepts with less syntax and clearer operators is better. The Ruby syntax is clearer than C#, Java, and Lisp. Does this create a compelling enough reason to switch languages?
Frameworks are built on top of languages. Like the foundation of a house, a framework consists of all the stuff most applications have (like a cement base and an electrical hookup). What makes framework X better then framework Y? Elegance and clarity?
While I believe RoR framework is mature and provides a full stack of hookups for web application development; does it provide a compelling advantage to leave the culture and communities that I have always known?
A quote that loosly couples with the last comment:
"Ruby helps to make rails work. But what everybody forgets is the cultural baggage which each community brings to it's work. Rails works because it's a product of standards and agile focused web developers working on web 2.0 style apps who have adopted ruby which inherits from the smalltalk community's legacy. Rails doesn't succeed because there aren't other ruby web frameworks, or because ruby is the perfect language. It works because it's the right combination of two traditions with some hype and an open and cooperative community supporting the framework."
The flame-grilled tone of the your post would be a little less annoying if you were right. But you're very wrong. It is HIGHLY likely that for the particular uses Ben Curtis has for a framework, and given that he would be the user, his own well worn, ideosyncratic setup is more stable, more mature and a better fit in general than Rails.
While you're probably right that if Curtis open sourced his code and other people tried to use it for different purposes on different platforms, it would be flaky as hell and underdocumented to boot, but that is not the problem Curtis has to face. He already knows all he needs to know about his own code and it already runs on his platform.
Furthermore, there's more to sticking to old well worn solutions than inertia and sunk cost, most importantly, the learning curve. Not even Rails with IBM endorsed Zero Training can beat the actual 'no training needed' you get from sticking with your current solution.
One issue I find interesting with RoR is David's attitude, and bashing (as mentioned on one of the comments above).
Matz has been humble and nice with Ruby.
Now this kid comes up with something called Ruby on Rails, and his attitude is just annoying. Lack of maturity, and his typical arrogance is worse than the J2EE snobs.
Challenge by Ryan on April 18, 15:29
I have to agree with the other posts. The bashing of anyone who makes a negative comment on RoR is just plain wrong! David, grow up.
Challenge by WWMD on April 19, 6:21
I'm still laughing about WWMD. So apt.
Rails is great. Now squelch the piehole a bit, David, before you kill it with your negative personality quotient. It's fast starting to seem like David wants to be the Dave Winer of frameworks.
Challenge by brain on April 19, 22:55
" I hate to break it to you, but first of all filling your prose with meaningless loaded statements and attacks is a real turn off and second of all you're wrong about Rails's maturity being a non-issue."
That's absolutely spot on. I was intrigued by this whole thing before I found out that the cirus was run by such a pompous tool.
Now I'm not even interested rails anymore. Someone else will come along and do the same thing just as well and not be a jackass about it.