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.


  1. So how do you render the HTML part once you've binned the tag library?

  2. your client side code figure 3 slide is wrong. You should be performing a GET

  3. Although I've specifically only advocated against JSP tag libraries in my post, by extension the JSP expression language (EL) and JSPs themselves no longer serve a useful purpose. And, as we know, Spring MVC makes it unnecessary to explicitly create servlets to handle the various URLs we wish to intercept. But perhaps that's the subject of a separate post. As for HTML rendering, I recommend you use HTML, CSS, JavaScript, jQuery etc for that. All we're doing above is replacing the data binding mechanism (JSP tag libs are being replaced with Java-to-JSON binding, courtesy of Spring MVC).

  4. I took the code snippets from a working example I created. And POST worked fine for me. You might be recommending GET in order to be REST compliant. However, many organisations don't allow data to be passed in the URL for security reasons. Also, the amount of data you can pass via a GET is a lot smaller than what a POST will permit.

  5. "most Java web applications have used JSP tag libraries as a client-side mechanism"

    wait.. client-side? jsp-tags are part of a jsp page which are transformed into a servlets which are server side.

    Directly returning json is a perfectly fine approach but as Anonymous points out you still need a way of describing how the data(JSON) should be rendered on the client, since bigger sites will have different layouts for different pages there will be repetitive code(html/js/control flow) that you should probably stick in a tag to keep it DRY.

    JSP-tag's and JSON are hardly competing technologies 'ditching' one for the other seems like a weird thing to contemplate.

  6. Michael, JSPs were created as a client-side facility to allow UI developers to have one place where they could access data from Java objects (EL, JSP tag libraries) and place the data into the desired HTML elements all in one go. I've acknowledged in my post that JSP are converted into servlets -- that's how they are able to access data from server-side Java objects. Once you're got your hands on the data (via EL or JSP tag libraries or JavaScript) you still need to place the data into the desired HTML elements. When using the JSON channel, jQuery offers elegant mechanisms for placing the data into HTML. And, if needed, JavaScript can certainly be modularized into reusable code so that should be no challenge to the DRY principle.

    Some of my colleagues were also having trouble wrapping their heads around my recommendation. While other colleagues were agreeing with me wholeheartedly. So, I figured I'd write this post to see if anyone could point out a serious gap in my thinking.

    Thanks for engaging but so far you have not caused me to revise my recommendation. For now, the only exception to my recommendation that I can come up with is in the case of the Spring Security tag library. But I'm not done thinking through that one yet.

  7. Jsp tags are definitely useful where we want to make decisions based on session data . For example let us say i am storing user entitlement in session and i do not want certain data to be loaded / or want certain data to be loaded etc since i have access to session data i can so this easily in the jsp. Why delay it it page loads and make an extra ajax call for this ?

  8. Noms, that's an interesting use case, but it doesn't necessarily imply a dependency on JSP tag libraries. Since the session is available on the server-side, the server-side code can either (a) inspect the session data and determine what to make available in the model based on user entitlements/authorizations/roles or (b) include the relevant session information in the model so that the client-side code can use it to make decisions on what data to display/hide. Option (a) should be the preferred option.


Post a Comment

Popular posts from this blog

My Experiments with the PICAXE 08M2+

Utility trailer buying guide

How to Select and Install Shelves