Better Webapp Development?

Looking at something completely unrelated, I stumbled onto this video presentation by a NASA JPL developer:

Better Webapp Development

As you'll find when you watch the video, the creator intends to push JPL developers away from using J2EE for web application development. To make his case, he compares J2EE to Ruby on Rails, Plone/Zope, TurboGears, and Django. His approach is to create both a "Hello World" application as well as a trivial time tracking application in all of the frameworks including 2 for J2EE:

1. Servlet + JSP + Hibernate + MySQL


2. EJB/JBoss

At the outset, his motivation should be clear from the test parameters. First, he's looking at 3 different Python frameworks which should give us a clue he leans toward Python. Secondly, his two Java setups involve some of the worst tools available. Rarely do Java developers now use raw servlets, Hibernate provides some of the ugliest "xml situps" (as he likes to call them) in any platform, and EJB is...well...EJB. Most importantly, he uses application development tools on each of the other platforms but sticks to Emacs and Maven on Java.

So, let's talk about what he could have done differently to present a more accurate test. To do this, I will completely ignore the EJB solution as I agree that EJB is ugly. Apparently, it has its place and performs well in that place, but I will never use the current incarnation (still waiting to see EJB3).

Instead of Servlets, the video should have looked at development using a web application framework. In my case, I would have chosen Stripes as it drops the XML limbo and provides much simpler form development. Stripes would likely knock 50-100 lines of code off of his XML, knocked substantial Java off, and made validation simple with a couple extra lines.

Next, let's look at JSP. While I like JSP with some JSTL, I understand the argument that it doesn't play well with Dreamweaver and other web design tools. But guess what...maybe it does play well. It just so happens that Dreamweaver has plugins for JSP, Velocity, and who knows what other J2EE view technology. The fact remains that you have to put dynamic data into the HTML stream at some point. And to do that, you have to have parseable tags.

As to Hibernate, I'm sure if you've read my blog, you know what I'll say. Hibernate is a mess. However, it does provide a nice database abstraction and relational mapping layer if you can live with its quirks. To save about 20-30 lines of XML, the author could have moved to Hibernate v3 with Annotations. Of course, he may have been generating POJOs from mapping files so who knows if that would save him anything. In my experience, it does save headaches, though.

Now, stepping outside of his choices, what if the author had used IdeaJ and all of its tools? Are there perhaps other tools available that would have automatically generated the application with little to no code and few, if any, errors? While I'm a text editor and command line kind of programmer, given the age and popularity of Java, I'm sure the answer is yes.

At this point, I'm sure the narrator would claim this wasn't a fair test because IdeaJ isn't part of Java. To that, I would say that IdeaJ is a tool, not unlike the tools used to generate applications in Ruby on Rails, Plone/Zope, etc. In fact, the test was unfair to Java *because* the author chose tools badly. If RAD was his goal, then he picked the wrong tools.

The other improper guidance given by the author deals with the "headaches" of each solution as he calls them. While I can't comment on Ruby on Rails, TurboGears, or Django, I do have some experience with Plone/Zope. If the author thinks an average developer can get in and write a time tracking application in a matter of minutes, he's sorely mistaken. Zope is complex. Plone may simplify it somewhat, but those dropdown clicks that he so quickly glosses over with some 50 items in the list take some learning. The minute the application goes from experimentation to production, Zope becomes time-consuming in that you need to understand it fully, and it's a big program with thousands of options.

That leaves me wondering if he glossed over complexity in our other 3 competitors as well...

The other missing aspect of this test is any measurement of performance, reliability, and/or scalability. What use is saving 2 hours in development if the user can't actually run the application? I don't have any experience with these other frameworks in any of these metrics, but it's impossible to make an educated decision without looking into those measurements.

Fun and productivity are not the only important measurements of development tools as this video would lead you to believe.