Discussions

News: Zarar Siddiqi: Are JSPs Dead?

  1. Zarar Siddiqi: Are JSPs Dead? (36 messages)

    Zarar Siddiqi has posted "Are JSPs Dead?," asking rhetorically and suggesting that JSPs perhaps shouldn't have been living in the first place, being merely an answer to ASP.
    JSPs are the ultimate contradiction to Java reusability, there is simply no mechanism in J2EE which allows even an honest man to reuse a JSP. If you’re thinking of , you’re missing the larger point of reuse - reuse as in other components of the application or even different applications. Of course being confined to a Servlet container kills off any chance of reuse in the SE world along with making testing so hard that you’re forced to mock an application server just to see what’s rendered. The direct binding to a Servlet is also something that never amused me nor did I find the behind the scenes conversion from JSP to Java to Class file ever a needed exercise. Why bother with an extra compilation stage when you’re already serving your page from a compiled Servlet? Be advised that if you’re still considering using JSPs as the V part in MVC for even a mid-sized application, you’re making a mistake. This is especially true if you’re using JSPs as purely a view mechanism (no actual code in the pages but just taglibs) since you’re not even taking “advantage” of the ability to write Java code in them. If you are one of those folks who thinks the library wasn’t the ultimate example of bad ideas, you might actually still be using scriptlets in your pages and passing them off as acceptable software. You, you just keep doing what you’re doing, there’s no help for you.
    Zarar suggests using Freemarker, Velocity, and AJAX as alternatives to JSP. It's an interesting thought line, because whether we like it or not (and Zarar apparently does not) JSPs are the default display technology in Java EE. Should they be? What else would work as a standard? What do you use? Why? (And what about those poor folks who are stuck in yesterday's applications, using Struts 1.1 and JSPs?)

    Threaded Messages (36)

  2. I use Facelets when I'm using JSF.
  3. It is a long time that JSPs are in use for tens of very big applications. I think Mr Zarar would suggest it some years ago before people build many application suing pure jsp/servlets or Struts as an MVC with JSP playing View role.
  4. of supporting the sh*t because we are too lazy , incompetent or arrogant about our intelligence comparing with others ... cool nothing new under the sun; I always used these templating techniques and when I've seen opposition I argued just with a simple "if u can do-it better/faster/more flexible with jsps than me ... please just do-it and I'll close the entrance door but if not u close the door from outside, please"
  5. Reusing jsp.... what for ?[ Go to top ]

    I think seeing reuse everywhere is often counter-productive. Views are the less reusable part of a web application because they are often dedicated to an application. Some design templates may be reused, and taglibs are the right way to deal with that. JSP are maybe not the ever best tool to build the client-side tier for applications, but it's certainly not the worst, despite critics about its maintainability (which is *often* a *purely technical* view of the project context).
  6. Re: Reusing jsp.... what for ?[ Go to top ]

    You mean except when using a component based web layer right? Why do you think we created/work on component based frameworks to begin with? It's only natural if you are against duplicating code. (of any kind)
    I think seeing reuse everywhere is often counter-productive. Views are the less reusable part of a web application because they are often dedicated to an application.
    Some design templates may be reused, and taglibs are the right way to deal with that.

    JSP are maybe not the ever best tool to build the client-side tier for applications, but it's certainly not the worst, despite critics about its maintainability (which is *often* a *purely technical* view of the project context).
  7. Re: Reusing jsp.... what for ?[ Go to top ]

    (which is *often* a *purely technical* view of the project context).
    No, it is from a "developing applications" point of view.
  8. Reuse isn't an end goal[ Go to top ]

    I think seeing reuse everywhere is often counter-productive. /blockquote> A-men. This holy grail of "reuse" has been the cause of some of the biggest cluster****'s of frameworks I've ever seen. Don't misread me here; reuse where you can, and where it makes sense, but too many times I've seen reuse used as the main driver of something, business problem be damned.
  9. Re: Reuse isn't an end goal[ Go to top ]

    I think seeing reuse everywhere is often counter-productive.


    A-men. This holy grail of "reuse" has been the cause of some of the biggest cluster****'s of frameworks I've ever seen. Don't misread me here; reuse where you can, and where it makes sense, but too many times I've seen reuse used as the main driver of something, business problem be damned.
    Quite true. I guess the only way to be sure then (if you have the time) is to evaluate all the "non-outdated" frameworks to see if they fit your style and confirm if things like reuse is *really* possible without compromising on usability and other aspects etc. Matt Raible is doing something along these lines and I for one am sure looking forward to his analysis, he's presenting at ApacheCon Europe shortly: http://raibledesigns.com/rd/entry/comparing_java_web_frameworks_proposed
  10. no, but they should be[ Go to top ]

    I think it's pretty obvious that there are better solutions than JSP for just about every scenario. It's just unfortunate that JSP that it is the "standard." As such it is the most straightforward for someone who doesn't want to investigate alternatives. So the technology may not be dead in terms of use; it may still suffice (or be abused) in some cases, but by no means does that make it the best choice.
  11. How to reuse JSP[ Go to top ]

    If you design you JSP files with component concept, you can reuse most of the components. I have been using this design pattern since 2003 and it made JSP development much easier. [JSP](1)->(1..*)[block](1)->(1..*)[field | label] Sorry this is a text based UML, it means a JSP file can include mutiple block level components and each block level JSP can include multiple field or label level JSP components. The field level JSP is just one tag, can be Struts, JSTL or anything. Better yet, if you work with Eclipse, you can navigation the structure by F3 or clicking the link depends on the plugin you are using. Don't just throw your JSP part to junior developers, ask some senior developer to work on the architecture first, or course, the senior developer should have hands-on experience with JSP design.
  12. I wish they were but am afraid they aren't. On my last project they were alive and kicking. But I am happy that there seems to be consensus about the fact that they are not OK. If I would have been working with them right now I would rage about it over here but fortunally I have some time off, wich gives me the opportunity to show my decent side.
  13. Good riddance, JSP are one of the technologies pretending to be something its is not. In reality JSP are compile Servlets, its a code generator and not actually a template. It reminds me of EJB where you have client stub RPC code pretending to be "remote" objects. Its a fallacy. regards Malcolm Edgar http://click.sourceforge.net
  14. Is the Java news cycle Dead?[ Go to top ]

    I've had this feeling for a while but it appears Java is getting mature and, well, boring. Most Java technologies have matured and the book writers are now seeing deminishing returns and the book racks are giving way to AJax and Ruby. Ruby and Rails are a fling but a good one. .Net is someone else's sloppy seconds and not worth the walk of shame. I'd say the spark is dead if anything is. There is less competition and less risk and anyone saying a mundane but widely used technology like JSP is dead is really just frustrated with the lack of spark. I would say the general trend of groups of committers around key projects that form a consulting arm only to be acquired by some corporation has made opensource dead. It's subtle but far more damaging than anything JSP has done.
  15. Re: Zarar Siddiqi: Are JSPs Dead?[ Go to top ]

    I wish they were but am afraid they aren't. On my last project they were alive and kicking. But I am happy that there seems to be consensus about the fact that they are not OK.
    So, are Zombies alive? :0
  16. Re: Zarar Siddiqi: Are JSPs Dead?[ Go to top ]

    So, are Zombies alive? :0
    nice one _o_
  17. JSP's are fine. Perfect? No where near it. Are there better alternatives now? Plenty. Put things in perspective. There's a whole lot of ways to screw up a J2EE application and if everything else is architected correctly and the only 'fault' is the use of JSPs for presentation, then the developer has done a pretty good job. Mike
  18. Re: Zarar Siddiqi: Are JSPs Dead?[ Go to top ]

    So, are Zombies alive? :0


    nice one _o_
    :) I could have taken it in a really bad direction. As in .. if JSPs are dead and people are still messing with them, then that makes them ... :-&
  19. jsps can't be dead after serving so many projects. The transitions has to be smooth till we find a matured technology. The most efficient way of re-using the code for jsps is by using tiles controller. In that way we can make sure that jsps only contain tag libs without any java code. using the latest jargon is no more a trend in the software industry. you got to maintain the right balance using common sense.
  20. What's wrong with JSP ?[ Go to top ]

    I feel sorry for those people who knows only JSP and not JSTL I've been extending JSP using JSTL all these years and it proves to even more productive than the brand new JSF already (with form binding, "workspace management" things, and whole load of other cool stuff). AFAIK no such thing like JSTL in templating engines I'm also wont bother migrate everything that I've built on top JSP to JSF, especially when it wont have any advantage rather than keeping update with newest standards :)
  21. JSTL isn't the answer[ Go to top ]

    I feel sorry for those people who knows only JSP and not JSTL

    I've been extending JSP using JSTL all these years and it proves to even more productive than the brand new JSF already (with form binding, "workspace management" things, and whole load of other cool stuff).

    AFAIK no such thing like JSTL in templating engines

    I'm also wont bother migrate everything that I've built on top JSP to JSF, especially when it wont have any advantage rather than keeping update with newest standards :)
    This is exactly how I used to feel but I changed my mind after discovering component based frameworks. You may want to read this blog entry: http://ptrthomas.wordpress.com/2007/03/02/wicket-impressions-moving-from-spring-mvc-webflow/ It also touches upon why JSP looks bad compared to the alternatives.
  22. JSP's along with JSTL are a cool feature.. Nothing wrong with that... Can somebody objectively point out the problems they face with JSP ? Now please don't say that they are bad because they compile into Servlets, so its a negative point. Your code compiles into object code, so that must be a bad thing as well.. What other sort of reuse is requierd ?
  23. JSP's along with JSTL are a cool feature.. Nothing wrong with that...
    Can somebody objectively point out the problems they face with JSP ?

    Now please don't say that they are bad because they compile into Servlets, so its a negative point. Your code compiles into object code, so that must be a bad thing as well..

    What other sort of reuse is requierd ?
    In addition to my post above which links to an objective comparison, if you are interested in "before and after" code samples, have a look at this blog post: http://ptrthomas.wordpress.com/2007/04/01/jtrac-ui-makeover/
  24. very biased comparison[ Go to top ]

    a very biased comparison ... the example used for jsp example is a bad & ugly one see my example : those will generate a file list with automatic upload dialog, uploading process & repository completely handled by the framework, even automatic thumbnail & view window all those will bind to a POJO Form. and for the decoration things ... its piece a cake to do. also for AJAX, it blends naturally with JSTL. the only complaints come from people who doesnt want or lazy enough to extend JSTL.
  25. Re: very biased comparison[ Go to top ]

    the only complaints come from people who doesnt want or lazy enough to extend JSTL.
    I did try writing my own custom JSP tags. It worked fine for a while, but when the application became more complex (looks like a complex example equates to "bad & ugly for you" :) I started feeling that it was getting out of hand.
    also for AJAX, it blends naturally with JSTL.
    Got an example? And by the way your sample is not pure HTML, so the same guy has to write the JSP as well as do the "decoration things". Of course it finally boils down to what technology *you* are comfortable with, so if you like JSTL that much, by all means stick with it. Just my 2c.
  26. Re: very biased comparison[ Go to top ]

    it is bad and ugly because you did not take it to the next level, it's called the "component architecture" here a sample of AJAX based combo box series : inside these "control fields" it will transparently load combo box list content via XMLHttpRequest when the parent combo changes it value ... oh yeah & BTW, it's long since I ever peddle with HTML or Javascript, it's all resting in my TagLib classes now ... :) decoration is also reside in another "Aspect" classes organized ... so it would be consistent throughout the app I'm not here to express what I'm comfortable with, just to balance biased opinion and keeping open mind to other people .. :)
  27. Re: very biased comparison[ Go to top ]

    it is bad and ugly because you did not take it to the next level, it's called the "component architecture"
    Oh, you mean JSP custom tags. The main point of the "Are JSPs Dead?" article is that it is very hard to achieve re-use with JSPs. Based on what I have experienced, I would 100% agree. Of course you can if you try hard enough but like in your case, you end up creating a mini framework of your own. You are having a good time it looks like because you don't bother about HTML and Javascript, but someone on your project has to. I would guess that person is not having such a good time :) And if sharing my experience makes me biased, then so be it.
  28. Now please don't say that they are bad because they compile into Servlets, so its a negative point. Your code compiles into object code, so that must be a bad thing as well..
    I'll say it, jsp sucks because it is compiled as a servlet. The programming model isn't that bad even though I prefer something like Velocity but the implementation model, generating a servlet instead of using an interpreter, turns JSP into a declarative programming language instead of a regular template language as you would expect. What's the difference? In Jsp, the template definition becomes the template executor, ie. the definition is executed by itself, which means the template is always going to be interpreted and rendered at the same time. This isn't a two phase process as you would normally expect of a well designed template engine. For instance, what happen when some of the text and scriplet you write should be treated differently according to their parent tag? In jsp, a page would print the parent tag (or execute it if it is a custom tag) and directly prints its content. It's impossible to get the data first, parse it and then print it. JSP does it all at the same time. This is has severe repercussions. Let's look at JSF problems to illustrate my point. I'll use JSF's Hans Bergsten examples. Note that the situation I'm trying to describe is not only related to JSF, far from that (there is a reason why no component framework rely on jsp). Here a very simple jsp/jsf page which should display a link: What about usability? But in this case, the result would be "What about usability?. Clearly not what you want. Why it is so messed up? Simply because the command link tag is waiting its children to be defined before rendering itself which is logical. The problem is that the jsp servlet as soon as it gets to the text definition "What about usuability" output it directly to the request... This one phase model turns JSP in a very declarative programming language instead of being a real template language. My other main issue against JSP is that it is totally depenedant of the Servlet container so you can't embedded it in a library to generate some dynamic html or other format as you would do with a normal template engine, which is really bad.
  29. I'll say it, jsp sucks because it is compiled as a servlet. The programming model isn't that bad even though I prefer something like Velocity but the implementation model, generating a servlet instead of using an interpreter, turns JSP into a declarative programming language instead of a regular template language as you would expect.

    What's the difference? In Jsp, the template definition becomes the template executor, ie. the definition is executed by itself, which means the template is always going to be interpreted and rendered at the same time. This isn't a two phase process as you would normally expect of a well designed template engine. For instance, what happen when some of the text and scriplet you write should be treated differently according to their parent tag? In jsp, a page would print the parent tag (or execute it if it is a custom tag) and directly prints its content. It's impossible to get the data first, parse it and then print it. JSP does it all at the same time. This is has severe repercussions.

    Let's look at JSF problems to illustrate my point. I'll use JSF's Hans Bergsten examples. Note that the situation I'm trying to describe is not only related to JSF, far from that (there is a reason why no component framework rely on jsp).
    Here a very simple jsp/jsf page which should display a link:


    What about usability?


    But in this case, the result would be "What about usability?. Clearly not what you want. Why it is so messed up? Simply because the command link tag is waiting its children to be defined before rendering itself which is logical. The problem is that the jsp servlet as soon as it gets to the text definition "What about usuability" output it directly to the request... This one phase model turns JSP in a very declarative programming language instead of being a real template language.

    My other main issue against JSP is that it is totally dependant of the Servlet container so you can't embedded it in a library to generate some dynamic html or other format as you would do with a normal template engine, which is really bad.
  30. It is funny. I always read that JSP are the V in the MVC and I thought it was really crazy. I don't love JSP, but I can find useful the intrinsic mapping URL->application-code-that-implements-that-url. The role of JSP in my apps is rather the C instead of V. I use them as entry-point for the business logic that is implemented as POJO. The V is implemented with a template engine+expression with an extended JEXL syntax. 95% of the code runs out of a J2EE container. Guido.
  31. Reading these posts, I can't help but think people need to take the blinkers off and start looking at the bigger picture when it comes to real seperation of concerns and real reuse. My 2 cents worth, is that the 'view' should be what is rendered by the browser i.e. good old simple HTML/CSS. In my option, there is only one web framework which gives you the ability to think of the view in pure HTML terms i.e. Wicket. JSPs do not allow you to think like this and unnecessarily complicate things. Keep up the good work to those contributing to Wicket project and taking the KISS principle to whole new level.
  32. wow ... now missing HTML is suddenly the biggest mistake we all ever do .. ? .. am I really that outdated ? ... LOL :)
  33. Reading these posts, I can't help but think people need to take the blinkers off and start looking at the bigger picture when it comes to real seperation of concerns and real reuse. My 2 cents worth, is that the 'view' should be what is rendered by the browser i.e. good old simple HTML/CSS. In my option, there is only one web framework which gives you the ability to think of the view in pure HTML terms i.e. Wicket. JSPs do not allow you to think like this and unnecessarily complicate things. Keep up the good work to those contributing to Wicket project and taking the KISS principle to whole new level.
    Ditto that re. view should be what is rendered by the browser. The Java community has lost track of the many page designers (vast majority) who are not JSP programmers. So smaller sites that do not already have Java skill sets take one look at the formidable looking JSP and JSF specs and give up on Java before they get started(what a pity). XML is a poor way to express program logic and JSP without XML is a strange language. Take a look at where the industry is going and you see that server side Java is stuck at the high end where Java is widely used on large sites - much of the innovation is happening elsewhere (various AJAX frameworks for instance). Velocity, Wicket, etc. are approaches that get around the problems with JSP. For another take on a web component framework take a look at: http://www.jotobjects.com/ And in regards to this discussion: http://www.jotobjects.com/JOTlinksaboutjsp.html
  34. I can't see that JSP, used properly (using component based includes, a proper tag library and so on) are any worse than any other component based web gui creation frameworks. Also I think designing reuse for something that will never be reused is a very bad - and very expensive - idea. The one thing I don't like about JSP are not the JSPs themselves. What I dislike is that no one ever bothered to build a true rapid application development model on top of it that works only inside the JSP layer. Instead we have tons of components models that come along with tons xml files, custom interfaces to be implemented, custom listeners to be implemented, template files and what have you AND JSPs. Now that *is* probably a bad idea.
  35. Guys..Jsps are dead..No doubt about that..Just because people have used it does not make it a good product..People have used Struts for so many years but that does not make it a good Web Framework...People have used Apache Torque for ORM but that does not make Torque a competent ORM framework...We used them because there weren't any other frameworks available at that point...Same is the case with JSPs..Even in Struts and JSF the view is still JSP..I am not advocating for JSF's also..Its another crap from Sun..I remember so many problems we faced with JSF when we started working with it...After pestering SUN with a lot of bugs they acknowledged that its still not production ready..Guys move to component based framewrok(sorry to say JSF is also component based..grrrr) like Tapestry...The best framework i have used so far( just to let u know being a consultant i have used Struts, Radien , JSF, Tapestry, Spring MVC and Webflow..Plain vanilla JSPs and Servlets). Spring frameworks are really good and is a direct competitor for Tapestry.I can write millions of line on this topic but for the time being this will suffice.
  36. JSPs are the ultimate contradiction to Java reusability, there is simply no mechanism in J2EE which allows even an honest man to reuse a JSP.
    ,
    Be advised that if you’re still considering using JSPs as the V part in MVC for even a mid-sized application, you’re making a mistake. This is especially true if you’re using JSPs as purely a view mechanism (no actual code in the pages but just taglibs) since you’re not even taking “advantage” of the ability to write Java code in them.
    The ability of writing Java code in JSPs is a real advantage, your sarcasm has missed the mark. And no, JSPs are not just a view.
    Not too long ago a colleague of mine stumbled upon a major bank website (TD Canada Trust) who had managed to seriously screw up their application server configuration and ended up serving the raw JSP page instead of actually executing the code in it. Needless to say the code looked like crap with request.getParameter() being used more often than white space to compute user states in a banking application. It was one of those “this page can do a lot of stuff so I’ll just write a lot of ifs to figure stuff out” type things.
    Why do you reflect your colleague's specific problems onto a generic technology?
    What I’m trying to say is that JSPs promote shoving control logic in your pages no matter who you are simply because it’s so easy to fall into the pitfall that are scriptlets.
    This is how my JSP components look like, I think that the event-processing code is pretty neatly separated from subviews: <%@ page contentType="text/html;charset=UTF-8" language="java" %> <%@ taglib prefix="jc" uri="http://jspcontrols.net/tags/core" %> <%-- Input phase --%> ... ... <%-- Render phase --%> ... ... ...
    It’s best to eliminate the temptation and use a dumb templating tool to render your views because let’s face it, they’re views!
    If you cannot help the temptation of writing ugly code, then this is your own problem, don't project your inability to write clean code on everyone else.
    As AJAX is becoming more and more popular, JSPs are getting further phased out.
    Not true.
    Lot of developers prefer to return chunks of HTML from the server rather than an actual dispatched forward.
    This is true, but I don't see how your experience with Struts -- where the "dispatched forward" came from? -- relates to JSPs.
    A lightweight and powerful template language is much more suitable here as your AJAX interface view will be an aggregation of snippets of HTML returned from the server. Doing this using JSPs would add a level of complexity that is both undesired and unneeded.
    I return HTML snippets from JSP components with no problem.
    Having said all that, you can produce the same product with both JSPs and other lightweight template engines, but the latter stay much truer to the MVC philosophy and result in a much cleaner code base.
    Please do me a favor, read this article, maybe it will help you understand that JSPs are not dead at all and can be perfectly well combined with structured code, event-processing and Ajax.
  37. My JSP Experience[ Go to top ]

    I found that JSP (using the XML syntax) was quite useful in a few of the projects I did over the years. The first time I used it in a project, we used XML and XSLT to generate JSP pages, so that we could separate content, presentation, look-and-feel and layout. By generating JSP pages before deploying a website for a client, we made it possible to customize look-and-feel and language easily. Eventually it would take us about three minutes to generate a full website. Our philosophy was to push all the complexities of having to support different languages and look-and-feels in the generation stage, rather than in run-time. Since we used XSLT to transform the content, the flexibility in layouts and look-and-feel was much greater than CSS alone. The XSLT templates were the reusable components. More recently, we used JSP in a software-as-a-service platform. The company was a start-up, so lowering the cost was paramount. With JSP pages in XML syntax, we found out that a small number of junior to intermediate developers were all we needed to develop and maintain a rather sophisticated system (24x7, over 1M hits per day). The good thing was that silly mistakes could be caught by XML well-formedness in compile-time. Using JSTL and banning (I am not even sure how to spell it, not having used it even once in the whole project), the pages were very clean and easily maintainable. My only complaint is that the syntax of the JSTL expressions are not checked until run-time. It has a few problems. Which technology does not?