JSP compared to ASP, Coldfusion and PHP

Discussions

News: JSP compared to ASP, Coldfusion and PHP

  1. JSP compared to ASP, Coldfusion and PHP (6 messages)

    A recent eWeeks lab review compared JSP to ASP, Coldfusion and PHP. The conclusions were that ColdFusion is the most productive choice wheras JSP technology offers best growth path for enterprises. ASP and PHP get the job done but didn't have significant value adds over the Coldfusion and JSP.

    Read the review on zdnet.
  2. This article seems to imply that one must/should choose a
    Web scripting tool among the presented four.

    Surely, a Web developer should be able to work independent of the technology on the Web server. The interface to the data model should not be via JavaBeans using JSPs or some proprietory Microsoft format.

    In contrast, establishing an XML interface to the data model provides flexibility in the way the data is rendered in a fashion that is wholly independent of the server-side technology.

    For example, consider a table of stocks,
    1. It can be encapsulated by a JavaBean and accessed using a JSP but this ties the web developer to the Java tech and requires a servlet container to be in place.
    2. It can be accessed using PHP server-side includes but causes the same problems in 1.

    If there is a standard XML interface, then one can use compiled stylesheets to transform the data and still abstract presentation logic from core business logic.

    This allows the web/xsl scripter to have finer control over the presentation and also promotes portability.

    RFC
  3. The problem with the standard XML interface is rendering it at the client side to HTML (or broswer supported format) using a style sheet is not supported in most browsers. How could you render the XML server side without the server side technology such as a servlet to handle the XML/XSL translation/render? If you force the user to use a late (IE5+) browser to keep the server side less proprietory, then surely the client side just becomes the proprietory piece instead? or have I missed the point?

    Regards
  4. Thanks for the reply John,

    The factor that makes this solution workable is that one can obtain/write an XSL/XPath transformation tool regardless of a platform or programming language.

    Just as you can use Xalan with your Java servlets, you can also use Microsoft's XML SDK with its XSL/Xpath extensions
    in a different environment.

    The overriding benefit is that a web developer can write a single platform-independent web page that fetches data from an arbitrary web server be it a Tomcat-enabled, PHP-enabled web server or even pure IIS.

    All is needed is an abstract interface to a middle-tier data source (servlet|CGI script|OCX) that specifies the location of a an XSL script or compiled stylesheet. The actual format/means by which the data model is produced is
    not externally visible.

    The middle-tier data source then transforms (using the styleshhet) the data model and presents the data in a clean elegant way.

    The stylesheet to use can be static or dynamically indicated using standard HTTP syntax.

  5. The performance comparaison , put JSP in the dust.
    however they used Tomcat ...
    I wish they would have used an optimized servlet engine
    (Resin , Jrun , Weblogic)
  6. Two things could have improved this review:

    As others have said, an optimized JSP/Servlet engine like JRun would have performed better. In fact, since a competitor was Cold Fusion, JRun would have been a more comparable JSP entry.

    The article seems to imply that they implemented the JSP "by hand", rather than using Macromedia Dreamweaver Ultradev or Allaire's JRun Studio, which would have boosted development productivity to that of Cold Fusion Studio. In fairness, Microsoft's Visual Interdev or Macromedia's Dreamweaver Ultradevcold have benefited the ASP efforts also.

    I wonder about the complexity of the test example if typed data slowed things down more than it spead things up.

    -Tom Schaefer
  7. For small shops, PHP is a good start. Beside being free, it's robust and fast. Later on, you can either do a complete migration to more OO languange like Java which make programming business logic easier. You also have to choice to do integration between PHP and java/com. Looking from this scenario, PHP is always a good start and allow possible extension. Best of all - it's free!