The problem with JSP - a misleading article...


General J2EE: The problem with JSP - a misleading article...

  1. I found this article on Problem with JSP.

    I really wonder, how distracting is it put an outdated article on the front page if the site ( dated January 25 2000).

    What purpose does this server the java community other than creating a bad impression to the new entrants to the java world and the java bashers..

  2. The article is old but the opinions are still dead-accurate.

    Although JSP tags have come a long way in the meantime, the basic problems of JSP: akward syntax, easy things too difficult, reliance on code generation ... those haven't changed at all.

    Much of the premise is: if you have a servlet performing the most of the work, then using a JSP just to render the response is overkill.
  3. I think many of the points in the article are still valid.
    - JSP syntax awkard for non-Java programmers
    - standard GUI-related activities require programming skills(anything that requires dynamically-sized GUIs, like tables, lists, etc).
    - doesn't "know" the structure of it's output format: may not matter much for the forgiving HTML processors, but for XHTML, MathML, WML, etc this is a real pain.

    I think the stuff related to pre-compilation and space consumption is really off the mark. I would say it is deprecated, but I don't think it was ever nearly as important as this article describes.
    I also don't especially like the article's solution to the problem: how is that scripting language some much better than Java? Maybe for the author, who is used to it, it is. But it is still a procedura-style language that most web designers don't know. And it's probably slower than JSP, too.

    I using XSLT as a replacement to JSP can be fruitfull in many cases. It is a standard markup language for transforming XML, and many web designers know it. It "knows" the output format and therefore can provide much more extensive "compile-time checking" (e.g, check proper nesting of output XML). It also has a less "procedual" style that's probably easier to learn, atleast if you are not allready a programmer. Of course XSLT isn't perfect either: there is no standard way to access your DB contents and Java objects as XML from XSLT, XSLT is currently slower (although projects like XSLTC may help here), DOM and SAX as an input to XSLT is far from perfect (requires a lot of number parsing, etc), and XSLT is not flexible enogth (yet).


  4. JSP Custom tags is the answer for all these. The non-java programmer needs to know only them.

    If someone needs a ready-made set of custom tags. The solutions like Jakarta taglibs is a good way to go. And now, that Sun is standardizing the tags ( JSTL ) its going be a lot more easy.
  5. I don't think cutom tags address all these issues. For one thing, it doesn't know it's output format. But more importantly IMO, there shouldn't be custom taglibs for abstract notions like iteration on a set. Having such "generic" taglibs would simply turn the taglib into a new programming language, one that is unfamiliar to both un-trained Java programmers and un-trained web developers. I think going with a standard language instead (XSLT) is a better option.