JSP Does NOT Suck!

Posted on by

JSP does NOT suck! Uttering those words is against the conventional wisdom of so many at javablogs.com and elsewhere. I feel the expectation from many Java developers – for JSP to provide easy seperation of HTML and logic – by default – is unreasonable. If that were it’s main goal – then it’s a failure. But if you look at JSP as a PHP/ASP/CGI competitor – feature for feature it’s stands on it’s own two feet. What’s missing is the availability of it for your average web dev hacker.

Don’t you think MovableType could be written in JSP? Of course it could. And it probably would be easier to maintain, more scalable, and easier to extend.

But not to deploy. The market for MovableType would shrink to such a size as to not make it worth the effort.

Seperation of logic and design in JSP does suck. But honestly – is it any better with CGI, PHP, or ASP?

Just as in apps developed with those languages, if the goal is for designers to manipulate HTML and avoid dangerous logic code, then you embed a templating language for them to interact with. Would you let a web designer touch your CGI scripts? Hell no! Then why would you in your JSP?

MovableType does this. Why couldn’t a JSP app do the same? Fact is – they can.

There are a growing number of templating languages that suit this purpose and are available for Java developers today.

Saying JSP sucks is like saying Perl sucks.

And that couldn’t be farther from the truth.

10 thoughts on “JSP Does NOT Suck!”

  2. Thanks 🙂 Good to know I’m not alone in the weblogging universe who thinks the same 🙂

  3. I think JSP is fine. You can do a great job of separating presentation and business logic with JSP if you’re disciplined, and I’m not a big fan of taking functionality away from myself to enforce discipline. Sometimes there’s just no way around using a scriptlet, and if you are disciplined, you can usually do everything with standard or custom taglibs. And things like JSTL and the Struts taglibs are making it easier than ever to avoid mucking up your JSPs with lots of random scripts.

  5. The major part of jsps that suck are the error messages, one simple mistage and most JSP engines create the worst error messages this side of Microsoft.

    This just kills the entry level programer, a big chuck for the ASP/PHP crowd.

    -Peace
    Dave

  6. I *hate* JSP errors to Dave. I wonder if that’s the fault of the container or the spec?

    And Rafe, yep, that’s the way I see it too.

    Lance, I think that Roller, while the feature set is similar to MT, had a different initial audience it was developed for. Like you said, one of the goals of Roller was to explore development/design practices with Java. I think MovableType, on the other hand, was thought of as a commecial product early on.

    Efforts like FreeRoller mitigate the whole platform issue and testify to how cool Roller is.

  7. The crappy error messages from JSPs are very much dictated by the container. With Resin, the stack traces that are printed show the line number from the actual JSP rather than the servlet that the JSP was converted into. That alone helps a ton. I would assume that other containers would start doing this as well.

  8. I think the key point is that JSP is relies on the use of best practices to separate HTML and Logic.

    I have developed an alternative approach to JSP, which I belive provides a much better separation of HTML and Logic. The Server Pages use XHTML and are processed as XML documents rather than converted to source code.

    The server pages are called HTML Server Pages or HSP for short. HSP are supported by an Open Source framework. For more information visit http://www.brillsoftware.co.uk

  10. The problem with you idiots is you can’t think of anything better.

    This lame statement doen’t make it right:
    Seperation of logic and design in JSP does suck. But honestly – is it any better with CGI, PHP, or ASP?

    Most of the web technology out there might as well be spaghetti code written in BASIC with GOTO statements.

    The industry needs to take a good look at the mess it’s creating and stop handing over simple design solutions and try to think beyond the obvious.

Comments are closed.