More on Rails

It appears that a couple of my so-called friends are expressing surprise(?) or condemnation(?) over the fact that I didn’t fall under the spell of Ruby-on-Rails at the $NFJS Austin show. As the great comic Steve Martin used to say, “Well excuuuuuuuse me!” :-)

Dion first takes a couple of cheap shots:

Firstly, you can’t say much for Ted wrt taste… I mean he is running that .NET blog software now ;)
Dude, you have NO idea how much simpler and easier my life is now thanks to dasBlog. So hush. ;-)
Secondly, I think Ted hit the nail on the head and didn’t even realise it … I think the Java world took this [greater need for configuration] waaaay to far. Abstractions upon abstractions. We forgot that web frameworks ARE FOR THE WEB!!!
I don’t remember ever saying anything otherwise, nor did I anywhere endorse any of the particular Java web frameworks that have sprung up like weeds, including JSF, which Dion goes on to imply I’m a fan of with:
Before you look around we have JavaServer Faces, which “features” that you don’t just get to write out HTML. Sounds great on paper. I still hear people talking about how they will be able to just flip on a different Renderer and they will have a mobile application. Of course, in reality a mobile application is very different. You care about different things.
Dude! I said the same thing waaaay back when JSF first came out, that it seeks to create a programming model similar to that of a rich GUI app over a technology that looks nothing like a GUI app. There’s no argument here. But the idea that somehow “it’s Rails or it’s JSF” is a HUGE logical fallacy, and one that frankly I’m surprised Dion even hints at. I have no value judgment to make a la JSF, as I’ve not done anything with it, other than I’m worried about the implicit inefficiencies that JSF was in danger of creating (as WebForms do in .NET). People I know and respect (most importantly, David Geary, a one-time huge proponent of JSF) are critiquing JSF, and for now that’s something I’ll let them do, as for me to comment on JSF in detail would be speaking from ignorance. That said, though….
I want a web framework that lets me work with web technology (HTML is one of them ;), but gives me a nice clean way to do this.
Allow me to introduce you to this really cool little technology, Dion: it’s called servlets, and it’s so tightly coupled to HTTP that it’s frightening. I mean, there’s really no way you could ever hide the round trips implicit in HTTP, nor could you port a servlet app to become a mobile app or a GUI app. They do reloading of compiled code on the fly, and they have a relatively simple configuration model (particularly if you don’t make heavy use of exotic features like security models, which you won’t because you don’t even have them in Rails so you won’t miss ‘em, right?). Couple this with some JSP and good XDoclet-based code-generation, and you’ve a pretty interesting system right there….
In my experience, I like to have simple tools which just work, but if the hardest part of your application is the web framework, you are lucky!
I heartily agree, and frankly, I find that “Servlets + JSP” fit into that category of “simple tools that just work”. That’s a value judgment, and I won’t find fault with anybody who claims that the servlet+JSP space is too complicated–but that said, don’t come crying back to us when Rails doesn’t let you do URLs the way God and Tim Berners-Lee intended. Oh, and before you start quoting support for Flash, how many Java web developers are really using it? Anecdotally… nobody. Right or wrong, Flash support hardly ranks high on the list of Good Things.

We then turn to Justin’s comments:

Ted Neward, a great friend, colleague, and all around smart-guy, just really missed the boat on Rails this last weekend. Dion pretty much hit the nail on the head on the technical response. Rails is a web framework that doesn’t make me think I’m writing a Swing app, or that I’m writing an EJB app. It pretends to be nothing; it is, rather, a powerful framework for writing an app that delivers HTML over HTTP. Hell, what with the ASP.NET/JSF render kit wunderland, I’m starting to wonder if we need a new acronym: POWA (Plain Ol’ Web App).
I like the acronym. More, as I said above, I’m heartily in favor of something that will help us “stop the madness” of the “Let’s-Hide-The-Web-Part-of-a-Web-App” framework design approach.
Regardless, he also whiffed (sorry big guy) in his musings about managed versions. There is, of course, Trails, a mighty attempt to make the Spring/Hibernate/Etc. stack as easy to configure and use as Rails, and MonoRail, an open source .NET equivalent as well. What fascinates me about MonoRail is that it is one of the first attempts to move away from the standard ASP.NET design pattern; the MVC crowd has just not found a great way to own that space. Maybe MonoRail will be the ticket. (By the way, check out the other stuff going on at CastleProject; DynamicProxy is a great little tool for making synthesized proxies a la Java, without all that Reflection.Emit() hassle.)
Won’t pretend to know everything, big guy, and more importantly, I didn’t want to pretend knowledge of a space that I don’t have. Was I reasonably convinced that somebody was already working on one (or more)? Sure, it’s not hard to make that assumption. But it’s better, IMHO, to take the conservative approach and “let the community tell you”, if I may steal-and-paraphrase the XP saying. Now it’s time for me to go have a look at those (in my copious spare time) and see if there’s any goodness there.
When I say he whiffed, it isn’t because he couldn’t tick off the various projects off the top of his head. Its because he missed that Rails is already influencing everybody else. The “small” feature he mentions, convention over configuration, is catching on like wildfire, and I don’t think it would have unless Rails had highlighted the fact that the 80% case is to only configure 10% of your app. We’re also seeing some folks revise their commitment to web components; with Rails, parameterized partial templates give you most of what you get with web components, and at a fraction of the compexity.
This, then, is interesting to me–is Rails only interesting because of “the fact that the 80% case is to only configure 10% of your app”? Or, is it that Rails’ sole contribution is that it helps bring the pendulum back away from the layers-upon-layers default approach in Java projects? If that’s the case, then I get Rails entirely, and I’ll quite happily put the Rails book back on my shelf, because it means that it’s major contribution is one of influence, and not one of “need to know for consulting practice”. But that’s NOT what I’m hearing the Rails-buzzers say, so I’m not convinced that Justin’s identified what is is I missed.

Look, guys, at the end of the day, if Rails is about Ruby and the things that a scripting language can do that a compiled, statically-typed language can’t, then Rails definitely has a place in the world and I’ll take the time to learn it. If Rails is about bringing sanity back to the web framework space, then I’ll wait for the Java and .NET Rails-influenced projects to ship and stick with something that has BOTH the sanity AND the support of managed platforms.

So Dion, Justin, if you still think I whiffed, tell me why, pray tell. Or else admit that you’re just jumping on a “bright shiny new toy” bandwagon and that two years from now, Rails won’t be in anybody’s lexicon. In other words, it’s “put up or shut up” time. :-)