Sunday, January 01, 2006

Why does it have to be so complex

I know, it's been said so many times before... But why does web development with Java EE have to be so complex?

I have previously worked with EJB 2.0 which felt like a pain... The turnaround time was horrible (the compile, deploy, test process took about 2 minutes). And it felt especially bad since most of the functionality offered by EJB was not even necessary for the project. It was a great relief to switch to another project where Spring Framework was being used.

Still, however, the complexity of doing simple things is rather high. At my current project, we use Struts, combined with a homegrown framework (which itself adds to the complexity while adding some functionality). Adding a new page involves so much XML configuration and boilerplate code that you wonder when you're going to do some real coding.

This is one of the main reasons why I have been smitten by the Ruby on Rails bug.

I think Rails has a sensible, pragmatic approach to web development. As David Heinemeier Hansson has often stated, Rails is not everything for everyone. The purpose is not to fulfill all needs for every possible web application but rather to ensure that it makes life easier for the bulk of applications. IMHO, this is a very healthy way of seeing things.

I think many Java developers -- myself included, although I'm working on it :-) -- in general have a tendency to want to do everything the "right way" from the beginning and always with the approach that "what if the customer/framework user/etc. want to do this in the future..." This is so non-pragmatic!

I think a problem in the Java world is that there are simply too many options. I like the fact that Spring is able to integrate multiple APIs for the same purpose (ORM APIs, for instance) with a more or less common interface. I know that these APIs fill different niches on the ORM market (perhaps quite large niches), but it just adds to the complexity. Sometimes it would be easier to stop and think whether you really need it all. As Java developers we have a tendency to want a framework be able to do everything for everyone, preferably being configurable (in XML) for any possible situation. I don't think this is a bad thing in itself, it just complicates matters. There is no way this is ever going to be simple (Anders Hejlsberg calls the phenomenon simplexity when you try to take something complex and try to "pretend" that it is simple by wrapping it in something simple).

One of the extremely nice approaches in Ruby on Rails is the focus on "Convention over Configuration" (i.e. using defaults as long as you adhere with the conventions, eliminating the need for configuration). This is so obvious and yet so powerful. Very often, I have had the feeling that I'm just repeating something that the framework should have been able to figure out itself. Basically, the use of "smart defaults" could eliminate so much of the configuration (if not all) as well as a whole lot of boilterplate code.

So far, I have only used Rails on a small pet project, but it really feels right. The defaults chosen by the framework are sensible and intuitive and really makes developing web applications more fun!

I really hope to get an opportunity (i.e. an excuse) do some Ruby on Rails development on a real-life project so I can see, whether the promises and my initial impressions still hold true.

In the Java world, I'm pleased to see that the focus on simplifying things is increasing. Spring 2.0 will bring a simplfied syntax for a number of typically used configuration cases (such as JNDI lookups, transaction configuration and AOP pointcut definitions). Also, they are focusing on adding smart defaults for obvious settings.

A project I intend to follow closely is the new Struts Titanium (Struts Ti) which is the "merger" of the WebWork framework with the Struts framework (in reality, it is basically a rebranding of the WebWork name). What is interesting, beside the fact that this completely different implementation of Struts should still be able to support legacy Struts web applications, is that the team is focusing closely on simplifying development of Web applications along the lines of the Ruby of Rails framework. There is much focus on intelligent defaults based on naming of actions, pages etc.

6 comments:

Geert Bevin said...

Hi Jesper, have you looked at RIFE? It's a full-stack framework that aims to make many things as easy as possible while still keeping on eye on maintainability, group development and componentization. You can find more information at http://rifers.org
David Heinemeier Hansson has give it his praises, as well as other prominent developers like Bruce Tate: http://rifers.org/blogs/gbevin/2005/10/28/rails_author_congratulates_rife http://rifers.org/blogs/gbevin/2005/9/15/prominent_developers_praise_rife

Jesper Kamstrup Linnet said...

Hi Geert,

Thanks for the pointer. No, I was aware of RIFE, but I have never had a closer look at the framework.

My first impression of the framework is OK, and I like the fact that you have created a Jumpstart application allowing users to get up and running quickly. I must also grant you that it seems to be a very full featured web framework (more so than most other frameworks, I have come across).

However, I still see a problem in the myriad of seemingly rather cryptic XML configuration files. I know, the application contains both a public site and an admin site, but still it seems complex.

I guess that my primary dislikes are that you're able to do so much (RIFE is really feature packed) and that you seem to have to configure so much.

My comments might be quite unfair since they are based on a very brief glance over the Jumpstart application, and also I have never developed a real life application in Rails. I intend to look further into RIFE (and Rails for that matter) and will withdraw these comments if I conclude that I was wrong. :-)

Geert Bevin said...

Hi Jesper, RIFE doesn't *need* many XML files. All the element and site XML declarations are in fact not configuration but declaration. They are really reduced to a minimum and it's the cornerstone of RIFE's logic flow and data flow management that provides componentization of everything in your site. It's a very small price to pay for huge maintainability benefits and you can really reuse all the elements in any situation: portlet-style mini app, widget, page, subsection of a site, AOP-like layer above your site, ... You also get the benefit that your entire application is documented and summarized in one central location, which makes it very easy to work with a team on the same project. Additionally, RIFE uses your url mappings there throughout its entire engine. This means that everything is fully relocatable and localizable. Imho it goes one step further for the DRY principle in terms of URL management. You can use Java, Groovy or Janino to perform these declarations, in case you're not fond of XML: http://rifers.org/wiki/display/RIFE/Site+structure+and+element+declaration+without+XML

I encourage you to read this blog entry too: http://rifers.org/blogs/gbevin/2005/10/11/rife_misconceptions

Our project values productivity a lot, except that we think maintainability and reuse is even more important.

Feel free to come over to the IRC channel or to join the mailinglist if you have additional questions.

Best regards,

Geert

Jesper Kamstrup Linnet said...

Thanks Maarten and Geert, for correcting my incorrect impressions. I'll still have to find time to take a closer look at RIFE but at least now I can see that there's still hope :-) I especially liked the 'RIFE misconceptions' blog entry.

By the way, Geert, any idea when your slides from the 'RIFE in Action' presentation at JavaPolis will be uploaded to the JavaPolis wiki? I unfortunately missed your presentation (at that point, business rules engines seemed more interesting...).

/Jesper

Geert Bevin said...

Hi Jesper,
the slides of that presentation will probably not be uploaded since I nowadays do a lot with embedded video fragments of live coding sessions. On slides that doesn't come over too well. The RIFE in Action presentation was essentially created in a few hours (since I only knew one day beforehand) by assembling the following presentations and videos:
http://rifers.org/rife_indepth_simple_blog
http://rifers.org/theater/rifecrud_intro_tutorial

I did write some additional slides about adoption, production statistics and future plans, but you get 99% of the presentation from the resources above.

Best regards,

Geert

Jennifer said...

Hi there! I'm currently doing a senior project for my mater's degree and am conducting some research comparing STRUTS and Spring and their impact on extensibility. I would appreciate it if anyone who has had experience with either framework would fill out a questionnaire for me. It's at http://www.createsurvey.com/c/31128-0nVgEU/.

Thanks!!