Related link: http://java.sun.com/products/jsp/

I’ve been working (again) on taking a project from HTML to JSP, and doing so reminds me (once again) how completely horrible JSP is.

JSP has this nice impulse to take Java code out of HTML pages and put it into JavaBeans or other Java classes, where it belongs, so the HTML author doesn’t need to know Java. Great, that’s great. Unfortunately, the “not Java” that is included in the HTML page is completely alien to (most) HTML authors, that it might as well just be Java for all they know or care. So I have to put <exec:iterator condition=”<%= shopBean.validate() %>”> right here, or nothing on the page will work? Yeah, okay. How do I test that again?

The result of this is simple and stupid: once again my UI engineers will be taking perfectly good HTML written in Dreamweaver and tearing it apart, throwing out some of it and rewriting other parts of it, just to make it work with the JSP they’re writing. Once they’re done, the HTML author will have absolutely no clue what the page does any more, and will have no desire or ability to edit it. When we insist that no really we need this redesigned, we’ll spend twice as long doing it (doubling our costs, negative ROI, bad technology choice, yadda yadda yadda) since the HTML author will need that long to write in sample data and then have the JSP author tear it out again.

This is completely stupid. It’s as if your compiler tore up your source code every time you compiled, and you had to go back and reverse engineer your source again in order to change the binary. Stupid! JSP is only an effective solution when the JSP author is also the HTML author.

I want something different. (Yeah, yeah, I know. HTML templating languages are one of the most over-implemented pieces of code ever. Every single Web design shop, tools vendor, large Web site operator, and two-bit commentator like me has their own stupid solution to the problem. I’m tilting at windmills. I’m wasting my breath. Whatever. The reason there have been so many solutions, and there continue to be so many solutions, is because the problem is still completely broken. It wastes my time and the time of the people I work with and I still want it to be better.) I want something that lets HTML people write and keep their source code in their favorite tools, adding dummy data and seeing how it looks, and lets them add hooks for the Java coders in a way they’ll easily understand.

This general problem — separating markup from other kinds of document information — was handled very well by Cascading Style Sheets (CSS), which separate document markup from stylistic presentation information by linking the HTML document to an external style document. CSS did this by adding very minimal changes to HTML itself — namely the “class” and “id” tag attributes — and putting almost everything in the stylesheet.

I think what’s needed instead of stupid JSP is exactly the same type of solution for separating code and HTML. Give me a “code” attribute that I can add to any HTML tag, and overload the “id” attribute. Have the value of the code attribute be an opaque string referring to a codesheet, linked to the HTML document by a a ‘<link type=”text/ccs” rel=”codesheet” href=”code.ccs”>’ tag. Have the codesheet use a CSS-style rules specification for indicating which Java (or whatever) class should consume tags with that code or id attribute. Then tell the HTMLer to add the “code” and “id” attributes to the right place in their existing documents, and they’re done.

What’s important about this is everything it doesn’t try to do:

  • It doesn’t try to handle class or method namespace collisions in the HTML document — no need for clumsy and confusing XML prefixes. (Instead, namespaces are managed in the codesheet, centrally named for the whole site.)
  • It doesn’t try to let the JSP taglib author create whatever kind of tag they want, confusing the hell out of the HTML author and the HTML author’s tools. (Instead, the tagset is defined by the HTML standard the HTMLer already knows.)
  • It doesn’t require the HTML author to have a JSP environment in order to author their pages. (Instead, they can put in sample, dummy data to see how the page will look when the code is running, and the Java coder can discard that data on the code side.)
  • It doesn’t bind the HTML document to any programming language or paradigm. (Instead, it keeps the author to HTML, and lets the codesheet swap out implementations without changing the HTML.)
  • It doesn’t require the HTML author to learn anything new in order to move from a static site to a dynamic site. (Instead, they can use their familiarity with CSS to understand the transition.)

I know I’m glossing over a lot, but I think this is the right model. Has someone already done this? I’d love to see it, if so, that I might boot JSP out the window as it so richly deserves.