Read my comments below:

> -----Original Message-----
> From: Ariel Valentin [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 04, 2004 11:20 AM
> To: [EMAIL PROTECTED]
> Subject: RE: I've officially decided that JSTL is one of the worst things
> to ever happen to mankind
> 
> I am new to this mailing list but I figured I would throw in my two cents:
> (Please excuse my e-mail provider it interpreted the characters from
> Ivan's
> original message in some strange way
> 
> Needless to say I was a bit concerned about a few comments...
> 
> >After getting convinced to try JSTL, I learned the following things:
> >
> >1.   JSTL and EL are inefficient.  Tests on similar pages clearly showed
> >that.  (compare - ${name} with <%=name%>, run in a loop 10000 times,
> >youÐ-?ll see the difference)
> 
> Sure it will be slower, it is really java classes under the hood trying to
> hide complexity of scriptlet code. Is that a bad thing? Not really, helper
> classes a great, we create them to handle business logic, why not more for
> view components. The latest hardware is getting less expensive so I do not
> feel this argument holds (especially with the new 64 bit processers and
> DDR
> memory).
> 
        You don't feel this argument holds?  When you have a poor little tomcat 
running 100 different web applications with 10,000 clicks/day on each, it DOES become 
an issue.  Your choice:  get a new server, OR replace all the ${} with <%=%>.  I've 
been faced with similar situation many times, and trust me, it drives you nuts.

> >2.   JSTL is cumbersome Ð-? someone told me once that the reason they use
> >JSTL is because their designers are scared of <%=%> code, but they have
> no
> >problem throwing around XML statements.  Well, whatÐ-?s my advice to him:
> >hire new designers, and fire your high school students.
> 
> That is not nice to say about your fellow UI developers. Their specialty
> is
> usability and content development and if you ask my opinion most server
> side
> developers do not dedicate time to this discipliine. It is too much to ask
> a
> designer to learn a server side language when they are busy trying to keep
> up with their specialty. The job positing to replace the high schoolers
> will
> be like all of those other rediculous ones you see on Dice these days
> where
> companies are looking for a laundry list instead of a solid developer.
> 
        I see your point, but you got me wrong.  I am not suggesting that designers 
should have to learn a whole new language, but I am saying that if a designer is OK 
with this: ${name}, but NOT ok with this:  <%=name%>, then it's a retarded designer.  
EL syntax sort of "encourages" designers to be free to throw expressions and tags 
around, which could result in SERIOUS logical errors when you pull some important ${} 
out of the loop, and as a result, the dev will have to spend two day figuring out why 
his code isnât working (this is where CVS is a charm).  Bottom line is: designers 
are for designing, not for throwing important stuff around.

> >3.   XML is for data flow, not for logic.  Whoever the hell thought of
> tags
> >like <c:if> and <c:choose> should be murdered in the worst way possible.
> >With JSTLÐ-?s exporting and importing variables, and all the logical
> >statements and loops, the whole idea of XML gets destroyed.
> 
> What should we use then for content development? HTML is done... no more
> updates... It's replacement is an XML application known as XHTML. Looks
> like
> XML has more uses that just data... Oh did someone mention XSL? XSLT?????
> XSLT syntax <xsl:If ... <xsl:choose .... I wonder where Jakarta developers
> got the idea....
> http://www.w3.org/MarkUp/Activity
> 

        What should we use instead?  Welcome to the front page of JSP manual:

        <% if( yourmoma ) { %>
                Do some things
        <% } %>

        To me, it seems EASIER than this:

        <c:set var="yourmoma" value="<%=yourMomaFromCode%>"/>
        <c:if test="${yourmoma}">
                Do some things
        </c:if>

        What happened to the good old idea of using JAVA, with all its beautiful 
features, in the JSPs themselves?  IMHO, Java beats tag syntax in all aspects - easier 
to write and understand, strict syntax, and more efficient.  I don't know WHY would 
you want to use XML for logic flow in the first place.

> 
> >4.   EL encourages sloppy syntax.  It doesnÐ-?t even have data types
> (well it
> >has on the bottom level, but not on the surface).  Remember JavaScript?
> >Did you know that at first, it was supposed to be server-side scripting
> >language?  You know the reason it didnÐ-?t make it (one of the major
> ones)?
> >  Because of its sloppy syntax and the amount of errors it caused.  Why
> >bring it back?
> 
> Apples and oranges... Javascript indeed has it's problems, (heck I am
> forced
> to work with VBScript so I empathize here), but someone was smart enough
> to
> recognize Javascript's limitation and that is why it is a client side
> technology. I believe JSTL uses reflection and if you don't like that you
> sure as heck will never like EJB Container managed persistence...
> 
        Oh don't get me started on EJB.  I think we all know how much money has  been 
lost as a result of people using it.  But you're missing the point, again:  the 
(major) reason JavaScript is NOT server-side, is because of its sloppy syntax which is 
like a warm oven for bacteria - bugs just GROW in it.  EL is making the same mistake 
over again.  Think about what's happening:

1.  We're running binary
2.  Binary's running java
3.  Java's running EL

I can accept to live with just 2 layers, even though it's already a bit too much, but 
3rd layer is taking it over the top.  Perfromance-wise.  See above for my comments on 
syntax.

> >5.   Server-side content and client-side content should be separated.
> When
> >everything looks like HTML (in some way), itÐ-?s hard to tell what
> actually
> >gets processed, and what gets sent to the client as static (if you have
> >all-nighters, youÐ-?ll understand).
> 
> The point about SS and CS separation is an arguement for EL. It should be
> used to make it easier to display values from Business logic components
> hiding the complexity from the View Tier, no "work" should be done other
> than rendering information to an understandable layout. If one is
> "processing" JSTL is not the way to go, move that logic into a helper
> class,
> that is what they are for.

        Understandable output?  Do you really think you can find one designer who 
would understand a simple calendar written in tags?  Hell no.  And for me, as a 
programmer, understanding good old java code inside <% %> is MUCH MUCH easier than 
understanding all the tag BS.  Besides, Java code is syntax-enforced, unlike EL, which 
saves me tons of time and bugs.

Besides, old java tags <% %> do very good job of presenting "understandable layout".  
<%=%> and ${} are both equally to understand to me.

> 
> >6.   JSTL is time-consuming.  The whole idea of JSTL was to speed up the
> >process.  Not only is it less efficient than embedding code the normal
> way,
> >but it also takes you forever to make something new with it.  DonÐ-?t
> >believe me?  Just try it.
> 
> Yes I have tried it, with a third party UDDI API that did not use JAX-R
> specification and found it easier to just write:
> c:out value="${sessionScope.business.TModel.overview.overviewURL}"
> than writing:
> Business business = ( Business ) session.getParameter("Business");
> TModel tModel = (TModel) business.getTModel();
> Overview overview = (Overview) tModel.getOverview();
> String overviewURL = overview.getOverviewURL();
> out.print(overviewURL);
> 

        That's one of the things that EL might be actually useful for:  printing stuff 
out and escaping XML.  But still, what if TModel might return a null value?  Then 
you're in for a nice 2 hour debugging ride with your EL syntax, or a 5 second adding 
if statement ride, if you used Java.

> >7.   The only reason JSTL was made is so that guys at Apache could write
> some
> >stupid book explaining its hella complicated syntax, and charge people
> $50
> >for it.  See, itÐ-?s just like the C++ story.  Why was C++ invented?  To
> >give programmers jobs.  No other reason whatsoever, C does whatever C++
> >does just as good, and better.  So I am not sure if JSTL is a step to
> >having Ð-ÂadvancedÐ-? developers who get paid more because they took time
> >to learn retarded JSTL syntax and EL, or is it just ApacheÐ-?s
> >developersÐ-? way of making money (and I am surre OÐ-?reilly and the bros
> >are thankful too).
> >
> >Point of this message:  DO NOT USE JSTL OR EL.  YouÐ-?ll regret it.  I
> did.
> 
> Thanks for the vote of confidence in the intentions of the open source
> community. I will keep tthat the next time the mother of the matrix uses
> this "free" software to charge my company millions to implement ERP
> software
> all the while giving ASF honarable mention in a magazine somewhere.
> 
> Thanks,
> 
> Mr. Ariel S. Valentin
> mailto:[EMAIL PROTECTED]
> 
> _________________________________________________________________
> Is your PC infected? Get a FREE online computer virus scan from McAfee-
> Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.701 / Virus Database: 458 - Release Date: 07.06.2004
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.701 / Virus Database: 458 - Release Date: 07.06.2004
 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to