A lot of the same comparisons could be made between Ruby/Rails and Java/Spring/Faces/Struts/Hibernate/etc when the Ruby/Rails combo first came out. That is to s

A lot of the same comparisons could be made between Ruby/Rails and Java/Spring/Faces/Struts/Hibernate/etc when the Ruby/Rails combo first came out. That is to say, when a technology is in its early stages, fragmentation hasn't had a chance to set in. I think Node.js stands a pretty good choice of avoiding fragmentation for the near future, but that is only because it is a pretty raw implementation. Node.js is apples where Ruby on Rails is oranges. Another thing the author would be wise to note that Node.js may not be ready for prime time just yet. The author has been attributed as saying such as recently as May of this year: http://www.yuiblog.com/blog/2010/05/20/video-dahl/ http://www.yuiblog.com/blog/2010/05/20/video-dahl/ The API needs to stabilize a bit before I'd roll a large amount of code on top of it. If there's anything I've learned from Ruby on Rails, it's that you have to be prepared to tear in to a plug-in or module if the maintainer decides they're not going to maintain it with future versions of the technology that it plugs in to. Overall, this rant jumps all over the place. We go from Sinatra, to Rails, to mobile. How is the switch from Sinatra to Node.js relevant to Ruby in a native mobile environment and also Rails? It's all just a little bit confusing. I'm responsible for the app hosting environments at our company, so I understand the author's frustration with Ruby versions and the impending release of Rails 3. About 6 months ago, we started on a brand new web app and decided that we were going to look toward the future. We built it on top of Rails 3 (first beta) and Ruby 1.8.7. I literally had to compile various builds of Ruby 1.8.7 until I found one that would work with the first Rails 3 beta. We had to hold that configuration through Rails beta1 because we couldn't find a config that worked with Ruby, Rails, and all the plug-ins we are using. It has been painful. But now that Rails is closing in on a 3.0 release, and Ruby is closing in on 1.9.2, things seem to be coming together. Plug-in authors see a light at the end of the tunnel and are running toward it. I also strongly disagree with the authors sentiment with regard to RVM. If there is a strong point to Ruby on Rails development, it is that every layer of the stack has received a lot of attention. RVM is an elegant solution, and it works well with bundler, which is integral to the Rails 3 release. Having pushed forward through several releases on top of Rails 3, RVM, and Capistrano, I can say with confidence that Rails app deployment has arrived. Mixing/managing Gem versions for production and staging environments in one OS environment is ready to rock. The one caveat being that there is no good solution for running more than one version of Ruby. The Passenger team is working on a solution to that, but I'm not sure we'll ever implement it. Running mixed Gems is one thing, running mixed interpreters in another. My preference is to keep some level of consistency at that layer. I've not addressed all the author's points, because he's right about some things. Specifically speed and the "ooooooh shiny" mentality of most Rails developers. My lead developer is the best programmer I've ever worked with. I wouldn't trade him for anyone, but I do find it a constant battle to force a strict vetting process of new technologies. We went through no less than three authorization plug-ins during the early stages of app development on our most recent project, and the last revision consumed a not insignificant amount of time to strip from the project. I still feel like the trade-offs are worth it. At least for our project.