Laurent’s Weblog

I read this last week an interesting article authored by Derek Sivers in the
O Reilly Ruby section. I couldn’t keep it for myself, so i forwarded this post
to some folks … my friend Tug wrote then a little article, replacing PHP
by Java in the text.

During the day, i could see other articles about RoR, speaking about a kind of desillusion (cf [Gartner Graph] on emerging technologies)…some folks were really radical to my mind , like ["RoR hype : party is over"] or ["Rails, The 15 minutes is almots up. Meet Erlang"]… On the other side you find this kind of article about Java by Obie Fernandez.

In this post, i’d like to add my personal feelings about RoR compared to Java world, based on some Tug’s remarks … and try to be as objective as possible.

As an introduction, i’m a Java developer (having quite ten years of experience with the language and the platform). I knew RoR (and Ruby) two years ago : i do not consider myself as a Ruby on Rails guru, but let’s say i’ve enough skills to be able to work professionnally with it : all my background experience in web development helps me a lot, and i’m not so lost with Ruby (even if the syntax surprised me in the first months) thanks to my experience with another Object Oriented programming language: Java.

The first time i jumped into RoR, i was very impressed by lots of its features as : convention over configuration, O/R mapping with ActiveRecord, Ajax facilities with RJS, generation and scaffolding, migration scripts, testing (unit & functional) support, email notification, REST/SOAP … but the scheduler, an essential feature for me too, was missing inside RoR whereas integrated in Grails (we can find plugins to schedule tasks inside a RoR application). After several weeks practicing with RoR, i rapidly saw the powerness of Ruby and all the great features inside RoR : it was a kind of revolution, comparing to some Java framework i knew like Struts or JSF ; i worked a long time with Struts (more than 3 years). But you know, if i remember well, Struts had the same effect on me by the end of 2001, when compared to old school web development with Servlets (mixing all the HTML, Javascript, SQL stuff). At this time i worked a little with PHP too ( around 2002/2003), and i really thought it was a back in time compared to Struts.

On my point of view, for the rule #1, i wouldn’t compare RoR to Java. As a web framework, RoR should be compared to equivalent Java web frameworks (as Grails, Struts, JSF, Tapestry, WebWork, Spring WebFlow, Seaside…)

More widely, Ruby can be used on server side (script batch programs, network programming, database, LDAP) or on the Desktop , combined with Graphical toolkits. In case of Desktop applications for example, we could do the same kind of exercise (in another post). A first simple question comes to my mind : what’s the real gain using Ruby + Graphical Tk in front of a) Visual C++ or .NET on Windows. b) C + Gtk or VX Glade on Linux. c) Objective-C + Cocoa on Mac OS X. d) Java with Swing or RCP family frameworks on all platforms.

So when saying Java can be used for anything you want ( Web, Mobility, Operating Systems, Database, networking), let’s compare it to Ruby (considering all the helpful Rubygems from the community), and not RoR. As i said, i’m not a Ruby Core programmer, but a guy who learned Ruby with RoR. But i’m pretty sure that thanks to the popularity of Java since 1995 (and now seen as a proven language), its integration into software vendors’ products, its worldwide enterprise adoption for about nine years, all the work done in open source projects by Java fanboys and by collaborators from great actors of the market (even if mixing many of this fragmented packages can be a nightmare on a project) : Java has the advantage. In the case for Ruby, we could say the language came behind the scene in 2004/2005 thanks to RoR, whereas Ruby appeared around 1995, like Java.

But the language itself is not the sole criteria…if we need to really compare Ruby and RoR to Java, at the enterprise level, we should also consider Ruby on Rails capabilities to integrate easily with third party products in an heteregeonous world. But we’ll see it later , in a next article.

Coming back to RoR, i can say today i’ve two kinds of experiences :

a) First on personal projects or shared projects with friends : in this case, i/we always built web applications from scratch. Beginning simple, and iteratively adding new features to the application.

b) On professional projects, where i use RoR over a legacy Database, we develop a web application on the top of a datamodel built 15 years ago.

These are two kinds of experience, really different for me. What i can say first, is:

- for case a) RoR is really well adapted and we can beneficiate of all the enhanced productivity of the framework

- for case b) it’s much more difficult, the productivity decreases and we can’t gain all the benefits of the framework (we should forget migration scripts; we should rework model classes to map table, primary key and associations; we should write much more SQL queries in the code than working with ActiveRecord find* helpers and in some cases even bypass ActiveRecord)

First i will begin about some RoR features that please me (and others that don’t), comparing them to Java Web frameworks.

When i began working with Rails, i read in parallel the excellent 37 signals book : Getting real.

Two things to say about this : first, i try to keep somewhere in my head all the great advices coming from this book when developing everyday. Twice, it made me remind mistakes from the past on some projects (and perhaps explain why some of them finished out of the initial budget, or have not been so well accepted by
end users after many months of specifications & development).

RoR, in case of pure web 2 applications, does the job…and even better than some J2EE frameworks. Every day i do something with RoR, i remember having done the same thing with Java and such or such web framework and how much did it cost me in time and energy.

With RoR all the essential technical bricks are here , well integrated in the framework. Great Ruby helper classes are here too : the greatest ones are for me those dedicated to Ajax (RJS : Remote Javascript template). What a pleasure to develop screens including nice Ajax components interacting well with the server side controller, without one line of Javascript (In Place editing, auto completer, dependent combos, form panels with ajaxified submissions, partial page rendering, ajax pagination for data grids,…) : all this
helpers are built over Prototype & scriptaculous javascript frameworks, hiding all the tricky parts (Ajax requests and callbacks management , making the Javascript cross-browser, or hiding DOM scripting are some examples). Except Google Web Toolkit and Grails, rare are the frameworks in Java world
integrating Ajax so smoothly for a Java developer who isn’t a Javascript expert.

So many Ajax tricks can be done easily with RJS , and some essential Ajax components are already there…when complexifying your app, you have the choice to integrate new Ajax features as a generic manner : typically as a component you could reuse easily from another application.; in this case, depending on
your Ruby skills, think of plugins for Rails applications (but before writing a new plugin, always do verify such plugin does not exist in the repositories of the community). If this component is specific to your app, it can be easier sometimes to write Javascript code, integrate new libraries (Behavior is an
example) but be careful of possible conflicts (jQuery for example: some functions overlap with Prototype) or to build around Prototype library; all this depending on your Javascript skills.

On the server side, in your controller, you have great features helping you to format easily the HTTP response envelope in the format of your choice : HTML, XML and JSON. It’s very useful for Ajax.

Less XML with RoR is what surprised me as a Java guy. After being an adept of XML around 1998, we then saw XML at all levels in Java projects and frameworks.
Do Java developers like XML? I would say Yes.

But i did an overdose with XML (Struts, Spring use it heavily for example). I’m convinced XML is a wonderful format, especially for data exchange, but putting it everywhere can be excessive. Let’s use XML only when needed. For me RoR respects this rule, and it’s a good choice : in RoR you use XML in two main
cases : with Ajax, if needed (with a respond_to format XML in your controller), and with SOAP/RESTful Web Services. Configuration files and fixtures use YML (kind of properties file format) for example.

Another big part for me is the database : like Tug (having common background in the same company) i’m a SQL guy. I’m conscious today lots developers don’t like SQL, and worst, don’t know SQL at all; but i love SQL.

Even with Java, at the beginning, my approach was bottom-up, and i liked reuse some powerful SQL queries written in a tool like TOAD inside my code. On bigger projects after 2000, the time of JDBC inside our Struts action was over : we used some ORM frameworks (some coming from Oracle, like BC4J), others like TopLink (supporting bottom up & top down design) , or other ones from open source (Hibernate, the DataMapper iBatis, or OJB are some examples). No more mixing SQL queries inside Java code: SQL queries are now often generated at runtime, based on the mapping done by the developer with the ORM, sometimes written in XML configuration files ( case of iBatis).

With RoR you have the couple Migrations & ActiveRecord : migration script let you write all the database object creation scripts without one line of SQL, and support the versioning for your datamodel (you can come back to an earlier snapshot of your database if needed). You have additional Tasks (for rake) to
help you in migrating or cloning your datamodel from one environment (development) to another (test, production)

Concerning the ORM itself, one thing that pleased me is that in your model class you won’t repeat the attributes (corresponding to the mapped table columns)…seems DRY . At runtime all is retrieved by an introspection on the concerned table(s). A bemol for the relations you need to add to wire your Ruby objects (for one-to-one, one-to-many, many-to-many relationships): here you can imagine, when working
with some databases (Oracle by example) you could repeat these relations by adding constraints to your tables inside the database. Seems not so DRY here.

ActiveRecord exposes all methods of the CRUD (find, new, create, update_attribute, destroy). For more complex queries, SQL can written directly in your Ruby code (using the find_by_sql).

Having used some ORM with Java gave me some facilities when learning ActiveRecord i think.

Finally , concerning the Web Services. I do not have lots of experience in WebServices with RoR. I bean to write clients (for del.icio.us, Flickr, Google). On server side, i used Active Resource to generate a RESTful application. For SOAP, there is the essential inside RoR to support it , but additional gems like soap4r can be added for more complex tasks: effectively it’s really less complex (because less features) than the WS-* stack in Java.

First, there are no reasons to have a war between Java/J2ee world and Ruby on Rails guys. I think today, they can live together. Java/J2ee is often too much complex for what we need to do : just check the time you lose integrating on the platform, even integrating additional open source bricks on a project. In this case, i would say , please just try RoR. And if you don’t want to change your language (because of the learning curve for your Java developers), so try to think of lighter Java frameworks like Grails, Wicket or Stripes. But please, be agile.

Another great application of RoR, would be: please replace all the “prototypes” written in static HTML or even with f**** PowerPoint, and use RoR!! First you’ll learn smoothly the framework, and for web 2 applications, even at the beginning you’ll can integrate great Ajax features, that you’ll be able to reuse later (even if you start your project with a Java Web Framework)

As i have many other things to say about RoR and Java, i plan to write a second part for this article. In the next part , i will speak about deployment and Ruby on Rails integration in the enterprise (always based on my experience).

Ressources :

O Reilly Ruby Section :
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html

Tugs Blog :
http://tugdualgrall.blogspot.com/2007/09/derek-siverss-blog-7-reasons-i-switched.html

Why java sucks the ass by Obie F. :
http://www.jroller.com/obie/entry/top_10_reasons_why_java

Rails, The 15 minutes is almots up.
http://blog.bwtaylor.com/java/ruby_meet_erlang

2 years of dev, put into the trash :
http://www.diegoparrilla.com/2007/09/ruby-on-rails-hype-party-is-over.html

Ruby on Rails hype : the party is over.
http://www.javablogs.com/Jump.action?id=379448