Jayson Falkner's Blog

Blarg #1: Are JSP Still Relevant?

Blarg #1: Why are JSPs still relevant?

You seem like the perfect guy to ask.

So; if they are, then why are JSPs still relevant?

Great question zander, and it is one I just so happen to have a lot to say about. You would be surprised how often this type of question seems to pop up, not just about JSP, but about just about any J-starting acronym the marketing folks throw to the masses. In some cases it is valid to ask, say the technology in question really is dated...or it was just pretty worthless in general. However, in the case of JSP, there are several great reasons it is still relevant. I'll address a few of the particular reasons I think are most important, and I'll try to phrase things assuming you don't know much about JSP. I don't mean to be condescending, but far too often this type of question is asked simply because the person doesn't really understand what the J-starting acronym really describes. If you aren't that type of developer, then please bear with me, I'm assuming there are plenty of other developers who will certainly appreciate an answer that doesn't assume much.

My reasons for why JSP is still relevant.

1. JSP is a key part of the J2EE Web Tier
2. JSP is The standard
3. It is easy to use JSP in amazing ways

JSP is a key part of the J2EE Web Tier

J2EE is huge, and almost all of it is good for at least one particular task. People do spend a lot of time (namely JSR expert group people) designing each and every J2EE related technology, which means in general something helpful is made. Note, this does not imply that your work will benefit from every J2EE technology, say JSP in particular. So let us be clear on what JSP is good at, and then you can decided if you are trying to do that, or if you could care less -- either way we should hopefully agree JSP is a technology worth keeping around.

So what is JSP good for? JSP is great for generating dynamic web pages, think any web page that uses markup, e.g. HTML, XHTML, WML, or even just plain text. When I say "dynamic" I mean something that changes. A good example would be an on-line store like Amazon.com that takes a little bit of information from you, say a title of a book, and automatically generates tons of HTML-based web pages that try to get you to purchase something. This is dynamic because Amazon.com certainly doesn't have billions of HTML files saved on their servers, it wouldn't be practical. Amazon.com only keeps around key information about books, and when needed uses JSP to generate HTML on the fly. A bad example of dynamic is something like my personal resume. It is nothing more than an HTML page I update maybe twice a year. It makes a lot of sense to simply code my resume by hand, using only HTML, and let people download it as is.

JSP is really the only good technology to do this in the standard set of Java/J2EE tools. Now that is an over-simplified statement, but it is true. There are several other technologies such as Servlets and JDBC that are almost always used with JSP to get the job done, but if you try to make dynamic web pages without JSP it takes a lot more time and effort.

In summary, I'm saying if you want to make dynamic HTML, XHTML, or text and send it over the World Wide Web, JSP is what you should use. That is why it is important. If you don't want to believe me I'll give a link at the end that does a proper job of arguing this point against the millions of common counter-points developers have. Now to move on....

JSP is The standard

A key thing to understand is that JSP is a standard. It has been around for good deal of time, lots of companies have dumped lots of money in to it, several other technologies are based on JSP, and there are tried and proved successful uses of the technology. In short, I'm saying any other Java technology that is trying to compete with JSP and isn't part of the standard J2EE API is more or less worthless. I don't care if you want to argue that something is more elegant, or that you can show me an open-source project that has a few top quality hacks working on it. None of that matters. JSP does get the job done, JSP can do a great job, and you can make a good living off of programming JSP/J2EE knowing Sun, IBM, Oracle, and a slew of other companies will keep the money flowing. Other projects like WebMacro/Velocity have lost. They are bitter, and they should be. Some really neat ideas and some great code might have been produced, but they certainly won't get much credit when the next version of JSP incorporates those features.

In summary, I'm saying JSP is relevant because it is a standard. As an average developer you should forget anything you hear from other non-standard Java technologies. Sad, but true, especially if you only care about making a living as a Java web programmer.

JSP is easy to use in amazing ways

JSP can be used well, and it can do amazing things. I've spent several years of my life figuring this out. I've tried the alternatives. I know about the other open-source projects. I've helped the JSP expert group. And I've spent a year of my life writing a book about this very topic. If you want to build a good web application that is fast, efficient, and easy to maintain, JSP can do it. If you don't believe me the best I can do is tell you to do some reading. Check out Sun's website, read java.net, read JSP Insider, or simply read my book. And you are right if you are thinking I'm just pushing what I like. I like JSP, but I say that because I've tried just about every other solution to building web applications. I've dealt with the poorly funded open-source solutions, the hyped commercial solutions, and even some home-brewed attempts to improve the state of things. But I think JSP is the best.

In summary, I'm saying that I honestly think JSP is a great technology, and I think I have the experience to fairly say so. Especially considering JSP 2.0, there are far too many helpful things that you can do easily with JSP. If you understand the technology, you will get the job done and you can certainly get the job done well.

And that is why JSP is still a relevant technology. I really wish I had the time to type out each and every bit of knowledge I have on the subject, in particular some of the really slick coding tricks that would completely solve your hard to maintain JSP problems, or reasons you shouldn't bother with stuff like WebMacro/Velocity, but I seriously just got done doing this in a JSP 2.0 and Servlet 2.4 book that went on sale a few days ago. Go buy it if you want an instant fix, or try to ask some specific questions on my points above if you want a slower, free-loader fix. I'll try to answer as many questions as I can as long as you keep sending them to me -- feel free to make them specific so I can try to show some code or talk about JSP 2.0 features.

Jayson Falkner - jayson@jspinsider.com

Comments

• Hard data?
  Has anybody done any benchmarks on the various approaches? For example: At run time, does the servlet that is generated by a JSP respond faster then a page generated by a Velocity template?
  

  Posted by: johnreynolds on October 09, 2003 at 11:16 AM

• I don't think you answered all of his question
  He said "The application programmer has to do the work since there is no clear seperation of content and code." You didn't seem to address this specifically.

  Posted by: keithkml on October 09, 2003 at 01:08 PM

• Just because JSP is a standard, doesn't make it good
  The major problem with JSP, IMO, is that it requires a great deal of discipline on the part of the programmer, as well as a sophisticated tool, to avoid writing unmaintainable JSP pages. Not only that, but even with custom tags, it is next to impossible to get a graphics/web designer to build a JSP page, without also needing to know how to program.

  That is bad. Velocity doesn't help that much, since you still need some basic programming knowledge. Tapestry offers the best solution that I have seen yet. Every page is a nearly standard HTML page, just using extra attributes in the standard HTML tags to indicate the dynamic parts of the page. Trivial for any HTML editor to work with, and a clean separation of coding from presentation. Since Tapestry is a servlet, it is also J2EE compatible, but with the advantage of not having to learn JSP/taglib/JFC/etc.
  

  Posted by: rbk on October 10, 2003 at 01:50 AM

• Hard data?
  I can sortof answer that. We used to use a struts tiles tag solution for templating our pages. A year or so ago we moved to a new system I wrote which uses dreamweaver templates directly, only using jsp for replaced parts of the page. This template engine is quite similar in philosophy to velocity, ie. we cache a parse tree and display from that, rather than the compilation model of jsps.

  The relevance is, one of the reasons we made this switch was because of the horrendous compile times of jsps when they were used for demos. A page using tiles which had 5 or so templated parts could take 12 seconds to render. Obviously this makes your system look pretty crap when trying to make a sale!

  Yes I know we can precompile, but you lose some of the flexibility in being able to modify the jsp, and precompiling "as standard" added about 1min to a build cycle, which was beginning to tick the developers off. We got other benefits from the new template system anyway, the point is we did actually measure the performance.

  JSP:
  1st page view - 12s (5 tiles)
  subsequent views - 0.015s

  Non-compiled templates, same page:
  1st page view - 0.2s
  subsequent views - 0.02s

  Times are approximate, on my 800Mhz laptop, that was with Tomcat 4.0.3 (I know, I know - it is slow). While JSPs are faster on subsequent views, the difference is small, and site performance now dominated by things like DB access, so we don't feel the loss.

  Memory usage is comparable to the JSP solution. The stuff we use this for doesn't get a huge volume of hits, so I can't comment on whether we'd suffer under heavy load, but the thing was written to scale up. I'm sure velocity users could tell you a similar story.

  Posted by: ba22a on October 10, 2003 at 03:14 AM

• Just because JSP is a standard, doesn't make it good
  I agree. I mentioned JSP is the standard because that is important. JSP is here to stay, regardless if it is good or not. In a seperate point I claimed I think JSP is good.

  I kind of agree with your point about discipline on the programmer's part, but that is something common in just about any technology. What I think is a more important point is that you need to understand what you are doing before trying to do anything serious. However, that is not always an option for real world programmers, and that is exactly why I'm trying to share some of what I think is helpful.

  I promise I'll soon publish a blog about the general strategy I think one should use when developing with JSP. I think that will go a long ways in answering most of these questions people are asking. I don't promote use of everything JSP has to offer. Most all of it is helpful for specific things, but, in general, the best code I produce is nothing more than an HTML page with a few JSP expressions and a JSTL tag or two...scripts, custom tags, and almost any other code just results in a messy JSP. IMO, the trick is enforcing developers code clean JSP, and you can do a pretty good job of that easily.

  Posted by: jfalkner on October 10, 2003 at 11:33 AM

• I don't think you answered all of his question
  I guess I only implied my thoughts on this. Part of what I consider good JSP programming is breaking up who does what, and ensuring each person doesn't step on the other's toes. Basically letting a HTML/graphics designer, a Java coder, and a database person work together.

  As I mentioned above, I'll be writing up a blog about this in the near future. It is something I think is really important, and I want to devote complete attention to it.

  Posted by: jfalkner on October 10, 2003 at 11:36 AM

• Hard data?
  I don't think you are asking a good question at all. The important thing is that whatever you are using is fast enough for what you are doing...there really is no benchmark someone else can make that tells you this. Java/JSP/J2EE is almost always fast enough to get any particular job done.

  Please think about my answer, it is important to understand.

  Posted by: jfalkner on October 10, 2003 at 11:44 AM

• The quick and the strong
  first of all; thank you for taking considerable time to write a lengthy response. Very nice piece!

  your point that JSPs integrate perfectly with J2EE stuff, and even going as far as saying that j2EE/JSP is the only for way dynamic websites is good to hear you say. It just points me to a real problem in the Java world; EJBs and other database stuff is still the only thing people will see as good products.
  I readily accept that with the only note being that I hate EJBs for their over design and at the same time not allowing something as simple as inheritance.

  As to JSPs being the standard;
  Windows is also a standard and as someone who has not touched a WIndows machine in many years I can tell you that standards are not all they are cracked up to be.
  You still have to deal with incompatible upgrades and buggy versions/3th party products. The same concepts that maintain a (relatively) good backwards compatibility also limit innovation.
  As with the surprisingly easy transition Windows users migrating to Linux, it is also really easy to make JSP programmers learn WebMacro/Velocity/Tapestry.

  To your last major point I agree while saying that you have to pick the tool for your job. Its all part of the equation.
  I consider the freedom of JSPs a limiting factor as I have to babysit my developers, which costs me time, and the company money.
  I consider the standard a pro if I have to hire external people; but then the previous point kicks in extra hard, which makes it kind of a neutral.
  In the end its about the features you want to support; and if your shop is into EJBs, JSPs are a good idea. If you use POJOs (maybe ven with an database layer that does not need J2EE) its the tag libs and similar features that you have to look for.

  I'll keep to WebMacro since it is the only engine that I know that provides clear content code seperation.
  I wrote a servlet with an earlier version of WebMacro that got 2 or 3 facelifts, with different workflow and different pages, while the servlet code was never changed (never even restarted/recompiled the servlet engine)
  I call that very powerfull and complete. Even for a loser technology :-)

  Posted by: zander on October 10, 2003 at 12:43 PM

• correction-- The quick and the strong
  This is a bit poorly worded:
  EJBs and other database stuff is still the only thing people will see as good products.

  I'll rephrase:

  EJBs and other J2EE based technologies are still the only thing the industry views as the only good database access tools.

  And let me request that the annoyingly tiny entry form (in replies) can be at least twice as wide. Better is to make it user adjustable...

  Posted by: zander on October 10, 2003 at 12:47 PM

• In JSP can you...
  You asked for a technical question and how to do it in JSPs.

  What I like in WebMacro is that it allows you to fetch a 'require' field from the target webpage (the file just loaded from disk) which allows the servlet to place certain object in the parsing engine to resolve stuff.

  Example:

  preferences.wm
  #require "user"
  Your user ID: $user.ID

  This allows me to completely decouple the page names (and thus the workflow) from the servlet engine while still allowing no code in the target pages.
  Take note; for example; that this moves the security of your datastructure to the servlet, and out of the pages the designer can edit. This is very usefull if you reuse your data objects for a client side GUI as well as a website (and maybe more)

  How do you do this in JSPs?

  Posted by: zander on October 10, 2003 at 12:57 PM

• In JSP can you...
  I seem to be having loads of trouble convinsing this site to do what I want :(
  Retry:

  You asked for a technical question and how to do it in JSPs.

  What I like in WebMacro is that it allows you to fetch a 'require' field from the target webpage (the file just loaded from disk) which allows the servlet to place certain object in the parsing engine to resolve stuff.

  Example:
  preferences.wm
  #require "user"
  <p>Your user ID: $user.ID

  This allows me to completely decouple the page names (and thus the workflow) from the servlet engine while still allowing no code in the target pages.
  Take note; for example; that this moves the security of your datastructure to the servlet, and out of the pages the designer can edit. This is very usefull if you reuse your data objects for a client side GUI as well as a website

  How do you do this in JSPs?

  Posted by: zander on October 10, 2003 at 01:12 PM

• Hard data?
  You're right about the general usefulness of benchmarks, but I think you have his intention backwards. Most people would be prepared to believe that since JSPs get compiled, they should be faster than an "interpreter" approach. Most people would also know that the time taken to render a JSP is a small part of the time taken to handle a typical request. How I read the benchmark question was: "other template approaches have advantages not related to speed. But is the interpreted approach so much slower, or resource intensive, that it will significantly affect my response times?"

  Posted by: ba22a on October 11, 2003 at 03:56 AM

• Standards compliance and content separation
  Jayson, I agree with your remarks about JSP. Many times, developers won't even have the choice: customers often specify JSP because it is the standard. But developers who do have a choice should think twice before leaving a customer with non-standard technology.

  But the concerns of some posters about content separation are also valid. JSP, like all template languages, mixes static content and program logic. This is a problem because there are two roles involved in JSP creation: an HTML author responsible for static content, and a programmer responsible for program logic. Regardless of the hype, tag libraries don't really solve the problem either, because custom tags are not standard HTML.

  The conflict between standards compliance and content separation led me to create Dynamator (http://dynamator.sourceforge.net). It generates JSPs (or most anything else, including plain Java) from files containing HTML and files containing program logic. HTML authors use standard HTML; programmers can use any language and technology they want (including custom tags).

  So it is possible to achieve content separation with JSP.

  Posted by: jaydunning on October 12, 2003 at 10:48 AM

• but what about the gui tools?
  While I agree whole-heartedly with most of what you've written, I can't help but wonder whether web designers were really in mind when JSP was designed?

  Sure, JSP tags look great in an XML editor, and as a developer I find JSTL-based tags great to work with.

  However, Microsoft and ASP.net are really pushing the tools frontier with ASP.net - it's all designed to be trivial to use with a point-and-click interface, rather than an XML editor.

  I can't help but wonder if this point-and-click simplicity is going to attract far more (lazy?) developers than the JSP approach, which requires them to take a disciplined approach to do anything useful.

  When you consider that good JSP pages require a well-coded controller servlet/action as well, then I can't help but wonder if JSF is going to have to be *really* good to stop web designers begging for ASP style dev tools...
  

  Posted by: lee_ on October 13, 2003 at 12:28 AM

• Hard data?
  Again, I don't think you are asking the right question. Interpreting a script versus compiling code really doesn't matter to the users of your site.

  The short answer to your question is maybe, it depends on what you are trying to do. J2EE/JSP will let you make really big web applications -- that is what it was designed to do. However, ask yourself if you are trying to build a really big web application. If you are only buliding a small one, and you have a decent server, you can pick just about any solution you like in which case I'd argue JSP due to it being the standard....

  Just for kicks, yes in theory the JSP approach is better. Don't forget you can compile the JSP before deploying the web application. Then it really is compiled code versus interpreted, and by definition the compiled code is faster...that is assuming you are using the same algorithm in each. However, this theory ignores almost everything practical such as caching, load balancing, database connections, and session management.

  Posted by: jfalkner on October 13, 2003 at 07:13 PM

• In JSP can you...
  In JSP this is done by what most people call "Model II", but really you are filtering a request before letting it reach a JSP endpoint. The quick and dirty solution is to code each page in two parts, a standard servlet filter that intercepts all requests to the JSP you care about and JSP that is nothing but a HTML template. Put all your Java/DB-accessing/form-processing code in the filter, pass values using request scope, and have the JSP use nothing but simple expressions to show the request scoped values. If needed, write up some code to ensure developers don't use anything but simple expressions in the JSP.

  This technique works really well, and if you understand it and generalize it a little you are well upon your way to being what I'd call a good JSP developer.

  I know my explaination is weak, but this answer really deserves a proper writeup, which I'll do soon enough. For now, here are some code examples that JSP Insider uses -- note: I have *all* of JSP Insider's code on-line thanks to the source-code showing servlet from Servlets and JavaServer Pages; the J2EE Web Tier. In general, I suggest you play around with JSP Insider's code to get ideas to make your life as a developer easier.

  The examples I wanted to show are as follows: a class (index.java) that loads news items and puts them in request scope and a JSP (index.jsp) that uses simple expressions and the JSTL iteration tag to display results. The filter that loads index.java whenever index.jsp is requested is the simple model II filter from http://www.jspbook.com.

  Posted by: jfalkner on October 13, 2003 at 07:53 PM

• The quick and the strong
  You are most welcome, I'm glad that you enjoyed the blarg.

  On you first point, EJB should be used. I didn't say this, and actually if you check out my book you'll see I don't really like EJB at all -- I promote not using them in most every web application you'll ever make. My big philosophy about building web applications is that you ca get the job done well (and quickly!) using JSP/Servlets/JDBC and by spending a little time thinking about the best way to do things before you start coding. Yes, I still say use JSP because it works well with J2EE, but I don't think that implies you have to use J2EE as popular belief dictates.

  About your second point: Windows versus Linux is like JSP to WebMacro/Velocity/Tapestry. My point is that you shouldn't care about non-standard technologies, but I'm glad to see you challenge it. In the case of Windows versus Linux, I think you are right. Windows is a standard that is fading away. However, if you recall Linux way back when it was first making some noise, you should also recall it was stupid to quit a well paying job as a Windows developer to start coding open-source/Linux apps. Only after a long time, lots of effort, and enormous amounts of resources (i.e. corporate funding) has Linux become a viable solution. Linux has hit the critical mass of users, and it is starting to set a new standard. However, if you fit JSP and something such as say WebMacro to the analogy, you are still back in the day when it was stupid to quit your job as a JSP developer. JSP is The standard, J2EE does have funding and J2EE will be around for awhile to come. Any project with a few loud, non-financed developers coding away on it isn't worth quiting your job over. That is just the way I see things from the perspective of a guy wanting to make a comfortable living as a Java web application developer. As a curious, open-source proponent, I think creative, non-standard, open-source solutions are awesome and there is much to learn by figuring out why a good developer spent time to build it -- but I'll still try to roll good ideas in to the next version of JSP....

  On your third point. Great, I'm glad you agree. It really is just common sense. However, I am now very eager to try and explain the method I promote when developing with JSP/J2EE. I feel you can use a little creativity to dramatically reduce the freedom of JSP and in turn reduce the amount of developer babysitting, all while still building a great web app. It really isn't hard, especially with JSP 2.0. Give me a little time and I promise I'll publish at least one good, free article about how to do this.

  About sticking with WebMacro. Great. I'm glad to see we both agree the greater point is that the job needs to get done well. As long as you can do that, and you are happy with the amount of time and effort it takes, you definitely have a good solution.

  Posted by: jfalkner on October 13, 2003 at 08:29 PM

• Hard data?
  Oh no! Now I'm completely fished in, I only meant to write a short reply, but it appears you didn't read what I wrote, so I need to explain it? "Interpreting a script versus compiling code really doesn't matter to the users of your site" - well, duh. They don't care if you use coldfusion or perl cgi, either. But thats not the point, this is:

  "other template approaches have advantages not related to speed"

  And as I said, people are prepared to believe that JSP is fast enough, and can scale. They move to other languages because of development issues, not the end user experience.

  For example, with JSP, the developer needs "something else" to manage interactions with other code (e.g. use struts as your model 2 framework). Then they need a bunch of custom tags, a whole heap of standard actions... advocates of Expresso or Tapestry would point at how that all comes "out of the box".

  With JSP, up until JSP2, the language wasn't designed to work outside the servlet framework. So you need something else /anyway/ to template emails, sql, etc etc. Velocity advocates would point at their generic template framework. They'd also point our how JSP lets developers write really bad code (scriptlets) that isn't possible under their system.

  Typically website designs are developed as a static image, then as a set of html pages, then, in JSP land, we alter or copy those pages to make the site 'active'. Updates to the design must be done to the JSPs (not only is this awkward for non-developers, they can't even see what it looks like without deploying it) or you go through another round of copy and paste. Hence why we wrote our own templating system, with JSPs only used for the most basic markup.

  Now you see the issues. People are not questioning the scalability /for performance/ of JSP. Instead they consider alternatives because they run into problems scaling /development/ and /maintentance/ of JSPs. However, they know JSPs scale for performance, to the extent that "everything practical such as caching, load balancing, database connections, and session management" matters more. They want to know that this would still be the case after a change not non JSP, ie that it "really doesn't matter to the users of your site", because it doesnt degrade performance horribly.

  Hence, a thumb in the air benchmark that shows non-JSP performance doesn't suck so bad would give people the confidence that they can try a development model that doesnt suck so bad. And again, yes: benchmarks are just a guide. But you don't expect a PC benchmark to tell you exactly how fast it will be in your own everyday use, just in a "typical" usage scenario.

  The question that prompted your article was expressing concerns pretty much like the ones I mention above. In response, your argument appears to be not on technical merit, but on the social network effects of standardisation: as a developer, you are more hireable knowing JSP; as an employer, you will find it easier to hire JSP authors and buy JSP tools. All true, and this is unarguably the unique selling point of JSPs.

  However economic arguments like this fail when their cost assumptions fail - ie, if the additional cost of developing with JSPs is more than the cost of retraining people to use an alternative. This is precisely what we found; we still use JSP for small parts of our sites - I'm not totally "agin it" - but mainly we use in-house tools.

  Anyway, ranting hat off. I promise I won't flame any more, even if you write saying I'm on crack. Look forward to reading your blarg in future!

  Posted by: ba22a on October 14, 2003 at 03:49 AM

• In JSP can you...
  What I miss in your news-example is the decoupling of the pages and the servlet code.
  Somewhere it has to be registered that index.java is needed to run before index.jsp is run. This is something that mixes content and logic in a more subtle way, but again moves your developer hours to the markup section.

  As a more complete example the require I I posted above can be 'user', 'order', or 'article'.
  All quite general terms that I programmed into my servlet for this website.
  Doing a request for article makes me see in the logs that the request failed because 'articleId' was missing from the context.
  So the html scripter puts that in in the previous page and voila, there is a page with article which you can query like '$article.Name'

  The point of the excersize is to dumb down the API (if you allow me to abuse the term) between the set of pages and the servlet to nothing but requeres and actions (which I did not mention in my example). This makes it a lot easier to maintain since absolutely no logic of flow control or page is put into the servlet. Into Java Code actually.

  Posted by: zander on October 14, 2003 at 02:50 PM

• In JSP can you...
  Right, index.java certainly needs to executed before index.jsp. A servlet filter does this. It implicitly attempts to execute a .java file to match a .jsp file. Information is passed using request scope. The whole code for the filter is over at http://www.jspbook.com, it is a simple Model II filter used to explain the same concepts.

  You really didn't miss anything. The whole system is as simple as knowing the foo.java file will get executed before foo.jsp. Likewise, bar.java will get executed before bar.jsp, etc. The JSP is dumbed down to just using simple expressions, such as ${article} or ${article.name}, and the JSTL iteration tag when needed. The classes created by the Java files are responsible for executing any other code you want, and you can use regular Java coding techniques to break the code up in to logical parts.

  We are both demonstrating the same thing. Is that a satisfactory answer?

  Posted by: jfalkner on October 14, 2003 at 04:41 PM

• Hard data?
  You are definitely not on crack, I appreciate the lengthy response. However, I'm still not sure what point you are emphasizing.

  The no-brainer should be that just about any modern technology for building web applications will get the job done 90+% of the time -- that is what I originally meant to answer in this thread. We seem to agree, and I think we are fine at leaving the benchmarks for this up to marketing.

  As for your greater point(s), I think you lost it in the ranting. However, I do see several you might be trying to bring up. Let us kill any appearance of flaming by trying to step back and tackle the worhtly points independently. If you can break your argument(s) in to direct questions, perhaps a good thumb in the air benchmark, and I'll try to answer with a blarg or two. Do you think that is a satisfactory way to answer this?

  Posted by: jfalkner on October 14, 2003 at 05:31 PM

• In JSP can you...
  This way of working does not make the servlet and its pages loosly coupled; more the contrairy.
  It requires me to know which variables will be needed in the page that I will let a designer write. Note the plural in that sentence.

  If the webdesigner in your news example thinks he needs a different front-page he will rename the page to 'news.jsp' and your system breaks. This is high-maintainance.

  So the question remains; in JSP can you do loose-coupling by seperating not only content from logic, but also flow (which page comes after which, and what names do they have) from the logic.
  And naturally; can this be done in such a way that the developer will not be tempted to hack around the system making the whole excersize moot.

  So far I have not seen why JSPs have indeed grown to be regarded a viable replacement to WebMacro. Indeed I still stand by the point that JSPs are to those templating languages are c stnds to java.

  Maybe you can do it correctly; but its so much work that nobody really does it.

  Posted by: zander on October 15, 2003 at 01:37 AM

• Hard data?
  Please read the following article , I agree with you that the cost of developing a JSP site is much higher than others,

  http://www.macromedia.com/devnet/mx/coldfusion/j2ee/articles/hybrid02.html

  Posted by: commoncents on January 09, 2004 at 06:55 AM

This work is licensed under a Creative Commons License.