Why bother with Java Server Pages (JSPs) and JSP tag libraries?

It isn't unusual for various technologies to develop fans with a certain fervor - the most common assertion in any resulting discussion being a variant of "My technology is better than your technology." Java Server Pages (JSPs) seem a distinctive victim of such debates in that they catch a certain amount of friendly fire even from those otherwise enthusiastic about other J2EE technologies.  A solution relying upon JSPs certainly must be aware of their shortcomings but in my experience their merits, laying more with the people-ware than the software, deserve some attention as well.

The shortcomings of JSPs are numerous and pretty well understood by most J2EE practitioners.  They aren't automatically pre-compiled so there is a response lag when they are first used.  Most IDEs don't provide very good support for them and that makes development more challenging.  Support in testing tools (JUnit, JTest, etc.) is similarly limited.  The list goes on and it isn't surprising that many J2EE developers regard JSPs as the "evil twin" of servlets.

But taking off my engineer/developer/architect hat and putting on my team leader/manager hat puts JSPs in a different light.  I share with my colleagues the "I don't like....", "I don't use...." and ".....doesn't work for me" observations about JSPs...... but in development projects of any scale it isn't all about "me".  The reality of many software development projects is that you don't get as many gifted engineers as you'd like but have to march on (hopefully toward success) with people far less adept at J2EE development than some of us who have been doing J2EE before it was called J2EE.

The merit of JSPs and JSP tag libraries is often that they hide that there is any J2EE going on.  From the view point of a XHTML web developer they are still crafting those pages in DreamWeaver much as they were before but with a few extra lines in their XHTML somewhere.  This allows these contributors to do the work that they do largely ignorant of the J2EE machinations going on.

No, before my gear-head friends laugh themselves into a tizzy about how JSPs are J2EE for Dummies, let me say that in my experience this is a genuine merit of JSPs - ignorance is bliss as they say.  One of the merits is that this allows a significant amount of discovery in the user-interface and workflow without a pre-mature commitment.  With a modest amount of architectural planning it is, for example, a realistic approach to defer the J2EE versus .Net back-end decision while some of this front-end discovery proceeds and (to a degree) still exploit much of those early front-end assets.

I suppose my bias here also comes from an unabashed enthusiasm for certain elements of "The Macintosh Way" philosophy...not the least of which is that the best engineering is infused with a certain measure of art, literature, etc.  So, the competiveness of many product-oriented projects I've worked upon, has been founded on the contributions of people who wouldn't know a debugger if it fell on them but are gifted artists, writers, and other creators of the user experience.  To best exploit these contributions, it isn't smirk-worthy but necessary to "dumb down" technology a bit so that the total solution has a bit of that high art that that is also necessary for winning products.

In the end, I see JSPs and JSP tag libraries as mechanism that under-utilizes Java technology but maximizes the total human intellectual capital applied to solutions.

- Brian



No comments: