Are JSPs dead?
Thatâ€™s supposed to be a rhetorical question, of course theyâ€™re dead. They died a long time ago when it dawned on us that they were nothing but untestable, overweight slobs that only ever existed because of ASP. Anybody who ever used JSPs has at some point, sworn by them, marveled at how great they are and felt really, really excited to write actual Java code inside pages. But it was only a matter of time until some of the lesser known facts about JSPs became more and more prevalent to the point of that templating languages were forced into creation to combat the shortcomings of Java Server Pages.
JSPs are the ultimate contradiction to Java reusability, there is simply no mechanism in J2EE which allows even an honest man to reuse a JSP. If youâ€™re thinking of <jsp:include>, youâ€™re missing the larger point of reuse - reuse as in other components of the application or even different applications. Of course being confined to a Servlet container kills off any chance of reuse in the SE world along with making testing so hard that youâ€™re forced to mock an application server just to see whatâ€™s rendered. The direct binding to a Servlet is also something that never amused me nor did I find the behind the scenes conversion from JSP to Java to Class file ever a needed exercise. Why bother with an extra compilation stage when youâ€™re already serving your page from a compiled Servlet?
Be advised that if youâ€™re still considering using JSPs as the V part in MVC for even a mid-sized application, youâ€™re making a mistake. This is especially true if youâ€™re using JSPs as purely a view mechanism (no actual code in the pages but just taglibs) since youâ€™re not even taking â€œadvantageâ€ of the ability to write Java code in them. If you are one of those folks who thinks the
Not too long ago a colleague of mine stumbled upon a major bank website (TD Canada Trust) who had managed to seriously screw up their application server configuration and ended up serving the raw JSP page instead of actually executing the code in it. Needless to say the code looked like crap with request.getParameter() being used more often than white space to compute user states in a banking application. It was one of those â€œthis page can do a lot of stuff so Iâ€™ll just write a lot of ifs to figure stuff outâ€ type things. What Iâ€™m trying to say is that JSPs promote shoving control logic in your pages no matter who you are simply because itâ€™s so easy to fall into the pitfall that are scriptlets. Itâ€™s best to eliminate the temptation and use a dumb templating tool to render your views because letâ€™s face it, theyâ€™re views!
What to use if not JSPs? Plenty of choices including Velocity, Jamon, Freemarker, StringTemplate, JByte etc. All good options with Freemarker being my favorite because of itâ€™s lightweight nature, templating prowess and out-of-the-box support for Taglibs. Whether youâ€™re templating a simple email to be sent out or a full-fledged page, the concept remains the same. Add in very easy Struts 2 integration for both Velocity and Freemarker and thereâ€™s little reason to rely on JSPs to do anything.
I used Selenium as a functional testing tool and realized that I was falling into the pitfall of checking the content displayed on the page to test whether the correct business logic was being performed rather than whether the correct view was being returned (think about it, thereâ€™s a difference). If you use a templating engine other than JSP, you can quite easily test the former without having to resorting to a functional testing tool.
As AJAX is becoming more and more popular, JSPs are getting further phased out. Lot of developers prefer to return chunks of HTML from the server rather than an actual dispatched forward. A lightweight and powerful template language is much more suitable here as your AJAX interface view will be an aggregation of snippets of HTML returned from the server. Doing this using JSPs would add a level of complexity that is both undesired and unneeded.
Having said all that, you can produce the same product with both JSPs and other lightweight template engines, but the latter stay much truer to the MVC philosophy and result in a much cleaner code base.