I'm cross-posting an answer I sent on the SERVLET-INTEREST list, that contiues
a similar discussion but also adds comments to Jason's article, since I feel
the discussion belongs in this group as well.
Subject: Re: value of tag libraries
Jason Hunter wrote:
> Hans Bergsten wrote:
>
> [moved PS to top]
> P.S. Great topic for today considering I just posted an article
> comparing JSP to WebMacro. If you didn't catch my earlier email,
> it's at http://www.servlets.com/soapbox/problems-jsp.html.
Yes, I saw your article and was about to send some feedback on it. But now
I can comment on all of it here instead ;-)
First, I'm sure we can argue this back and forth forever without totally
convincing each other. But hopefully we, and others, can at least learn
something about the pros and cons with the two alternatives.
Like I said in my reply to Justin, I like JSP and feel it has advantages over
templates. Does this mean I think JSP is perfect and template based systems are
all wrong? Absolutely not. Is JSP so bad as you and Justin describe it? I
don't think so. Are there problems inherent in the JSP specification that
makes it impossible to improve. I think not.
I believe most of the areas you bring up can be solved with custom actions
in JSP 1.1 today, and even better tomorrow when the most commonly requested
custom actions get standardized. As you know, there's an approved JSR for
specifying a standard JSP tag library. There's also work in progress to
develop a set of custom actions within the Jakarta project, most likely in
parallel with the spec work.
The reason I feel that custom actions are so important is that 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, where the designer can pick components from a palette
and add them to the web pages. Tools like this makes it possible for people
without programming skills to develop fairly sophisticated dynamic web sites.
I must admit I have not looked much at WebMacro (yes I know, I should), but
from what you and Justin have described (and a quick look months ago) I
get the feeling that it requires Java programmers to develop the request
processing and business logic pieces, and the templates are pure "views".
That's ideal for a complex web application, when you have access to both
programmers and web page developers.
But most dynamic web sites require only pretty simple stuff, like building a
dynamic response based a database query using a few inputs from
a form. Tools that makes it possible to develop these apps without having
access to programmers is a big advantage. There are a lot more web page
designers out there than there are Java programmers. Have you tried to hire
an experienced server-side Java programmer lately ;-)
Even on a large, complex project, where you *do* need both programmers and
web page designers, using tools that the web page designers are familiar with
to develop the pure "view" pages is also a great benefit. I'm sure it would be
possible to integrate support for things like WebMacro in web design tools as
well, but my bet is that you will see it for JSP first.
> > JSP can also be combined with servlets, as well as JavaBeans and
> > Enterprise JavaBeans, so I see the same possibilities with JSP as
> > you describe for templates.
>
> I tend to think of "JSP vs templates" like "C++ vs Java". Sure, you
> can do everything in C++ that you can do in Java. So why is Java
> winning market share? Partially it's because Java makes it easier to
> write and read code, plus it helps enforce good design.
>
> > For instance, you can (should) separate the request processing.
> > One common way of doing this is to let
> > a servlet receive the request, use and create beans to process the
> > request, and then select an appropriate JSP page for presentation
> > of the result.
>
> And you (should) write OO C++. Meanwhile, Java makes you. I prefer
> that, just as I prefer how template engines enforce the separation.
Both these arguments are moot if you, as I, believe that higher level
tools than a text editor will be used to develop the web applications.
> > > 2. Template systems do not require non-standard extensions to
> > > Java, which is what JSP is. They work in any webserver with
> > > an ordinary JSDK and Java runtime. The same cannot be said
> > > of JSP (which emphasizes standards because it is non-standard).
> >
> > I'm not sure I understand this argument. Both the Servlet API and
> > JSP are standard extensions (packaged in javax packages). JSP
> > works in any web server that supports the Servlet API.
>
> 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
> right 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.
This is just a matter of time. You know as well as I do that most vendors
have beta versions for JSP 1.1 available, or has announced support to
be included in products released during this spring.
As far as bugs go, having just one vendor doesn't mean that it's bug free;
I'm writing this on a Windows NT machine ;-) Not even Open Source is bug
free, and even with one vendor for the template system you may run into
vendor specific bugs on the platform where you deploy it.
> > Have you looked at what you can do with custom actions (tag
> > libraries) in JSP 1.1? I have implemented a number of custom
> > actions that can iterate over a number of data types, such as
> > arrays, Vector, Enumeration, Hashtable.
>
> C++ vs Java: C++ has a String type in the STL, but it'll always be an
> add-on even though it's a standard. I prefer Java's core knowledge of
> Strings. I also prefer WebMacro's core knowledge of iteration types
> (with the ability to write my own if I want to get fancy).
The standard tag library will likely make this point moot.
> > one of the most important
> > advantages with JSP over any of the template systems is that it's
> > formally specified and included in J2EE. This means it will be
> > covered in classes, books, endless web sites, etc. And therefore be
> > familiar to a lot of people.
>
> Perl isn't formally specified apart from implementation (at least I've
> never seen the spec), but yet it's still *widely* covered. An open
> source implementation that works everywhere is equally good as a spec
> in promoting classes, books, web sites, etc.
Sure, only time will tell if WebMacro (or another template system) will
gain this kind of exposure. I'm, however, sure that the fact the JSP is
part of J2EE pretty much guarantees that it will be widely covered.
> > This makes it a lot easier for an employer to find people that do
> > not need to get additional training, makes it easier for developers
> > to share experience, creates a market for both Open Source and
> > commercial custom action libraries, allows web design tool vendors
> > to provide great integration, etc. In short,
> > all the advantages of a broadly supported standard.
>
> These are arguments against using a single-vendor solution, but against
> a popular open source technology they don't really work. WebMacro can
> succeed as well as Perl or Apache in all these areas.
Yes, it can happen. Will it? Who knows. But again, for JSP it's a given.
You made a few other interesting points in your article that I like to
say something about as well.
[Jason] Problem #5: Useless Error Messages
Yes, here we're in full agreement! And if you use scripting elements you
will run into this sooner rather than later. That's yet another reason
why I promote using custom actions, removing virtually all Java code
from the JSP pages.
[Jason] Problem #6: Need a Compiler
[Jason] JSP requires a compiler be shipped with the webserver. That's problematic,
[Jason] especially since Sun doesn't give away the tools.jar library containing
[Jason] their javac compiler.
Not completely true. Sun has allowed ASF to redistribute the javac compiler,
in a separate JAR file as opposed to the complete tools.jar.
[Jason] Problem #7: Wasted Space
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.
So have you changed your mind Jason? I didn't think so ;-)
Hans
--
Hans Bergsten [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
