JSP Sucks
The first time when I used JSP was in 1999, with WebLogic server. I used a “cookbook” approach: make a JSP, deploy, test, enhance it, and so on – what’s called “rapid development”. My understanding of HTTP and DOM was poor. That’s my excuse to having used it in the first place. Back then there were plenty of thick books on J2EE, and JSP was practically the only JAVA technology for rendering dynamic web pages. It was hard to argue that the pros of JSP must outweigh the cons. Let’s recall what the claims of JSP are:
- Easy conversion of legacy HTML pages to dynamic pages;
- Separating code from presentation;
- Ability to extend JSP language via tag libraries.
But before I go into dismissing those claims, I will describe my point of view on software design.
The Biggest Design Flaw
The biggest design flaw you can have in a program is code duplication. Source code is for humans to read. A typical program or module includes tens of thousands of lines of code, which is equivalent to a thick book. In literature lessons, they teach you that repeating your thoughts is bad, and so it’s bad to repeat code, including comments.
Another, stronger reason why code duplication is bad is because the thought process during code writing includes a great amount of generalization. Generalization is a fundamental component of human intellect. In fact, human languages have been evolving together with advances of human intellect by adding the words representing generalized or “abstract” terms. If our language didn’t have words such as “circle”, “food”, “vehicle”, we could still communicate, but our communication would have been much lengthier and confusing. Duplicated code reflects the lack of generalization during programming process. The programmer, who repeats the same code over and over, fails to generalize those pieces of code. Then the people who read duplicated code will have to spend more time understanding it because they would have to perform the generalization process themselves, essentially doing the job that the first programmer failed to do.
And now we come to the third reason: maintenance. When it comes to maintenance of a program, duplicated code is the killer. Here is a typical life story of a program: it’s designed with the ability to be extended. But when the extensions are written, there is no more design, and therefore lots of duplicated code. During maintenance, every piece of duplicated code needs to be carefully changed and separately tested. And then, the system becomes too expensive to maintain. It is illustrated by the chart below.
I have to admit, most software projects go this route. However, a program’s life can be shorter or longer depending on how good the framework is, and how much attention is paid to enhancing the design while writing the extensions. Every decision to write duplicated code instead of re-writing existing code shortens the life of the program.
JSP and Duplicated Code
Everything said above has direct relationship to the title of this article, because JSP technology doesn’t just promote duplicated code, it EQUALS duplicated code. Let me prove it to you.
First of all, any Java code that resides in a JSP page is not reusable, period. If you ever need to design a similar page, it’s much easier to cut and paste that code, than remove it from the original JSP page and put it in a Java class.
Does it contain <html>, <head>, <body> tags? If yes, it’s code duplication. Do any tags that you use contain any formatting, or JavaScript handlers attached to them? If yes, it’s code duplication because I am sure you use the same tags with the same formatting attributes (CSS is not an exception) in other JSP pages. Does your JSP page contain other repeated sets of nested tags perhaps with different parameters? If yes then it is code duplication.
This leaves only custom tags. Indeed, the only way to avoid code duplication in JSP is to make it consist of only custom tags. But that would defeat the first claim of JSP, “Easy conversion of legacy HTML pages to dynamic pages”, because writing custom tags for the legacy HTML pages means practically re-writing them.
Separating Content and Presentation
In order to achieve separating content from presentation, a JSP page must not contain any Java code. In practice, it requires a great deal of discipline to do so because all JSP books and tutorials teach you how to mix Java code with HTML. There are in fact advocates for this approach. The only way to populate a data table without using a Java loop is to use custom tags. The Standard Tag Library, JSTL, defines such tag and many other tags exactly in order to avoid using Java code in JSP. Here is a quote from JSTL home page:
“ JavaServer Pages (JSP) technology makes it easy to embed bits of Java code (or scriptlets) in HTML documents. This solution, however, may not be suitable for all HTML content developers, perhaps because they don't know Java and don't care to learn its syntax. To serve these HTML developers, you can introduce custom tags through the JSP Standard Tag Library (JSTL 1.0), which can be deployed and used in an HTML-like syntax.”
Okay, perhaps you can find a web designer who will use JSTL tags in the JSP pages that he/she will write, and Java developers will just write Java Beans. But what about text? Menu names, copyright, column titles, whatever else static text needs to be displayed on the page? If your web app needs to be localized, no text should come with the page from the HTML designer. But then visual design tools become kind of pointless.
Also, how would an HTML designer create reusable elements? Fancy borders, fancy buttons, fancy menus, fancy whatever. It all needs to be reusable. Because it’s not possible, HTML that comes from the HTML designer contains a lot of duplicated code, with all the consequences. And CSS is not a panacea, because in CSS you can’t define JavaScript event handlers, you can't specify the tag used for rendering the element (for example, whether to use an <a> tag or a <button> tag), and some attributes simply don’t have CSS equivalents (example: cellpadding and cellspacing).
To be fair, there is <jsp:include> using which big page elements, such as “masthead”, “navbar”, and “footer” are made reusable via JSP include directories. But using “include” for fancy borders and buttons just isn’t practical. There is even a more “advanced” way to include those “mastheads” and “navbars” intended to avoid duplicated code for page layout: Tiles. But because a “tile” is not a fully-functional HTML document, you can’t use traditional visual design tools for JSP.
Tag Libraries
As it was mentioned above, a good JSP page should contain only custom tags. Essentially, it becomes an XML document. Does XML need to be compiled? Would pre-compilation bring any benefits at run-time? Perhaps, but not in the case of JSP. When you use a custom tag, JSP compiler doesn’t call your tag class to render the corresponding HTML tags, it just places a call to your custom tag class in the generated JSP class.
The conclusion: if you’ve managed to design your JSP pages with only custom tags then there are better technologies that you could use instead, but that’s another story.
posted by Roger Wilco @ 3:57 PM
0 Comments
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home