July 29, 2004

J2EE vs Ruby on Rails

J2EE currently helps me earn a living for my family. It sure beats the CICS/COBOL/DB2 or PLI/IMS mainframe technology sets that I used in my younger days.

But it can be incredibly frustrating to build applications within a short space of time due to J2EE's complexity. Within the Java world there is a movement to develop a better way, using frameworks such as Spring and Hibernate.

However, when I read today about Ruby on Rails, a web-application framework for Ruby that has just been released as open source by David Heinemeier Hansson, I had to take notice. According to David, he used Rails to develop Basecamp in just two months. That's an impressive claim. I'd known about Ruby as a scripting language before but this is the first time I'd heard about a webapp framework based on it.

I know this is an inflammatory statement but it would seem like the smart money is on a shift away from J2EE to Ruby or Python-based web frameworks.

Do you agree? Or have I missed something? For example, what advantages does J2EE have over Ruby or Python in terms of building high quality web applications quickly?

Posted to Software Development by Keith Pitty
Comments

Connectivity. Can't build it quickly if you need to connect to some legacy app that has not adaptor in those languages.

Consistency. Look around the Ruby and Python world, there's just no defacto standard on how to do things.

Robustness. My impression of many Python components are that they are quick hacks just to get things done and never seem to have a consistent component model.

Manageability. No JMX layer for remote management, need to build it yourself.

Also, there's nothing to prevent you from not using certain cumbersome frameworks (like Struts and JSP), you build code in a similar manner as the Ruby or Python frameworks out there. See for example Helma.


Carlos

Posted by: Carlos E. Perez at July 30, 2004 12:38 AM

Well, people say that the J2EE solutions are more scalable. A Ruby or Python web app may take less time to get going, but if you're going to run an Amazon or eBay you need something that scales up.

Now, I have no idea if this is true, it's just what they say...

Posted by: Ralph Richard Cook at July 30, 2004 12:41 AM

Rails seems suitable for developing (at least) small-scale web applications in a rapid manner. I haven't seen a single web application framework written in Java that would use such approach.

It will be nice to see whether Rails can cope with more complex applications as well: the blog example presented in the "10 minute setup video" is trivial (but impressive nonetheless).

And remember, CPU time is dirt cheap compared to development time.

Posted by: Jari Aarniala at July 30, 2004 1:28 AM

Thanks for your thoughts, Keith. I've posted a bit about it on Loud Thinking.

Jari: Being a 10 minute video limits the amount of material that can be covered. Rails is much, much more than that. See Basecamp as an example of a "mildly-complex" web-app done with Ruby on Rails.

Posted by: David Heinemeier Hansson at July 30, 2004 2:04 AM

Quickly? J2EE isn't really about building things quickly.

The scripting languages like Perl, Python, PHP, and Ruby are useful for quickly hacking up a Web site. However, as Fowler's "Principles of Enterprise Application Architecture" notes, they are pretty much limited to the "Transaction Script" model.

Transaction Script is a good model for simple, focused, self-contained Web applications that can define their own data structures. That IS a large percentage of Web applications, and not to be dismissed.

But the farther you go beyond those limits, the more of a quagmire Transaction Script becomes. Controlling data that is simultaneously shared among multiple applications is messy enough that it begs to be centralized in a separate layer, rather than distributed across every script page you have. At that point the Table Module approach of .Net or the Domain Model approach of J2EE becomes the least painful route.

The first "E" in J2EE is for "Enterprise". J2EE is about enterprise-level data handling, not about whipping up a little-but-useful Web site.

Posted by: Doug at July 30, 2004 5:56 AM

Damn! Fowler has a new book already? ; )

Posted by: Florian Weber at July 30, 2004 8:56 AM

after reading your comment again, dough.. one more thing:

what the hell does all that stuff about transaction scripts, layering stuff have to do with scripting languages?

"J2EE is about enterprise-level data handling"

awesome! i think thats the funniest and best thing i ever heard about j2ee =)

Posted by: Florian Weber at July 30, 2004 9:34 AM

about java scalabiliy: remember the recent flamewar about friendster.com: they choose php over java cause the first scaled better, and they had more than one author of JSP books.

Anyway, the problem imo does not rely (well, partly) in java itself, but in the surrounding stuff.
J2EE devs are moving not just to ruby, python and the likes, but to lighter frameworks.
The various IoC containers, AOP frameworks, tapestry and many other things are simple run away from the main j2ee world.

Posted by: gab at July 30, 2004 12:24 PM

Well so far java has the most impressive set of apis for enterprise development : transaction, security, mom and so on.
I'd love to use ruby in enterprise projects but the lack of (standard) apis and the lack of connectivity (I mean distributed TX, messaging middleware, IIOP...) is really a serious problem.
The language itself is beautiful but a language is nothing without a large set of well accepted or standards apis.

Posted by: jos at July 31, 2004 2:56 AM

Actually Python HAS a complete and reliable component system (much better than java's actually) which comes from Zope and can be downloaded here:
http://zope.org/Products/ZopeInterface/

Also:
PEAK, Zope3 and Twisted are way way way ahead than j2ee, just read this article from IEEE Internet Computing: http://dsonline.computer.org/0407/d/w4towp.htm

I'm developing a very big web application using twisted and its web application framework, it is incredibly easy and powerful.

I also think that the same can be said about rails and ruby, but I happen to know python.

Actually, keeping saying that java is for enterprise is everyday becoming more and more only a joke, since there are more reliable, portable and powerful languages out there than java.

And python, for instance, can use all the java library through jython or the recent Pype...

Posted by: Valentino Volonghi at July 31, 2004 7:27 AM

Doug,

> The scripting languages like Perl, Python, PHP,
> and Ruby are ... pretty much limited to the
> "Transaction Script" model.

I'm not sure about Perl, PHP or Ruby, but as far as Python goes, you are misinformed. I've seen many more "Transaction Script" applications written in Java than I have in Python.

PHP currently encourages the Transaction Script way of doing things, but is in the process of evolving beyond that. Ruby apps could most definitely have a model layer. Perl apps could too, but I'm not sure that many Perl hackers would bother.

Posted by: Alan Green at July 31, 2004 7:53 PM

Thank you to everyone who has posted a comment on this topic. You have given me plenty of food for thought.

Posted by: Keith Pitty at August 1, 2004 9:42 PM

Regarding the connectivity argument, I give that no credence at all. If you have some oddball system you want to connect to, it's more likely to have a C interface than a Java one defined. C is still the standard for writing low level stuff, and Python at least is dead simple to write C extensions for, if you don't want to use SWIG.
Out of all the negatives here, the only one I'd give any real credence to is the management interfaces. However, something like JMX would me much easier to implement in a dynamic language than Java.
Someone mentioned friendster and PHP, I also recall hearing that Yahoo! uses PHP a great deal. eBay is at least nominally using WebSphere, but I believe that the heavy hitting parts of Amazon are in C or C++.

Posted by: Gordon Weakliem at August 20, 2004 7:54 AM