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]