Are JSP tag libraries still relevant?

Figure 1

Figure 2

Figure 3

Figure 4

Dump JSP tag libraries and switch to JSON.

I often see development teams using JSP tag libraries when they shouldn't be. I wrote this post to explain why it's best to view JSP tag libraries as relics of the past.

Most non-trivial web applications store data in a database on the server side. These applications need mechanisms that allow the clients (web browsers) and servers (e.g. Java application servers) to exchange data. Typically, either a) data needs to be displayed for the user (so, the client sends the look up criteria to the server and the server responds with the relevant data) or b) the user changes data in the browser and the client needs to submit the data modification to the server for processing and/or permanent storage.

Until recently, most Java web applications have used JSP tag libraries as a client-side mechanism to extract data out of Java objects (JavaBeans) passed back and forth between clients (web browsers) and servers as part of the JSP/servlet paradigm offered by Java. (Note: JSPs are HTML files that get converted into Java servlets so that they can contain Java code for manipulating server-side Java objects.) In each case, the server responds with a new page (with embedded data), also known as a full page refresh.

In 1995, AJAX came along and changed the full page refresh paradigm described above. AJAX allows for partial page refreshes and data exchanges between the browser and the app server without having to do full page refreshes.Since then, AJAX has continuously gained momentum with support built into popular frameworks like Spring (for Java) in v3.0/2010 and jQuery (for JavaScript) in v1.5/2011. 

The data exchange format that works best with AJAX is JSON, since JSP tag libraries cannot be invoked unless a full page refresh is involved. There are several options for mapping between the server-side Java model objects (JavaBeans) and JSON, which can easily be consumed by JavaScript running in the browser. (Note: Since JSON is the literal representation of a JavaScript object, the conversion from JSON to JavaScript object is trivial.) The option I recommend and have been using is Spring MVC's @RequestBody and @ResponseBody annotations as part of the controller method definitions (which leverage the Jackson library for JSON processing) to automatically map JavaBeans to JSON and back (see figures 3 and 4). (The alternative is to use a proprietary framework like Direct Web Remoting or DWR, which I do not recommend for obvious reasons.)

As a result, I recommend to most teams I consult with that it's best to abandon JSP tag libraries entirely in favor of a pure AJAX/JSON based approach.

Here's a summary of the reasoning behind my recommendation to use AJAX/JSON exclusively (even for full page refreshes).

1. Unless, you have a very simple application, you will likely need to support partial page refreshes using AJAX (rather than do a full page refresh each time that some data needs to change on the page). To do so, you need to map between Java objects (JavaBeans) and JavaScript objects (JSON) in order to exchange data between the browser/client and the application server. Therefore, it probably doesn't make much sense to support two channels for data exchange (JSP tag libraries for full page refreshes and AJAX/JSON for partial page refreshes). And if you have to pick one it has to be AJAX/JSON, since JSP tag libraries don't work for partial page refreshes. Hence, my recommendation to go head first with AJAX/JSON and abandon JSP tag libraries. But if you need more incentive, please read on.
   
   
2. I have worked with teams that have analyzed the size of the data being shuttled back and forth across the network and found that JSON consumes a lot less network bandwidth than the JavaBeans/JSP tag library approach or even XML payloads. Their analysis seems to make sense to me since JSON is a bare bones pure text format without the syntactical overhead involved with XML or the rich object overhead involved with JavaBeans.
   
   
3. Relative to the acrobatics required for manipulating JavaBeans using JSP tag libraries (see figure 1), the JavaBeans to JSON mapping is completely seamless with Spring MVC and requires no coding whatsoever (see figure 2). Whether or not you're using JSP tag libraries, chances are that you need to populate JavaScript objects with the data in order for the data to be consumed by jQuery widgets. In other words, the JavaScript object(s) are required in regardless of whether you use JSP tag libraries or not. Abandoning JSP tag libraries allows you to skip step 2 (see figures) and go straight to JSON and the corresponding JavaScript object(s) without having to muddle through the manipulation of JavaBean objects using JSP tag libraries.

Thanks for reading. I hope I've made my case adequately. However, I'd like to have your feedback, especially if you believe I've overlooked something.

Share this post