I was happy to note that Dion Almaer commented on my blog post on Merb. Dion is one of my favorite bloggers/podcasters and I value what he writes highly.
But I disagree with him on this one. The problem with using Java for web application development was never one of too much choice. In fact, it was because of that choice that Java became a player in the server side market at all. Sun alone never had the answer to what was needed for server side development, instead the open source world stepped in and made incremental corrections.
The same thing is happening to the Rails world. The core team cannot create a framework that is a one-size-fits-all. The initial Rails proposal is great for a large number of webapps, but it is other things around it like plugins and JRuby that is making Rails a viable choice for all.
My Java tools of choice was usually Tomcat/Jetty, FreeMarker, iBatis, WebWork tied together with Spring or PicoContainer. What I hated was having some frankensteinian-enterprise-architect-design-by-comittee-lets-not-be-different stack forced upon me with a fullblown J2EE server, EJB’s, Struts or the JSF monster, sprinkled with an Eclipse-only development environment. And I hope dearly that Rails development is not going the same way where people question you on your choice of tools and wonder why you are not using MySQL and TextMate like the rest.
There is one choice that I do not miss though - directory layout. I am truly happy every time I do not have to choose it.
Instead of not having to choose, the most important difference I’ve experienced is that Java as a language together with the Servlet/J2EE spec induces a lot of accidental complexity, which is almost non-existent in the Ruby/Rails world. It is that which enables the increased velocity many development teams experience when switching to Ruby.