Servlets.com

Home

What's New?

com.oreilly.servlet

Servlet Polls

Mailing Lists

List Archives

Servlet Engines

Servlet ISPs

Servlet Tools

Documentation

Online Articles

The Soapbox

"Java Servlet
Programming,
Second Edition"

"Java Enterprise
Best Practices"

Speaking & Slides

About Jason

XQuery Affiliate

Advertising Info

Reactions to "The Problems with JSP"
February 10, 2000

by Jason Hunter

Reader reaction to the article posted here two weeks ago titled, "The Problems with JSP" has been tremendous, generating around 100 messages on the public mailing lists (jsp-interest, servlet-interest, and the official webmacro list) and nearly another 100 more to me individually. This follow-on article showcases some of the most interesting points made during the discussion, for those who didn't get to read all the replies and to make public what people sent to the feedback alias. The results were a little surprising.

Posts were selected based on my opinion alone. Emails written to the feedback alias by people taking the option for their correspondence to remain confidential have not been quoted. (Too bad, there were some good ones!)

The Majority of People

The vast majority of people responding to the article have been supportive. Almost everyone writing appreciated the exchange of ideas fostered by the article.
John Keyes:
"I thank you for making people think about the reasons why they use certain technologies (which in a number of cases is because its a buzzword and not for functionality)"

Martin Jarvis:
"How great it is to find someone else sharing my doubts about JSP. Many of the projects I am involved in are all using servlet based templating framework that we have developed."

Robert Crawford:
"Interesting article -- I happen to agree completely, though I favor freemarker."

Doug Dominiak:
"I very much enjoyed your article. Well-written. I was not aware of some of the things you mentioned, and am glad that I am now."

Robert Fisher:
"I completely agree with the article "The Problems with JSP". For a while now, I've been trying to explain to everyone I know why JSP isn't the answer to separating code from content, but I haven't been able to articulate it as well as the article did.
I love JSP. I think it's a great technology for those projects in which mixing code and content makes sense. But, if separating code and content is your goal, JSP isn't the answer."
I'm slightly shocked to have received absolutely no flames, in either public or private correspondence. The closest I got was a joke. At least I'm taking it as a joke.
Anthony Nemmer:
"Why not just get rid of all that JSP servlet crap and use perl ? =)"
Boy, I hope it was a joke.

The Majority of Words

While the majority of people were supportive, the majority of words (especially on the JSP mailing list) have been defending JSP.
Josh Hunt
"I just got done reading your article on the problems with JSP. I am working on a project that makes heavy use of JSP. Although, I can agree with some of the things in your article there are a few that I disagree with."

Scott Stirling
"I got the point of the non-JSP alternatives being available and perhaps overlooked. I also got the one that JSP shouldn't be seen as the logical replacement for servlets. But I didn't like some of the red herring and straw man arguments used to try to bolster the points"

Govind Seshadri
"Interesting article...although I mostly disagree with the notion that using WebMacro is a 'great leap forward' compared to using JSPs and custom taglibs."

Ray Cromwell
"About the only positive thing your paper highlights is the need for a more economical iteration mechanism for containers, and perhaps, although it's borderline, a more economical syntax for variable interpolation. All the other benefits you assert are dubious."

Kevin Duffey
"Well, I dont much agree with your article, at least in the way of a template engine being a better alternative to JSP. I can see how in some cases it may make sense for those either too lazy or too unwiling to understand the JSP syntax. To me, a template engines syntax means learning a lot more than JSP syntax. Sure, you can mistype the <%! with <%, but if you learn JSP, you'll know when to use one or the other."
Most of the responses have been highly focused on whether JSP or WebMacro is superior technology. This debate misses the main question: Is it valid for the official "Application Programming Model" document published by Sun and a public record of Sun's philosophy to say, "JSP technology should be viewed as the norm while the use of servlets will most likely be the exception." (Section 1.9, December 15, 1999, Draft Release)? That's a radical statement, and I believe that should some combination of the servlet-based alternatives (WebMacro, FreeMarker, ECS/htmlKona, Cocoon, XMLC, XSLT, Turbine) provide a better solution and together garner significant market share, the statement can be determined to be false.

Why should we care if the statement is true or false? Because if it's true and JSPs are the natural follow-on to servlets, then we servlet developers can stop developing and using these alternative content creation methods and concentrate on JSPs. However, if that statement is false, then we should educate ourselves about what options are available and learn where each technology performs best. At the same time we should encourage the technologies to cross-pollinate, using the best ideas from each.

Because I believe the APM statement to be false, I'm glad to see the article has encouraged the debate over when JSP should be used and when alternatives should be used. There are a lot of alternatives to consider, as readers pointed out.

Govind Seshadri:
"Anyway, what is so special about WebMacro in particular? Why not use Cocoon, Turbine, Freemarker, OTembo or even ECS? They all offer similar features and I daresay, some of them are probably better supported than WebMacro."

Bill Thompson:
"Jason, excellent wrap up of where most of us are today! I'd like to throw into the mix another approach to generating html. Specifically, XMLC from the enhydra project. XMLC completely separates html from code, thus eliminating most of the problems you refer to for both jsp and template engines."

Stu Charlton:
"I really agreed with Jason's conclusion on this article as it reflects my professional experience with JSP. It winds up making your GUI very unmaintainable unless you invest a lot of resources in making a sophisticated infrastructure [which is what we did eventually - mapping JSP to business objects with reflection].
I would like to say that forthcoming servlet template engines REALLY COULD learn a lot from Apple's WebObjects. This product still provides (since 1994) the most flexible, high-performance, and CLEAN templating system that I've seen. It works so well that even HTML tools like Adobe GoLive support it.."

The JSP Standard

Overall, the most compelling argument made during the post-article discussion for why to choose JSP over WebMacro (and over all the alternatives) has been the power of the JSP standard. A common platform that's "good enough" generally wins over an alternative that's slightly superior; it's something called the "Network Effect" -- the success of a component (technology or otherwise) depends on the network of support infrastructure established around that component. Microsoft Windows is the classic example. VHS videotape is another.
Ann Marie O'Meara:
"JSPs are popular, they are widely-understood, there are nice tools to develop them, and other people can answer questions on them. I also do not feel that we are imposing on anyone by asking them to learn the JSP syntax, since it seems to be the emerging standard for server-side Java."

Nic Ferrier:
"I personally would not suggest using a non-standard tool for a big rollout project that is going to need continued support - as much as I would like to sell my clients my continued existance to support GNU-Weblook (or whatever) I can't. But JSP is clanky, we can improve it. We'll only do that by talking about and experimenting with new ideas."

Craig McClanahan:
"If people like WebMacro, go for it ... in this particular case, I'm going to stay mainstream on the projects I manage."
...and...
"I have to wear my 'project manager' hat as well, and say what's best for the overall product. In many cases, that means mainstream technology choices, quite independent of technical 'elegance' or 'beauty.'"
For the counter-argument, in response to Craig...
Robin Meade:
"Agreed. But how does a fledgling elegant technology ever become mainstream? Early adopters try using it, like it, and help give it some recognition. I believe this is what Jason Hunter is doing, and I thank him for it. Once developer interest reaches a critical mass, the technology quickly matures and becomes maintream."

The Difficulty of Leaving a Standard

Leaving a standard can be a difficult business case. Selling people on a technology they know nothing about is an uphill battle. For example, some people were uncertain on the portability of WebMacro:
Kevin Duffey:
"I can't say if a template engine such as WebMacro exists on multiple platforms or not, but I would imagine JSP/JavaBeans/Java has a much wider range of platforms and far more support in app servers and web servers."
I found this post particularly interesting because WebMacro works on more platforms than JSP.
Jason Hunter:
"JSP doesn't work fully in Servlet API 2.0, which is what Apache/JServ supports. And the specific portion that's missing is the RequestDispatcher part that allows you to do the separation discussed above. Plus, JSP 1.1 support is very spotty and each vendor has their own bugs you have to work around. There's something nice about WebMacro working with the older Servlet API 2.0 and without any vendor-specific bugs. There's just the one open source implementation to fix bugs in. Kinda like Perl."
In the end, however, the truth doesn't matter here as much as the perception -- JSP is a standard, managers trust using standards. You won't get fired for using JSP.

Dictating Style

Because of the "network effect" around the JSP standard, JSP should remain the dominant servlet-based technique for generating content. However, JSP has not been widely perceived as a "sure thing", as servlets were. I personally have never heard from anyone who learned servlets and decided they weren't useful. Yet lots of people have used JSP and felt it didn't satisfy.
Geoff Soutter:
"If someone at Sun had had their thinking hat on they could have made a much nicer version of JSP by giving up on M$ "compatibility" and making the following changes:
- a tag library from the start, with standard tags for looping, etc
- simple syntax for accessing variables, etc in HTML without resorting to overly complex XML stylee
- NO java code allowed to be embedded in the HTML!
- avoiding "compiling" JSP pages into class files (not necessary when no java code)
This much was obvious to me anyway 18 months(?) ago when JSP 0.90 was released: I looked at it and went: "sigh". It's weighted far to much in favour of developers.
To my mind: it should be like so:
- JSP (or similar) is for HTML people
- Servlets / Beans are for Java developers
For those who are interested in such things: Anders Kristensen published a paper a couple of years back that describes a JSP-alike system which would have been a much better starting point than ASP!
http://www-uk.hpl.hp.com/people/ak/doc/trix-tr.html
This is maybe a good halfway house between a full template based system ala WebMacro and the current JSP....?"
But then, what one person would prohibit, another will depend upon.
Ray Cromwell:
"some of us like having the full power of Java available in JSP"

Runar Oli Bjarnason:
"But that's the whole beauty of JSP. The ability to embed ANY code directly in the HTML."

Ray Cromwell:
"Well, given the extreme popularity of Cold Fusion, I'd say they would prefer the XML syntax. In fact, I know designers who worked on both a WebMacro-like template language, and on Cold Fusion projects, and they preferred Cold Fusion syntax."
Perhaps the difficulty is that when you move to the "high" level of JSP, you must start dictating architecture. Servlets are a generic platform, a blank canvas and a set of paints. You may do with them as you will; everyone can agree to use servlets. JSP builds an architecture on top of servlets, and because of that dictates to some extent how pages are created.

Yet there are alternatives. WebMacro uses a style that's similar to JSP "Model 2". ECS uses a drastically different approach creating a page as a set of Java objects. Turbine uses a central servlet dispatcher. Cocoon and XMLC use XML for content creation. Different styles work better under different conditions. JSP dictates style. Style is a dangerous thing to standardize.

Tools to the Rescue?

In response to "Problem #3: Simple Tasks are Hard", several people pointed out that tools will make these tasks easier.
Hans Bergsten:
"I'm pretty sure that the majority of the web sites we see today are developed with tools like FrontPage, NetObject Fusion, DreamWeaver, etc. rather than by people hacking HTML in a text editor. The custom action model lends itself very well to tool support"
That's probably true. However, others pointed out that not everyone (like Linux and Solaris users) will have access to or will want to use tools.
Robin Meade:
"I suspect that a template tool with elegant syntax will be favored by those who prefer using text editors over visual tools for text markup. Programmers tend to fall into this category, as well as a significant portion of html designers.
JSP syntax, as it stands now, IMHO, is a drag to learn, type, and look at. Discussions like this may help expose this as a shortcoming that could be addressed. Perhaps something like the <wm:webmacro> tag that you suggest below.
Or maybe JSP's verbose, unsightly (IMHO) syntax will relegate it to *only* being manipulated by tools. If so, that leaves a sizeable niche in the server-side java community for a decent template tool with a simple, elegant syntax."

Do We Need a Compiler?

In response to "Problem #6: Need a Compiler", a new fact came to light.
Hans Bergsten:
"Sun has allowed ASF to redistribute the javac compiler, in a separate JAR file as opposed to the complete tools.jar."
Unfortunately, for right now Tomcat has yet to bundle tools.jar, and other servers don't yet have the same licensing agreement. Yet this holds great promise for the future.

Is Space an Issue?

In response to "Problem #7: Wasted Space" some disagreed.
Hans Bergsten:
"Yes, the class files take up disk space. But disk is cheap, so I don't see this as such a big deal. Regarding the difference between memory usage between JSP and template systems, I'm not convince the difference is so big. I assume that for a high performance site you would end up caching all templates, which would require roughly the same amount of memory as JSP class files. But even if you're right, memory is also cheap."
And some agreed.
Ethan Henry:
"I think that the lack of class unloading/reloading is the major factor that will keep real sites from using JSPs."
Perhaps the issue can be declared moot if JSP implementations take advantage of the following.
Ray Cromwell:
"the class file need not embed the String constant pools, but can actually store offsets into the JSP source file, and read them at run time. I have a hack to GNUJSP that does this. The resulting class files are much smaller, and *do not* occupy class-heap memory, so that with a little change, the static String data can actually be GC'ed and re-read as needed (by using SoftReferences)"

Where are We Today?

So where are we today? Are we any better off than we were two weeks ago before the article? I'd like to think so.

The article pointed out seven things that at least some people believe are problems with JSP. Because of the article, some of these, such as the memory consumption issue, have been discussed and proposals made for how to avoid the problem with better implementations. The open discussion has helped improve the technology.

More importantly, at least in my mind, awareness has been raised that there are alternatives to JSP. People are downloading and trying WebMacro. They're checking out XMLC (http://www.enhydra.org, http://staff.plugged.net.au/dwood/xmlc/index.html), Cocoon (http://xml.apache.org/cocoon/), XSLT (http://www.xslt.com), ECS (http://java.apache.org/ecs/), and the rest. They're looking at JSP not as a "sure thing" servlet follow-on but as one good option.

My biggest concern has been the promotion of JSP at the expense of the alternatives. Considering the indisputable fact that not everyone who likes servlets likes JSP (whether or not they "should"), I'm worried that people who are not yet in the "servlet camp" may try JSPs, find themselves dissatisfied, and not realize that perhaps XMLC, Cocoon, ECS, or another of the servlet-based alternatives would work great for them.

Servlets are the common platform, like TCP/IP. JSP is likely to become the most popular technology built on that platform, like HTTP. But neither JSP nor HTTP works best in all situations, and maybe not even most situations. With any luck, you the reader can help ensure that other servlet-based technologies get a shot at some sunlight.


This is the second in a series of articles. To be notified when new articles are added to the site, subscribe here.

Care to comment on the article? Fire an email to talkback@servlets.com. Interesting comments may be posted unless you specify otherwise.

 


Home   com.oreilly.servlet   Polls   Lists   Archives
Engines   ISPs   Tools   Docs   Articles   Soapbox   Book

Copyright © 1999-2005 Jason Hunter
Privacy Policy

webmaster@servlets.com
Last updated: March 1, 2009