Ted has spoken again. I'll skip ahead to the end of his post for the tit-for-tat (check out Dion's response and what Glenn says for more).
Quoth Ted:
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.
Of course Rails' "sole contribution" isn't convention over configuration. That's just one contribution, but the one that is infecting the world of Java web frameworks. The reason that this is the most infectious part of Rails is that this is the easiest part to emulate in Java. Most of the rest of what Rails brings to the table is harder to achieve, which is why it is harder to find on the Java side of the garden wall.
Glenn has pretty similar views, but I'll reiterate here. Rails' value proposition is:
Pretty clearly, Rails' biggest benefit is Ruby itself. Ruby is the engine that drives the train. Dynamic languages like Ruby provide for eloquence of expression and compile-/run-/deploy-time extension of the core framework abstractions. The ActiveRecord model is a clear example of this; extending classes at runtime to provide strongly-named property-bound finders (blogpost.find_by_title_and_author("Ted doesn't get Rails", "Dion")) is powerful, and hard to do in a statically typed language.
Its dynamism isn't just for DHH and the Rails team, either. Because of the way Ruby works, I can reach into the framework and tweak it to do just what I want without having to go and muck around with DHH's source code. Need more tools in ActiveRecord::Base? I just open the class in my environment.rb file, and add (or replace) what I need. And, since Ruby is interpreted, it sports the nifty no-compile-redeploy as well, which (as I've said earlier) is surprisingly important as I am developing an application.
The beating heart of Rails is Ruby.
Lots of people have written about Ruby's suitability for creating DSLs. When it comes down to it, Ruby's extensibility and flexibility put it in a class with Lisp, Python and Perl and separate from byte-code-language-X for creating custom syntax. For me personally, extending the base constructs of Ruby to support new, app specific capabilities, makes my job 40 times easier.
For example, I have a customer for whom I had to develop a custom query builder based on an (unfinished and ever changing) complex domain model. I quickly realized two things; first, it was impossible for me to determine through purely reflective means how to search on each field in the data table. Sometimes, I wanted to search a foreign key column as a straigt-up value, sometimes as a join to another table, and there is nothing about the field (other than the requirement from the customer) to tell me which was which. Secondly, in the generalized result set, I needed a way to create links to display each row of the table. The problem is that I won't know ahead of time what type of object each row will represent, nor which action of which controller to invoke to display it. Enter my custom search dialect, which allows me to decorate my model classes thusly:
class ModelObj < < ActiveRecord:Base
search_as_join :other_table_id, :yet_other_table_id
shows_with :my_controller, :my_show_action
endThis is hardly the end-all-be-all of DSL design, but it is enormously powerful for me because it just becomes part of the language, and as the model changes and grows, the language supports the new complexity. With Java (or .NET), I have this power, but it is through bolt-ons to the core language. I've got AspectJ and AspectWerkz and AOPAlliance, or I've got annotations and metadata. With AOP, I can do everything I want, but I have to do it through an externalized syntax, a pre- (and/or post-) compiler, or a bunch of synthesized proxies and their attendent XML markup. With custom metadata, I can get most, but not all, of what I want, but in a more natural, built-in (at least as of Java Tiger) way.
As I said last time, and as Ted agreed, it is high time for web apps to act like web apps. I want my framework to deliver the HTML over HTTP experience as though that's what I intended all along to deliver. If it gives me nice ways to bridge the server and client that make it feel a little more tightly integrate (AJaX, anybody?), the more the better. What I DON'T want to forget about is that I'm on the web. Rails strikes, for me, the exact right balance between abstraction and transparency.
Rails' convention-over-configuration is a startup-enabling technology. By startup, I don't mean a new company, I mean a new project. Part of the Agile methodology's premise is that you get the framework of the app up and running as fast as possible (during the first iteration). Then, add on the features. Rails' convention based approach makes this an absolute lead-pipe cinch. I never question any more how long it will take me to get the front-to-back chassis in place. Rails all but guarantees I'll be finished in the first iteration, often in the first couple of days. Will I keep that chassis as is for the rest of the project? Of course not. The scaffolding is just that -- a shell that allows you to visualize the general shape of the application before you've put in all the foundation and walls and pretty siding. As you fill that stuff in, the scaffolding comes down, and you are left with real, working code. Yet all along, you've been able to demonstrate to your customer what the final thing might look like. Might be a little fuzzy along the way, but the end product won't be a total surprise.
Lastly, but certainly not least, Rails gives you speed. I simply have never worked in a web app framework that enabled me to move at such a controlled velocity. I may have moved faster in the past (particularly using generated ASP.NET pages) but I never had the tools built in to ensure I was doing a decent job. Not only is Rails a highly productive environment, but it almost forces you to take a test-and-prove approach to development, if through nothing more than guilt. (Hey, look, you just generated a new controller, and I put all these handy tests down here for you to use! What, you aren't going to use them? What kind of lame-o are you?!?!)
At the bottom of all of this is my core belief that Rails is for building web sites and web applications, not Enterprise Applications That Happen To Have a Browser-Based View. For those of us who are tasked with building those latter applications, I'm pretty much positive, given today's landscape, that I'll stick with Java. Through Java, I get three major things I don't get in Rails: JTA, JMS, java.security.manager. (Though, Brian seems to be solving the JMS issue...) Since my Fortune100 clients are pretty darn sure that all three are vital to their ongoing success, Rails (and its Ruby underpinnings) just aren't going to cut it for them yet. For everything else I do, which is the bulk of my work, Rails delivers productivity, value, rapid feedback, high quality, and code that not only delivers the customer's needs, but if they read it, LOOKS like it is delivering their needs. On top of it all, its fun to boot.
I think that Ted will end up putting the Rails and Ruby books back on his shelf, if for no other reason than he's never thrown away a book in his life. However, I believe that Ted really values technologies that offer something new to developers and their customers. Rails is clearly, for me, one of those technologies, and I think that Ted believes it too, really. He just likes to have blog-offs.