Jason Hunter writes:
> Ray Cromwell wrote:
> > whereas you think that using WebMacro template code is good.
>
> It's a lesser evil. I'd rather see a simplified scripting language
> used in the page than a strongly-typed unforgiving compiled language.
> Different "languages" are better for different tasks. Java, as much
> as I love it, is not ideal for scripting.
Neither is WebMacro. If you want to go the scripting route,
I would assert that ECMAScript, JPython, and TCL are much
better routes. In fact, there is nothing inherent in
JSP that forces the use of Java, as PolyJSP shows.
I actually believe Microsoft has the right approach, which is
to abstract away which scripting language is used in their ASP
engine. You can plug in Python, Perl, Java, VBScript, and anything
else. For JSP, it could use the BeanScripting framework.
> Other template engines can use whatever syntax they like and you like.
> JSP leaves you effectively coding with XML.
Which is a much better syntax for authoring/editing environments than scripting.
What's easier to write, an editor that is based on XML syntax, or
an editor that mixes WebMacro and SGML?
XML leads a declarative approach for designing the view, which has been
shown time and time again to be easier for non-programmers to digest.
> You skipped the cookie example. It's more compelling than this first
> example in my opinion.
It's still nothing more than a slightly terser syntactic sugar.
But what business does the view have in setting cookies anyway? It
should delegate this to the controller. Cookies are too low level
of a mechanism for the view to be dealing with. According to WebMacro
propaganda, this should be a no-no.
> > Problem #4: Looping
> >
> > Well, given the extreme popularity of Cold Fusion, I'd say they would
> > prefer the XML syntax.
>
> Perhaps. Again, I'm not saying WebMacro is the right solution for
> everyone. I'm saying that JSP isn't always best. If you like XML
> syntax, then get a template engine specializing in that. I don't know
> much about Cocoon but it seems a likely candidate.
So? Java isn't always best either. The problem with this continuing
JSP Jihad is this fiction that JSP somehow dominates the market, that
us poor programmers don't even know other solutions exist. This,
despite the fact that usage of JSP on the web (or servlets for that
matter) still *pales* in comparison to Perl, PHP, Cold Fusion, and
ASP.
Did it ever occur to you that some of us like having the full power
of Java available in JSP, and really use JSP as an efficient mechanism
to embed massive amounts of easily editable HTML into Servlets without
having thousands of println()'s ? That JSP, is not seen as a panacea.
> > Why write code using foreach constructs, when a designer would better
> > understand something like this:
> >
> > <lists:define-list src="isps">
> > The next name is <lists:listitem item="name"/>
> > </lists:define-list>
> >
> > For a given project, the architect, in designing both the model and
> > the view, would be sure to design high level constructs to rendering
> > output rather than relying on low-level iteration.
>
> That syntax ain't half bad. Though, for my own site, I think I'll
> finish the work faster using WM's built-in looping, and avoiding having
> to write the tags above.
I'm sure it is, just like I could finish everything alot faster by bypassing
the whole MVC architecture and just hacking my SQL statements directly into
the page like 99% of websites out there.
But expediency isn't exactly the point of WebMacro, or is it? I keep
hearing about the ole "it's easier for graphic artists to use" argument,
but given my 6 years of web consulting experience on decent teams,
I'll say that this is largely theoretical. What really happens is,
graphic artists prefer to use Photoshop or Frontpage to mock up
a page, and the programmer ends up translating this into a view.
And also, in my experience, many of the people who assert these
benefits have never been on a large project team, and in fact,
hack out most of their websites by themselves in isolation, or
with one other coder.
> > Problem #6: Need a compiler
> >
> > This one is reaching very hard, I grinned, and almost laughed.
>
> Interesting. It's actually been a serious problem for the JSWDK (now
> Tomcat). I've sat in long meetings at Sun where we tried to figure out
> how to work around this problem so the server could ship supporting JSPs
> out of the box. We couldn't initially get a license to ship Sun's
It's still a redherring. About 90% of Java software I download
says "make sure you download the JDK first" It's a serious problem
only if you want to ship a shrink-wrapped webserver product. It's
not a serious problem for the vast majority of sites which DON'T
use a shrink-wrapped webserver. The world is moving to outsourcing
and application service providers anyway.
And if you want, jikes is a perfectly valid solution to the
problem. So is gcj and guava, and gj. Your target market is
likely Unix, and jikes solves the problem, with a tremendous
speed boost.
If you want to criticize JSP, you're going to have find
more serious problems than the Java compiler issue. It's a non-issue
for every web developer and corporation I know of. It's only an issue
for companies who want to sell shrink-wrapped web servers and redistribute
Sun's JDK. My advice: pay up to Sun, like Borland, and everyone else
does.
> > Problem #7: Wasted Space
> >
> > Come on, you're claiming that the compiler generated temporaries are a
> > problem? With today's disk prices? Get real.
>
> ISPs don't give you Gigs. They give you something like 30 Megs. For
> more you've got to pay more.
Another total red herring. Can you please show me a site where the actual
JSP/Template *text* amounts to more than 1 megabyte? 1 megabyte of
raw JSP code amounts to about 20,000-30,000 lines of code which is
a very large amount of data to be residing in JSP and not in a RDBMS.
30 megabytes would be unprecedented, at near 1 million lines of code.
If you're coding a website that has 1 million lines of code, you shouldn't
be at an ISP. You should be at Exodus/AboveNet and have $8 million
in VC funding.
And what's wrong with paying more? Sheesh, if your website is that big,
you should be paying more. Disk space is about 1 cent per megabyte.
> > Secondly, 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)
>
> Sounds like a complicated workaround.
No, it's quite trivial! Anyone can modify GNUJSP to do this in
about an hour. All you need to do is change the code that
generates out.println(some string constant) to
out.println(resourceBundle.getString(someIdentifier)) or,
in my solution, out.println(getConstant(ID)) where getConstant
is a subroutine generated with the server that uses a SoftReference
in JDK1.2 to store the constants, and reloads them when they get
GC'ed.
Anyway, it's irrelevent, because it's invisible to the user. JSP will
have competing implementations just like Servlets (JServ vs JSDK vs
Caucho vs JRun vs ServletExec etc) In fact, there are already about
5 JSP implementations, unlike WebMacro which has only one.
> > Now let's talk about what I see as WebMacro's problems:
> >
> > 1) much slower than JSP/servlets
>
> Maybe. It works *way* faster for me because I can have the
> servlet/template catch its own output and resend that cache on later
> requests. Since my db query takes several seconds, this is a 99%
> speed boost. I just regen the page when my db changes. It's
> beautiful. JSP pages don't let you catch their output.
Sure they do.
<%
JspWriter oldout = out;
out = new MyJspWriter();
if(dbChanged)
{
%>
rest of JSP code
<%
}
oldout.write(((MyJspWriter)out).getBuffer());
This works in all cases unless the JSP engine, for some reason,
defines 'out' as a final local variable. I haven't found any
that do that.
I am using it in a production website right now to pipe JSP-generated
XML through XSLT.
If you don't like that approach, than simply have the servlet pass
your own HttpServletResponse extension. (which I also do, because
I needed the ability in GNUJSP to read/write request data)
Still, it doesn't negate the point that WebMacro can't scale as
well as servlets/JSP. Java scalability is directly linked to
heap usage. The more heap you use per request, the lower your
throughput and higher your latency. Heap usage lowers the
maximum number of simultaneously requests, and as the heap
fills up, the GC thread owns more of the CPU, in a downward
spiral.
> You also can't GZip your JSP output on the way to the client. That's
> a trick servlets/templates can use to speed up slow connections.
Wrong again, as a demonstrated above. You *CAN* chain JSP output.
However, GZiping doesn't work for all browsers, and the number of
sites using it leads me to believe this claim is of dubious merit.
> There's nothing to say a dedicated template engine has to waste the
> heap.
Sure, but WebMacro's implementation does. If WebMacro translated
to servlets, and didn't have to build parse trees and evaluate
those trees, it wouldn't thrash the heap, but it does.
> > 4) not as powerful as Java, can't define subroutines, or build up
> > high level constructs.
>
> This can also be considered a benefit.
By whom? You think cut-and-paste coding is better? You think
building high level components is a bad thing?
> > 5) POOR code reuse factor. Basically, all you can do is include
> > code snippets. Ah, the days of m4 and the C preprocessor are back.
>
> I'm not sure what you mean here.
What I mean is this: in any given WebMacro system, there will be 9 gazillion
instances of code that all looks the same:
(pseudocode)
<TABLE>
#foreach something in container
{
<...TABLE ROW...>
}
</TABLE>
WebMacro doesn't have macros or subroutines, so all coders can do is
cut-and-paste or #include which is a very POOR way to parameterize
and reuse code.
It's all well and good that Justin is adding macros well after the fact
that WebMacro's been out for awhile. A little late tho.
> > 6) not based on XML syntax, thus, no real chance of mainstream
> > tool support.
>
> I don't see why you need XML syntax for a tool vendor to support you.
It's much easier for tool vendors to support a common standard than
to support a proprietary hack. XML parsers are a dime-a-dozen. It's
trivial to parse XML.
> > If WebMacro was *vastly* superior to existing technologies, it might
> > be worthwhile to adopt it vs the standard alternatives, but the fact
> > is, it's not vastly superior (and might be inferior), and the benefits
> > gained don't justify the switching costs.
>
> Well, you haven't used WebMacro so it's dubious how well you can
> compare the two. I used JSP and WebMacro both to design sites and I
> found WebMacro vastly superior. I just want to share that with people,
> along with the places where I found it superior, so that people who may
> be having similar problems with JSP know there's an alternative.
I don't have to use WebMacro to see why it doesn't offer significant
advantages, it's quite easy to evaluate it just by looking at what it
offers. I've been using template systems since 1993. In 1994 I wrote a
large template system similar to webmacro. In 1995 I wrote a Java
application server using RMI and a template/scripting system which I
called Model-View-Scripting, and which was used on a very very large
project. I have a pretty thorough experience using template
architectures and model-view, enough to know that WebMacro is not
"significantly better" than JSP.
It's just like the gazillion other template systems out there. It is not
special, it is not noteworthy. Is it usable? Does it suck? I don't think
so. I think it works as well as everything else. And that's the crux.
My point is, language wars are *dumb*. People use languages for
reasons other than mere technical superiority. Java is a prime
example. Why Java and not Eiffel, or SafeTCL, Smalltalk, or General
Magic's Telescript? It all boils down to the network-effect. What is
everyone else using? Which has the most support? etc
When I read your essay, I felt like you were trying *really hard* to
find things wrong with JSP. The disk space and compiler comments
were especially telling. If you want to convince us that WebMacro is
way better, you better have some really strong points in your next
essay.
-Ray
===========================================================================
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
