Summary
In a recent blog entry, Kohsuke Kawaguchi explains why he switched from JSPs to Jelly in the open-source Hudson build system.
Advertisement
Kohsuke Kawaguchi develops Sun's JAXB 2.0 implementation. In addition, he is also project lead of the java.net Hudson project, a continuous build monitoring and integration system. He had been using JSPs in Hudson, but has lately become frustrated with the compromises JSPs forced upon his design. In his latest blog post, Hudson 1.40 and why I eventually said bye bye to JSP in favor of Jelly, he notes that:
I've never been truly happy with JSP (and consequently any technologies built on top of it, including JSF and things like that.) It felt very anti object-oriented, because in JSP and their siblings, pages are always the king and the data is the servant. You write, say, /showProduct.jsp, then give the data as the parameter, maybe like /showProduct.jsp?id=513. This always remind me of writing C code, where you'd say printProduct(513) where the parameter is int used as the product ID. I thought we are all supposed to program in the Java way, that is product.print() where 'product' is the object that perhaps gives you product.getId()==513.
He points out that a page-centric, as opposed to a data-centric, view of JSP makes developing data-aware Web applications difficult:
The first reason why it matters is because the Java way allows you to overload method/JSPs. Even in the web app it's pretty convenient to overload views—you'd want to show a different page for displaying book details and CD details. So depending on the kind of product 513, you'd want to use different JSPs. The 2nd reason why this matters is because it hides the identity of the object. In the Java way, I don't need to know that the product is actually identified by a single integer, while C way forces me to expose it. In reality, you do it a little better in C by using a structure and a pointer, but in JSP you'd have to pass in all the "primary keys" explicitly.
In addition, he also encountered problems with JSPs' speed during development:
Containers are often very slow to reload JSP pages. It seems to be particularly bad if you have a lot of tag files, and I guess stapler's creative/abusive use of JSPs wasn't helping the reloading performance either. It was apparently because every JSP page and every tag file is compiled into its own class, by using javac. Even when javac is run within the container process (and some don't even do that), it's still painful 3 to 5 seconds. When you are just making color changes or something like that, such a delay just turns you off.
After a few similar frustrations, he decided to convert the pages in the Hudson project to Jelly scripts:
The page reloading got a lot faster, although probably rendering speed is slower. I don't think my users would mind that at all, because it's not like we are talking about 10 hits per second, and most latency is network origin anyway. A nice side-effect was that JEXL that replaced EL (Jelly uses JEXL) is more powerful, and I no longer have to define a stupid one-line JSP function and write all taglib.tld just so that I can invoke Set.contains.
JSP is a terrible tool for building web pages; so are almost all of the other web programming frameworks.
Programming language designers had decades of experience before discovering that object-oriented programming was better than everything else that had come before, and yet, all of that insight was abandoned when it came to the design of web frameworks. People imagine it to be a great design achievement when business logic coded in Java is separated from presentation logic coded in some sort of HTML-like tag-file notation. The ooh and ahh over standard tag libraries that allow us to embed C-like control structures into our HTML pages. But if object-orientation is so useful for coding business logic, why wouldn't it be equally useful for coding presentation logic? Yet, I see nothing object-oriented about HTML -- whether or not it is supplemented with purchased, custom-built, or standard-library tags.
Before adopting any web framework, a programmer should ask himself these questions:
(1) If I, the user, need a configurable panel of visual components which react to each other's events in a standard way, to be instantiated on each of a number of web pages, what facilities does the framework offer for defining this panel as an assembly of arbitrary visual sub-components (e.g. sub-panels), and deploying it as a re-usable object? This is not rocket science -- all we're doing is building a class that nests and links GUI objects.
(2) If half the configuration properties of my re-usable panel class have the same value on a large number of my web pages, what provision does the framework make to allow me to create a simpler façade to this panel that sets these default values for me? This shoiuld be no big deal in an object-oriented language -- all I should need to do is create an extra constructor that feeds default values into some of the parameters, if necessary by creating a subclass that calls the parent's constructor using the default values.
(3) If the other half of my instantiations require additional or more specialized behavior from this panel, what provision does the framework make to allow me to subclass this reusable, configurable panel, inheriting the behavior of the parent class?
Object-oriented programming is not new, nor is it even controversial anymore, so why aren't we using object-orientation in the coding of webpage presentation logic? I guess it was difficult figuring out how to translate an object-oriented language into the primitives that a web browser understands, so we've had to build our web front ends in the browser analog of assembly language.
There are a few very new frameworks which take a more rational approach to web programming, such as Wicket and Echo. Let's hope the complexity of AJAX forces developers to climb out of this HTML/CSS/Javascript muck.
Isn't JSF supposed to be an OO presentation logic framework, similar to what you mention?
> JSP is a terrible tool for building web pages; so are > But if > object-orientation is so useful for coding business logic, > why wouldn't it be equally useful for coding presentation > logic? Yet, I see nothing object-oriented about HTML -- > whether or not it is supplemented with purchased, > custom-built, or standard-library tags. >
> Even when > javac is run within the container process (and some don't > even do that), it's still painful 3 to 5 seconds. When you > are just making color changes or something like that, such > a delay just turns you off.
If a developer is putting HTML markup for color or any other formatting directly in the JSPs instead of using CSS, there probably isn't a framework in the universe that can help.
Steven E. Newton's comment illustrates perfectly what's wrong when it comes to solving this kind of problem in the Java universe.
The original article tackles a perceived problem with JSPs; they won't immediately register page changes. I'm sure many have experienced frustration with the long turnaround time when trialing small changes in JSP files.
Thanks, Steven, for pointing out that color changes should be stored in CSS files. Not only does your post directly address the issue at hand, entertain and enlighten, it also serves to humiliate one who obviously has less insight than you.
> Isn't JSF supposed to be an OO presentation logic > framework, similar to what you mention?
Nope. You can build your backing model logic in an object-oriented language, and within your code you can access parameters and methods of your presentation components using .dot-notation. But can you instantiate sublclasses of JSF components, and use object-orientation to assemble JSF components into larger, more complex business-domain-oriented visual components? Not that I've seen.
Suppose JSF provides a component with lots of parameters, and I want to use it many times with some of the parameters set a certain way. How do I subclass the component so as to set those parameters to my personal defaults while permitting each occurrence to set the other parameters as needed? Is this very simple use of object-orientation even practical in JSF? I certainly haven't read about it.
Suppose I have many diverse pages which have this one thing in common: each displays an array of values in a table and has a button that when pressed downloads the table contents to the user in the form of a comma-delimited file (with a few of my project's peculiar formatting requirements). Each page's table has its one column count and column-headers, and gets from the containing page the default filename with which the user can save the comma-delimited file. To make it more interesting, let's say that instead of static contents, the program re-computes the array of values based on choices that the user has made elsewhere on the page. In a desktop (i.e., Swing) application, I could build a panel class that has all the features I need, and instantiate it in each screen with very little code. Can it be done in JSF?
No, it seems to me that in the JSF world, visual-component creation is best left to professionals who have studied the JSF internals. The ordinary programmer is limited to individually instantiating pre-supplied components, one at a time. If you have a pattern of similar (but not identical) visual components that appears on fifty different pages, you're just going to have to code that pattern fifty times.
I agree with Kohsuke. The only reason I support JSF at all is because it's better than JSP and Struts, and politically, it's easier to push than some unheard of framework/approach (unfortunately).
If I had my say, I'd almost never use any mainstream anythings. Usually if something is mainstream it's an indication that it's inadequate. I don't know why that is. I can't think of any mainstream language or standard that's actually elegant.
I'd probably be using something like Tapestry or Wicket, or roll-your-own (maybe... I don't prefer DIY if I can help it).
This problem is larger than just JSP. I believe it all started with ASP, which was horrible and Sun keeps copying horrible ideas without having any guts of its own. Once in a while it copies a good idea. Or when it does copy a good idea, it can't copy it well (look at Studio Creator, which is horrible in actual day to day use, but the idea of visual design is a good one).
Development experience has long been ignored by mainstreamers. They mostly focus on politics and run time performance in the top 1% of the cases and sacrifice the 99% of business case scenarios to achieve acceptable results in 1% (look at J2EE monster of over and under engineering). It's over engineered in places that don't could for 99% of real world use and under engineered in the same places. That's what happens when you listen exclusively to your biggest accounts and ignore the real meat of the marketplace.
Just because you aren't literally typing "extends" doesn't mean something isn't object oriented. The nodes of a div system inherits its ancestor, and nodes can even make use of multiple inheritance in styling classes. I think that betrays a misunderstanding of about how HTML works.
With regard to JSP, if you need something more than simple loops and conditionals, you're probably doing something wrong. The author of ANTLR created a template framework called StringTemplate based on those principles.
Frankly though, if that doesn't appeal to you, Echo2 sounds like the direction you want to move in. Frankly, I think CSS has a bright future way beyond code-based gui design. (Provided of course Microsoft starts playing nice)
To each his own, there's more than one way to skin a cat. The key point is that JSP is not "wrong".
Previous Topic
