Friday, March 09, 2007

The Holy Grail(s) UPDATED

In Which I Claim that Java is NOT Dead, and Groovy will be Bigger than Ruby

UPDATE 12/11/2007:
I have recently started using Ruby and Rails on a Java project. Does this invalidate my assertions here? I don't think so, it merely underscores the key application for Groovy: tight integration with Java source and libraries. I had the need to do some schema management, for which Rails migrations are the simplest approach I know, and some batch scripting; neither of which intersected with Java at all. A final factor is that I just know Rails far better at this point.

As I have talked about in previous posts, Java (EE) has been optimized for Enterprise requirements: Big applications with heavy-duty scalability, performance, and security, often weaving together many disparate databases and integrating with other applications. On the other hand, Java has most decidedly NOT been optimized for productivity, maintainability, or developer self-actualization. Although some frameworks and tools have attempted to address the latter set of requirements, nothing comes close Ruby and Rails.

For green-field development, small-medium sized projects (and medium can mean easily thousands of users nowadays), I would really, really lean toward Ruby on Rails. However, what about for projects in organizations that have standardized on Java, or for developers who are already Java ninjas? Enter Groovy, and Grails.

The promise of Groovy, and Grails (though I am sure there will be other frameworks), is to bring productivity, maintainability, and, well, fun to the Java world. Because these are Java-based technologies, projects can leverage these capabilities to get to market quickly, and Scale Later, falling back on all those nice big E Enterprise features of the Java EE stack. That, I think, is the Holy Grail of Java development: Rapid development early, beefing up later.

That is why, IMHO, Groovy and Grails might be as big as, if not bigger than, Ruby and Rails. I expect I will be writing a lot more about this in the future. Also, look forward to a new blog called GroovyCode, where I intend to capture bits of Groovy coding goodness.

For your further reading pleasure, I include here an email thread I had with Scott Davis, a Groovy pioneer and operator of aboutGroovy (as well as all around coding Rock Star) [from Aug. '06]:
> Thanks for the info, very helpful. As for the client, it's an
> outside shot right now but I will see where it goes. I originally
> suggested ROR, but he wasn't "comfortable" with it. He couldn't
> really state the requirements that he thought were lacking, but I
> think he just feels it is not industrial-strength enough. In order
> to get his business, then, I proposed a Java solution.
>
Ahh, "industrial-strength". Now he's showing his cards. Grails is
based on "industrial-strength", well-proven technologies like Spring,
Hibernate, et al. I firmly believe that RoR is "industrial-strength"
as well, but it doesn't have the track record that Java does at this
time. +1 Grails.
>
> Now here comes GOG, seemingly on the cusp of critical mass. Which
> got me thinking that I could offer ROR productivity, with the
> option to (readily) leverage all the enterprise capabilities of
> Java down the road. And I can talk about reusing some of the code
> I have, though it might not actually make sense.
>
You've hit on the sweet spot of Grails. I honestly haven't gone into
a Grails app and seen what exactly is salvageable in terms of pulling
out the Spring, Hibernate files and using them in a pure Java
environment, but I can't imagine that it'd be too hard.

> Well, there. Probably more than you wanted to know. Before I let
> you go... What do you think the productivity (functionality /
> time) advantage of GOG is over Java Webapp development? Any reason
> it could not scale to, say, 100s of 1000s of users?
RoR folks like to claim 5x-10x increase in time to production over
J2EE. I'm not *even* going to venture into that rats nest for Grails,
especially this early in the game.

The bootstrapping aspect of Grails is pretty compelling -- download a
single tarball and *poof*, instant app. It, however, is running Jetty
and HSQLDB. I haven't played with hooking it up to an external db, or
running it in another servlet container, but that certainly
diminishes the "out of the box" / time-to-production. Of course, this
is pretty much a one-time cost.

Creating initial views is pretty easy (grails generate-all), but hand
editing them takes some time and coordination. If you don't like the
default ordering of the fields, for example, you need to hand edit
list.gsp, edit.gsp, view.gsp, new.gsp, etc. If you add a single new
field to the table, there is no clean/automated way to migrate your
views as well. This is an ongoing cost.

I think the biggest win is letting Grails handle all of the
"plumbing" issues for you -- Spring, Hibernate once again.
Infrastructure like that getting autogenerated is huge.

> How about ROR by comparison?
Much more mature, and I think at this stage of the game it has a
better coordination/migration story for iteratively adding fields and
keeping your model and view in sync. For green-field development with
no ties to Java, it's a pretty compelling story.

3 comments:

Anonymous said...

Who knows where to download XRumer 5.0 Palladium?
Help, please. All recommend this program to effectively advertise on the Internet, this is the best program!

Purohit D said...

Java development services with dedicated Java developers. Java development outsourcing with proficient Java Developers.

website designing development company chennai india said...

I have read this post. collection of post is a nice one ..that am doing website designing company chennai india and website development company chennai india. That I will inform about your post to my friends and all the best for your future posts..