October 23, 2016
Hot Topics:

Where to Point Your View -- JSP or XSL

  • July 3, 2002
  • By Jeff Ryan
  • Send Email »
  • More Articles »

What Do the Approaches Have in Common?


Both the JSP and XSL approaches clearly separate presentation from business logic, data, and user actions because these advantages are inherent in MVC. This makes maintenance easier. It also allows for focused developer roles and parallel development that helps larger projects to scale better.

Industry standards

Both approaches are also based upon industry standard technology. This means that you will be able to find developers to maintain the system, and you will have vendors competing to supply the tools and platform to build and run your application. There are also many open source tools and platforms as well. There are plenty of books and training available in both technologies.

Tool support

Both approaches have tool support to aid the development process. JSP Tag library support is beginning to show up in third-party tools that allow you to graphically build the markup. XML IDEs speed the development of the XSL.

What Differentiates the Approaches?

Parallel development

I find that XSL makes parallel development easier. Once the XML data format has been agreed upon, a presentation developer can completely build the XSL view markup through an XML IDE without even needing a servlet container to construct and test the code. A XSL developer does not have to know Java. It is very easy to integrate the view with the rest of the application when ready. With a JSP view, this could still be accomplished by creating a "stub" object to stand in for the model, but it doesn't lend itself as naturally to this approach.


If your data is already in XML format (which it often is), it isn't necessary to parse the XML and transform it into objects. The XML can be transformed directly by the XSL view. When a result set is a complex tree structure, it may result in many value object classes often built for the sole purpose of communicating the data to a JSP view. This can be a time-consuming task and creates many temporary objects to be garbage collected.

Modular code

In a XSL stylesheet, it is possible to modularize the routines (called templates) for creating your markup language and make your routines rule based. I find that it is much easier to maintain than a JSP. It is still possible to build your markup in a procedural fashion and care should be taken in making the stylesheet as maintainable as possible.

It is possible to write your entire application, not just the view, in a JSP. The developer must be very conscious of the responsibilities of the view and not cross over into the responsibilities of the controller or model, for that matter. XSL, on the other hand, is pure presentation and forces decoupling of presentation and data.


One interesting difference between the two approaches is that XSL code and the skill for crafting stylesheets is portable between the .NET and J2EE platforms. The same couldn't be said for JSP. I would think that there will be more third-party tool support for XSL since there is a broader developer audience, but we'll have to see how this plays out.


Even though you can potentially create fewer value objects, XSL will perform slower than JSP. However, the Java Transformation API for XML (TrAX) allows stylesheets to be compiled, dramatically improving performance.

Comparision Matrix

The following table summarizes the above discussion on what the approaches have in common, and what differentiates them.

Attribute JSP View Approach XSL View Approach
Based on industry standards Yes Yes
Separate business logic and data from presentation Yes; however, it is possible to cheat in your JSP Yes

Tool Support Yes Yes
Modular Code You can modularize with includes and tag libraries, but it is very procedural. The JSP gets compiled into a single (often huge) Java method. Rule-based templates are very modular and easy to maintain. However, you can cheat and build your stylesheet in a very procedural fashion.
.NET Portable Skill and Code No Yes
Performance Excellent Generally acceptable. Can be optimized.
XML Model Yes, but you need to parse the XML yourself Very easy
Parallel Development Yes, with some effort Very easy

Page 2 of 3

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel