Why JSPs are a bad idea

It's pretty much accepted wisdom these days that no-one uses JSPs in the way they were originally conceived. We used to use a <jsp:bean tags to create or find a Java object, and then use scriptlets - little snippets of Java enclosed in <% and %> symbols - to insert data into the page, or to implement some basic logic. After many spaghetti JSPs had been written, it became clear that passing a web request direct to a JSP and programming that one JSP to deal with all possible complications was a really bad idea. It produced brittle web applications that were hard to fix and even harder to extend.

Nowadays, most people use some kind of MVC architecture. Instead of each web request being passed directly to a JSP, it is passed a handler, be it a servlet, a Struts action, or whatever. The handler, written in Java, deals with the request and decides what needs to be done. It retrieves the necessary data, and then invokes a view to create an HTML page. There are various ways of implementing views, but by far the most common method is to use a JSP. The data is attached to the request object using the setAttribute method, and the request is forwarded to the JSP, which retrieves the data either using scriptlets (not usually recommended) or via a tag library, such as JSTL or the Struts 2 tag library.

In my view, JSPs are a bad idea even for this limited usage. They have numerous problems, most of which could be fixed with better implementations (why, after all this time, can't an exception generate a stack trace giving you the actual line number in the JSP?), but there are two fundamental problems:

1. each JSP is tied into the web application framework as a web page. That means you have to use something else to generate e-mails, for example, or any other templating task you may have. It also means that common features of your dynamic web pages, such as setting a charset encoding or cache-control, need to be repeated in every page. There is no way to specify these things once and have them honoured everywhere.
2. there is no workable provision for re-use. You have two choices: use an include file (static or dynamic), or take the repeated code out of the JSP language altogether by writing a tag library.

Include files are incredibly primitive. They offer no way at all to manage data coupling between the included code and the page that calls it, so they are best restricted to situations where the included code has little or no data in common with the calling page.

Writing a tag library is hard work, although for code that will be re-used often, it's worth it for the clean interface and documentation features. What it doesn't do is to give me the quick, simple re-use that I can get in Java. If I'm writing a Java method, and I realise that what I need is something I've already written, my IDE (Eclipse or IDEA) can easily convert a fragment of Java into a method I can call. Most Java programmers will have heard of the DRY principle: Don't Repeat Yourself. Ensure that common functions are implemented in common code, so that when you have to fix them, which you will, you only have to fix them once.

Exactly the same thing applies to HTML coding. Web users expect consistency. For example, your website might display a product image with the product name below it, plus various other features: a hover effect with a short description and a hyperlink to the full product page. The important thing is to make sure that every time a product image appears, exactly the same features appear. The best way to do this is to use the same code to generate it every time.

Using an MVC framework lets you use other tools to generate views. There are tools adapted to this specific purpose, such as FreeMarker and Velocity, both of which address the two issues just described, and either of which is a great improvement over using JSPs. Generic, multi-purpose tag libraries such as JSTL and the Struts 2 tag library are a valiant effort to patch up the defects of the JSP system, but even they cannot overcome the most fundamental problems. The JSP system is broken, and there's no longer any need to use it. There are better alternatives.