Follow Slashdot stories on Twitter


Forgot your password?
Programming IT Technology

4 Web Scripting Languages Compared 237

monkey crunch writes: "ZDNet is running an article comparing PHP, ColdFusion, JSP, & ASP. Although they don't show the script sources, it's interesting to note that PHP garnered the highest performance of the bunch. From the article, PHP: 49pps, ASP: 43pps, CF: 29pps, JSP: 13pps" PHP did gather the highest pps, but it's interesting to also note what the article gave top honors. In any case, it's an interesting topic, but remember: use what's best for you. Don't use what you feel you "have" to.
This discussion has been archived. No new comments can be posted.

4 Web Scripting Languages Compared

Comments Filter:
  • Here's a link []
  • The preview thing fux0rz things up! Fix it plz! Here is the prettier post:

    At Security Space [] you'll find all sorts of interesting stats, such as what kind of servers [] people use, what modules [] apache servers use, what technologies [] people make use of and what people author [] their stuff in.
    It's a really good site, which I use a lot to point out how many sites run open source products. Strangely I cannot find Tomcat there... Odd?
    • The database connectivity is far from perfect, and ODBC isn't the magic bullet some people like to think it is. While you can use ODBC to connect to an Oracle database, it will offer significantly lower performance than using the ora_functions.
    OK, but the same applies to the other languages. Using ODBC performance will be lesser, and using custom database access will be less portable. The article singled out PHP by saying that its database access was portability-unfriendly.

  • writing ASP's and backend code in VB - I have to say I was new to web scripting languages at that point and ASP was a bit of a revelation - it was like, 'yes! Now I can write my web sites in BASIC' ... Then after graduating I took a job at a web design firm- they were using JSPs - I took one look and realised it was basically ASPs, but with Java

    You can write ASP in PerlScript, JScript, Python, VBScript, etc. And ASP+, Microsoft's next "version" of ASP, will support, among other languages, C#, which is just alias java c#

  • As an experienced Java server coder I can vouch that the idea that using Tomcat 3.2 as a benchmark is utter stupidity. Tomcat developers and all benchmarks agree that either Resin [] or Orion server [] delivers the best performance for JSP. Tomcat is murderously slow in comparsion (ZDNet tipped it off when they said ASP was faster, which by no means matches my experience or general concensus). I have coded components (Bean) and extensions (taglibs) for JSP a few times and I have yet to come across a better general web scripting technology than this. Now I know that /. is the home of a lot of perl/C lovers but can all those companies who are ignoring M$ solutions and going for the Java solution really be that wrong. Anyway to get to the point a java compiled JSP/Servlet container running a web application of JSPs, Servlets, taglibs and Bean, is a very good and portable solution (I am still forced to develop on Windozer but we deploy on Linux as well as Win2k and WinNT). "Think of something cool and tell yourself it`s my sig" -me adapting a quote from BtVS
  • Fortunately VB7 will support try/catch/finally blocks.
  • "and it is very difficult to maintain"

    100% recycled BS. I am the only one who tires of this complant. Perl is not hard ot maintain, bad programming and design structure is hard to maintain. I have been involved in 25K LOC projects with an established coding standard and naming convention and variable scoping rules. Ease of Maintainance exceeded any C project I have ever worked with and a 25K LOC Perl project is probably worth 35k of C or C++ code for equivalent functionality.
  • did you have any source control? i sure hope so. Visual Interdev integrates nicely with VSS- you can check files in and out directly from VID. Did you ever need to check the MSDN for help with your ASP? if you have the MSDN installed (which you should if you are working on a fairly large project using ASP/COM), just press F1 in VID and viola, whatever you have highlighted automagically pops up in the MSDN help files. Or what about deployment? didn't you need to deploy over multiple servers? VID simplifies this process nicely since you connect directly to the web server. hit save and the file is already updated on the server. open up the the test server as a separate project in the same window, drag and drop- bam- you just deployed to the test server. what about database access? you can browse the db directly from VID without ever opening up a SQL window.

    it sounds like you didn't even attempt to use VID for anything more than an HTML editor. forget the autogenerated junk- that's crap. but if you know how to write web code, you shouldn't need or want any of that anyway. VID offers a ton of productivity enhancers if you take the few moments to learn and use them.
  • you are correct that ASP isn't a language, but you seem to be searching for the correct way to define it, so here it is: ASP is an ISAPI filter on the web server that interprets any file with a .asp extension. all that means is that it's a DLL (asp.dll) that does the work if a .asp page is requested.
  • PHP can build dynamic PDF and figures ?

    Give me a break. You can generate dynamic GIF/JPG and PDF with all of the scripting languages in the article. PHP, being the kitchen sink of a language that it is, chose to bundle the GD library, and several PDF generation libraries into the language, and that's about all that makes it slightly advantageous in this respect. It's fairly trivial to create dynamic GIF/JPG images with JSP/servlets (Jason Hunter's servlet book had some examples), and there are at least three Java PDF generation class libraries that you can use to generate PDF from JSP/servlets.

    I will no even get started about ASP and CF-both can readily access COM objects, which opens up a whole bunch of opportunities since there are so many libraries available. PDF and GIF/JPG is definitely not a problem with any of these technologies.

    Whenever you're designing a comprehensive reporting application at work, coming up with a decent library to generate good-looking business charts is a problem with technologies like PHP, however. There is so much free and commercial Java and COM libraries available for JSP/Servlet and ASP or Cold Fusion developers, but not for PHP.
  • I learned ColdFusion in about two weeks, and I'm now making a ridiculous amount of money coding some pretty significant apps for my company with it.

    Say anything you want about what's better, what's worse ... but I'm sticking with this mealticket for right now. ColdFusion is great ... it's fast, easy, fairly elegant, and pays really well!!!

  • I've been forced to use JSP at work, and can't say that I'm too fond of it. It's a very powerful, solid web language. However, this power is it's weakness. Code and content really should not be mixed for anything more than just presentational logic. However, with JSP you have the ability to write arbitrary Java amongst your HTML. How can this be a bad thing? Well, if you make a concerted effort across your entire team to abstract the guts of your code into beans, you'll do pretty well. However, if you're in a rush (like most companies are), that standard will be the first thing thrown out the window, and you'll end up with a hairy mess: imagine 6 HTML pages within a single JSP, selected with a switch statement, where the main body of various tables are drawn by functions defined at the top of the file. Try handing that thing over to your web designers. Believe, they won't be able to make a dent, and you'll end up with a site designed by developers. It'll be very nasty.

    Of course, ASP shares these same problems, as JSP was modeled after it. The real solution to this problem is to use a scripting language which doesn't allow the intermingling of Java code and presentation. An example would be WebMacro or Velocity, template engines which use a very simple scripting language to access bean properties to display a page. A servlet inspects the HTTP request, performs all logic for deciding how to handle this request, constructs a bean representation of the data requested, and then passes this data to the template for display. This seperation is clean--the servlet is written by a Java programmer, the template by a graphics artist. They only need to communicate about what data will be passed between the two. It also enforces good style of not allowing arbitrary code to appear in your presentation layer--something which requires a fair amount of discipline--especially with junior developers--when working with JSP.

    The main thing JSP has going for it right now is market push. JSP was just a clone of ASP in an attempt to win mindshare by providing something familiar. {A,J}SP really isn't very well thought-out, but most people don't realize this because they don't know much about the alternatives. Compound this with the fact that developers don't mind mixing code and content, and you've got a pretty strong force in favor of something which can make web monkey's lives a living hell. It's really a good idea to look at the alternatives. Unfortunately, none of them have really reached the critical mass of users yet, but as sooner we make the transition, the faster they'll mature!

  • All of these scripting languages are available on both Windows and Linux (some on other OSes too). They took into consideration how easy it is to code in CF, why not take into consideration which OS a scripting language best runs on?
  • Interestingly enough Tesco (a massive uk chain of supermarkets) are implementing their newest checkout apps in linux! Conversely Sainsbury's (their major rival) use NT. I was amused to notice this when upon seeing familiar messages ona few checkouts in Sainsbury's I looked closer to see that Dr Watson had detected appplication errors and seen fit to close the checkouts.
  • by hey! ( 33014 ) on Tuesday October 31, 2000 @05:59AM (#663178) Homepage Journal
    You can't separate the tool from the kind of craftsman and job it is intended for. The reason I mention this is that comparing these scripting languages this way abstracts out the most critical details

    Thus, when you look at the "cost (Developer time)" score, what you are really looking at depends on the composition your team. It's just plain stupid to rank JSP/servlets as "C" and ASP as "B"; there are applications a skilled programmer can do with JSP that would be nearly impossible in ASP. In that case, JSP would be "A" and ASP would be "D". On the other hand, if you are relying your already overtaxed and underskilled Microsoft only IT app development department to deploy some very simple dynamic content, then ASP would rate "A" and JSP would rate "D" for cost.

    By the way, about a and a half year ago I took my small company kicking and screaming to Zope. I built a standard page framework with consistent but customizable layout, navigational elements and decorations. Was this costly -- you bet. We wasted untold time arguing over content that users provided that had hard coded positions, dimensions, font sizes, and IE only HTML extensions. However, once I got these people out of the layout business into the content business, we ended up with a web site that is consistent, professional, and constantly updated with no technical skills required at all.

    Moral: the cost to deploy is not necessarily related to the cost to maintain.

  • I use PHPLIB for its Template class.

    And, AFAIK there is no template functionality built-in to PHP4... yet.
  • by omega1 ( 9381 )
    Just to let you know, JSP actually will let you use other languages as well. It's not commonly implemented, but Resin from can use either java or javascript ...

    However, JSP is definitely slanted towards java ;-)
  • Actually, if you plan your displays before implementing them in xsl, and nail down your xml formats, xml/xsl is a very elegent, extremely maintainable way of managing display on very large sites. If your working on a site large enough to justify it, then the processing overhead isn't a big concern, you have the iron for it. And as for the added level of complexity at initial development... like all development tasks, the better you do it the first time, the easier it is to maintain on into the future.

    On the other hand, if all your doing is web counters, message boards, and fancy dhtml crapola... then you care about this [] much.
  • First a dsclaimer: I'm a principal developer of SteelBlue

    If you are intersted in web scripting languages similar to Cold Fusion, you may want to check out [] SteelBlue is a fully free and open source application server designed to produce dynamic database driven web applications.

    The core design of the language is similar to Cold Fusion in that regular HTML is extended with special purpose tags for doing things like SQL, data type checking, making select boxes, etc. This is supplemented with a "Eval" language that is similar in syntax to C. There is also a library of a few objects that can be manipulated to do things like parse XML or manipulate JPEG files.

    In addition hooks have been built to allow easy extension of the core language by anone who can write C or C++.

    This code is newly open sourced, so we are looking for whatever feedback we can get...what we have gotten so far has been good, so people seem to like it. Now all we need to do is get more people to see it! -Al

  • Is it just me or does ZDNET usually manage to select the most expensive, slowest product?

    I guess open source just doesn't buy enough advertising. We probably should be grateful that they even mentioned perl.
  • ... shows their cluelessness.

    ColdFusion is not an OO language, it is not even a structured programming language (you can't write functions that you call elsewhere in the same file). This means that any non-trivial web apps rapidly grow into an unmaintainable mess of code.

    And in spite of their benchmarks, any procedural code in CF is dog slow. If you hit on a bug (and there are quite a few) that causes problems with what you trying to do, you cannot switch app server vendors as you would with JSP.

    It may have been faster that Tomcat, as configured by them, but this does not mean that ColdFusion is faster than JSP. ColdFusion is interpreted, more so than Java, and is not nearly as optimised and researched as Java virtual machines are.

    The one thing I would give ColdFusion credit for is DB access, which is extremely quick and easy. You configure a DB connection in the CF administration interface, and you then refer to it by name in the code, no specifying all the connection info. This allows you to create dynamic webpages that show DB records much more quickly than with the competitive systems.

    In this regard, ColdFusion does for Web Apps what VB did for Windows desktop client apps, in that it allows very rapid development of frontends for databases. Arguably it is "the VB of web development", even more so than ASP+VBScript. But as you can imagine, the resulting code frequently ends up about as maintainable as a lot of VB apps.

  • I'd have to agree with the article that ColdFusion has a quick development time and is easy to use. Also, and I saw this refuted above, but it is also extremely easy to maintain and more portable than you'd think.

    I develop web applications for the USPS, and we use ColdFusion in the project I'm currently on; there are no portability issues to speak of with the basic cfml code. There *are*, however, portability issues concerning the CFX tags (ColdFusion extensions written in C++ and compiled as shared objects) and *anything* that mentions Java. I attribute the Java problem with the fact that it's an environment nightmare to get anything written in Java to run on different machines. The CFX problem was unintended, but Allaire made an error when they compiled the server using Sun's native C compiler (for the Solaris version). If you use gcc to compile your libraries, forget it; it will ungracefully crash and burn.

    So what are the downfalls? The same pitfalls come with ColdFusion as with anything not open-sourced. They don't fix their own bugs in a timely manner. I have personally discovered two bugs, one of which is really getting in the way of development (and stability), Allaire has officially recognized both and escalated the situation, but there are *no* patches to fix these problems and no sign of any help.

    If PHP had problems as large as these, were notified about it, and didn't have it fixed with amazing haste, I'd be disappointed.

    That's worth a lot more to me than being able to teach an idiot how to code and make it work, which seems to be the focus of corporate opinions.
  • A good web development team, no matter which language or platform you choose, will have a mix of people coming all the way from the pure inteface guys (including here the designers) down to the bare metal guys (including the usual daily-kernel-compiling guy). All projects larger than toys I have been working on for two years have had this configuration.

    As for ASP, the mix ASP/COM is the Microsoft-blessed way to use the technology since the beginnings of 1999 (almost two years ago). So, yes, you must have a good C++ guy in your team, otherwise you will be unable to scale up for too long with ASP. PHP will take you a bit higher before entropy takes over. Python is even better (now if only Guido would put the braces back where Nature intended them to be... :)).

  • 1. Not sure if I'd say Java is 'open' and 'non-proprietary'. There are apparently a lot of things developers would like to see in Java, but Sun is not implementing. I don't know specifics offhand, but one of the guys here does a lot of Java stuff and fills me in on the details now and then. Yes, you can see code, and yes, it's cross-platform, but I wouldn't say 'non-proprietary'.

    It's proprietary to Sun's specs. There just happens to be a large enough user base out there to make it seem common.

    2. A lot of packages don't, either. Or if they do, it's more 'java bandwagon' hopping than true support. Our latest experience is with the Adobe Acrobat 'bean'. Adobe seems intent on making it as hard as possible to do PDF work on non-MS platforms (no acrobat 4 for unix, for start) and the 'bean' they released is pretty low quality.

    They had a press release in summer 1999 saying how they were supporting Java through this PDF bean thing - the code we see in the Java itself is all marked 1998, and it's not been updated since.

    Not saying all developers are like this, but do some research before jumping into Java - just because people say 'works with Java!' doesn't mean it actually does.

    4. There are some inconsistencies we've come across between platforms that don't lend themselves to 'write once run anywhere' java mythology. Keyboard issues, for one. Also, Windows Java support is different than Linux, for example. I'm sure it can all be 'worked around', but it's not simple. (these are more 'graphic' issues, perhaps not important for server-side java work).
  • Python, Perl: How do you write a serious article about web scripting languages leaving these two out?

    the article mentions both python and perl on the 3rd page [].

    Perl is the mother of all scripting language

    the article actually calls perl "The granddaddy of open-source Web programming languages".
  • OK, would someone mind telling me why ZDNET refuses my connection when I'm running SLackware Linux but not when I'm running Windows 95?

    It makes absolutely no sense!
  • Depends on your point of view. CF can easily be extended with C, Delphi, etc.
    • Yes, I talk about recompiling. Recompiling takes time, especially with Java. Rule of thumb by a fellow Java developer (who, btw, loves Java): No matter what kind of hardware you throw at it, the JDK will make your system slow down to a halt.
    I'm a professional servlet developer (feels so good to say that - haven't been for long ;) ). We use jikes (IBM compiler that's DAMN fast) and compiling... well.. even on our largest modules takes only a couple of seconds. I have scripts set up to quickly copy files betweenmy development box and the destination server. One script takes care of everything, and I don't find the speed an issue. However, I did when I was using the Sun compiler.

  • by Atomizer ( 25193 ) on Tuesday October 31, 2000 @04:21AM (#663193)
    I'm suprised by the developer cost/learning score they gave to PHP. I always thought PHP was very easy to learn, even easier than ASP. PHP always takes less code than ASP in my experience. You don't end up with the "Response.Write" when all you mean is "print". Don't get me started about "MoveNext". Arg!

    On the other hand, I do think PHP needs a more consistent DB API. (I think they are working on it.) But ASPs is only consistant because there is only really one direct way, ODBC. If you only used ODBC on PHP all your code would be more portable among DBs. But it's much more fun to use FreeTDS to hit a MS SQL server with a Linux/Apache/PHP server than an expensive ODBC driver.

    I've also found that all of our contractors that we have hired that know ASP learn PHP very quickly. They all have the same comments about the PHP code being much smaller and easier to read. VBScript that is used in most ASP pages just doesn't quite fit the web as well as PHP.

    And another thing. ColdFusion is the cheap way to start a web project? I guess that fits if you rate PHP hard to learn and expensive to develop, but $5000 is a hard price to take up against free for almost anything else. Sounds like Dilbert logic to me. The most expensive product will obviously make our programmers more productive.
  • by Pengo ( 28814 ) on Tuesday October 31, 2000 @04:21AM (#663194) Journal

    For the first time the benchmarks where not the main focus of the article, but the ease of uses and development time in getting to market. I do stand behind their opinion of ColdFusio being something that is easy to get going and something built in one weeks time, but then you will run into the same problem w/PHP.. a bunch of code that is not reusable.

    Tomcat/JAVA is a great development platform. The PagePerSecond is not that relavent because you can load balance hardware and .. frankly.. hardware is cheep compared to human resources, etc. We have a very large application that was written in Java/JSP and it's very simple to manage. We have a large code base of 'Beans' and we use the JSP for the glue to the presentation. Our group doesn't utilize the taglibs yet, as our 'Bean' base is still under heavy dev.

    I do agree that there are some performance issues with Tomcat, but those are easily fixed by using something like Resin (GPL) or Orion (Commercial). Lots of small companies are looking for quick and dirty solutions that fit the budget. (Free) .. Tomcat is (IMHO) the best bet, because if your application grows and grows, you will be in a better position to manage the code. (Downfall of PHP).

  • by SamBeckett ( 96685 ) on Tuesday October 31, 2000 @04:22AM (#663195)

    I've been developing with most of these "web" scripting languages this past year, and I can tell you one thing about all of them:

    They suck.

    Yes, it's true.. ColdFusion is nice for rapid, small applcations, but anything over that you will be grinding your teeth because of limitations of the language.

    PHP.. PHP is in the same boat, but you can develop middle-sized applications before grinding your teeth. The language itself feels likc one giant hack and there is WAY to much built-in, no module support to speak of, and the "unified" DB driver sucks (ODBC has a performance hit). It's shoddy OOP and function support causes headaches.

    Java Servlets take FOREVER and a day to develop; ColdFusion and PHP beat the pants off of Java anyday; However, like I was telling my boss, "With Java, everything looks like a nail..."

    Can't speak for ASP, but I can say...

    Python. It's a better language (syntax, semantics, libraries, modules, OOP) than PHP any day.

  • Am I the only one who finds this statement on the second page of the article funny??

    "When performance does become important, various techniques are available that can make dramatic differences in speed. For example, Microsoft Corp. has rewritten the Nile benchmark we used in these tests..."

    So that's how you get the big speed, to hell with the application, rewrite the benchmark itself! *grin*
  • The point they were making is that it's a different interface to the same functionality, depending on what db you're using, and they're absolutely right. Since these languages are written (allegedly) for people who aren't exactly geniuses, that's a bad thing.

    PHPLib actually does a pretty decent job of addressing this problem in php3, but php4 didn't take that particular lesson from phplib.

    They didn't "single out PHP", they made some constructive criticism. All you slashdroids need to learn the difference.

    "Don't trolls get tired?"
  • JSP would've done better if they had used Caucho's Resin []. It's lightning fast. I'd be interested to see the results of a more comprehensive test covering more app servers.
  • ASP = Actually Slow Pages.

    Okay maybe not. I have used ASP, and I did not find it all that. I have used PHP, and I liked it better than ASP, but I find both a bit slow and 'limiting'. ASP is usually done in VBScript, so if you have had any experience with Excel or Word Macros then you would feel right at home.

    I think perl is actually better, but for true speed I'd use C.

    I have heard of JSP servers going down when the garbage collection suddently kicks in. Think of a busy web server that does not have time to do its garbage collection. At some point it needs to do so and when it does, everything else stop or slows. This is just a part of Java though. It happens in any one of these languages that the authors mentioned too. Perl is better about garbage collection I think than Java, at least in my experience with the two.

    DON'T use tcl, or you will regret it.

    I don't want a lot, I just want it all!
    Flame away, I have a hose!

  • WebObjects had three great things going for it: great tools, fantastic database connectivity middleware, and really solid web scripting and tag extentions.

    It still does. The main Problem with JSP's (& ASP's and CFM's) are that they are all the same. It is *possible* to design a good app using them, but the default paradim encourages lazy coding and mashing all of the Code & HTML & Data Store logic into one file. A gauranteed recipe for non-reuse, non-OO encapsulation, and headaches down the road.

    Model-View-Controler (MVC) is the core of most good design patterns. It seperates out the display logic, from the business logic, from the data store issues. WebObjects has this design pattern in its DNA, they've been doing it since way back. Multi-tier logical seperation of functionality is a GOOD THING.

    No matter what tool you are using, read Design Patters by the "Gang of Four" (tm) and Refactoring by Fowler. It will allow you to make a good design using any technology. Design Patterns was written and based on several peices of old NeXTStep technology (Foundation). And, they've been improving WebObjects constantly over the years. Check out the OmniGroup mailing list on WebObjects [], a lot of Apple developers subscribe to it.

    I think people should use the right tool for the job. I happen to use WO because it lets me be more productive than any other middle ware technology I've used (and I've used all the major ones). BTW: re Java - WebObjects supports pure Java (and will support Linux in the next version due out RSN).



  • Of the four languages reviewed, I have to say that PHP sucks least, but it still sucks. The developers plainly couldn't spell orthogonality much less define it, the documentation is simply awful, the interpreter's ability to detect, localize, and identify errors is on a par with stuff I used back in the punchcard era, and mixing PHP code with HTML and SQL produces results that are grotesque. I wish to hell someone would crank out an Apache modules that would make it easier to plug calls to compiled C or C++ code into web pages.

  • In my view, both should be all-out contestants in any serious comparison. What would be the point of excluding Perl if, for instance, all platforms your analize were worst than Perl? If you exclude it as "old", how would you know?.

    The exclusion of Python is also unforgivable. Just a look at Python's API is enough to notice how serious this language is becoming.
  • Besides being supported by PHP, it also have Java servlets, and it's own language Pike (based on LPC (an object-oriented C dialect)). Very featurefull, and cross platform, and the source is available.

    / The Arrow
  • for several reasons. I am currently involved in setting up a new website that just got some money. It is currenly running an assortment of perl and python scripts on a Zeus Server. After looking at a couple of options we decided on PHP on Apache, why? at this point it's cost. ASP or CF on NT with MS SQL is a little too much up front. And for us that was the bottom line. Having said that I realize that 5 potheads financing a website with VISA doesn't exactly follow the same rules as 'Enterpise Computing' decisions but hey I just wated to get in my $ 0.02 CDN. As an aside the most interesting config we looked at was ASP using Python and MySQL on a NT box.
  • first of all, JSP and ASP are not scripting languages. JSP is Java and HTML (not "based on Java". it is Java). ASP is not even a language. It is an ISAPI filter on the web server- a .dll that interprets pages with a .asp extension. The languages used in ASP are scripting languages (Jscript, Javascript, or VBScript). But the next generation of ASP -- ASP+ -does not use any scripting languages. You may choose your programming language of choice (not sure about Java- prob not, but you can use VB, C++, C#, COBOL- and more)

    And as far as JSP performance goes, i did not see it mentioned anywhere that JSP pages are compiled into servlets the first time the page is accessed. this means the first page view is extremely slow, but every page hit after that is significantly faster. ASP+ also will compile the pages as opposed to interpreting them on the fly as ASP does.

    ASP, in my opinion, is easier to write mainly as a result of Micro$oft's extensive development tools (Visual Studio and it's close ties to MS servers). but JSP can run on almost any web server- with little or no code changes- and it's not that much more difficult to write. And now there is the J2EE spec which claims no code changes are necessary if the spec is followed (from experience this is not true, but *very* few changes were needed to move an app from NT/JRun to iPlanet). I haven't used the other languages mentioned, so i can't speak about them.
  • by Daath ( 225404 )
    ColdFusion is their first choice? I dunno why, seems strange...
    CF and ASP should be bottom, PHP should win, and JSP should be the web-scripting to come, I see huge potential in JSP, but it's so slow...
    Porting the M$ ADO to PHP would be the greatest thing that has happened to PHP since the new scripting engine... But then again, we'd loose all our nice db classes =)
  • My experience with Tomcat is that it still has a lot of bugs/features under construction and is certainly not optimized for performance in the way that commercial servlet containers are. A more stable and robust servlet container (Allaire's JRun comes to mind) would have provided much more realistic numbers on JSP performance.
  • by Mr Neutron ( 93455 ) on Tuesday October 31, 2000 @04:01AM (#663224)
    Note that the Tomcat results shouldn't be taken as representative of all JSP engines. Tomcat is merely one JSP engine of many, albeit the "reference implementation" for JSP. It also has the advantage of being free software. However, lots of other web and app servers (iPlanet, BEA WebLogic, WebSphere, blah, blah) implement their own JSP/servlet engines. Their performance will definitely vary.


  • by under_score ( 65824 ) <{mishkin} {at} {}> on Tuesday October 31, 2000 @04:28AM (#663227) Homepage
    With JSP's performance measurement may be a bit more of an art than with the others. Since the JSP container (eg Tomcat) is often configured to compile any .jsp that has changed, it may have a serious performance hit attributed to it. However, that _feature_ is meant for development and would be turned of in deployment: all the .jsp files are pre-compiled. As well, the JVM used makes quite a large performance difference. The Win32 JVM with Hotspot, seriously outperforms some of the other JVM's (orders of magnitude difference). I don't really know about the Linux JVM's, but I have heard that they underperform relative to Sun's Win32 JVM. Basically, the performance aspect of the article is completely bogus: utilizing two completely different OS platforms is just the start of the problems!
  • I took a summer job at BT (the british telecoms company) two years ago, writing ASP's and backend code in VB - I have to say I was new to web scripting languages at that point and ASP was a bit of a revelation - it was like, 'yes! Now I can write my web sites in BASIC!'... of course VB isn't great, but it is easy to use (at least until it crashes). Then after graduating I took a job at a web design firm- they were using JSPs - I took one look and realised it was basically ASPs, but with Java, and was very very happy. JSPs perform great (the first time one runs it gets compiled into a servlet, which takes a second or so, after that access is just fine). JSPs have only got better since, though anyone looking at JSP should also think about XSLT, just for an alternative approach...

    At my current (, internet travel) company, I'm writing Java once more, and it's a pleasure- the only problem is that the front end of our site is naked servlets, dating from pre-JSP days, and we use our own propriety template symstem to generate the html- the template system has really starting to creak at the seams and it's not flexible enough to cope with our needs... we'll be swtiching over to JSP (possibly mixed in with some XML/XLST) soon....
  • by Staciebeth ( 40574 ) on Tuesday October 31, 2000 @04:30AM (#663230) Homepage
    I write Cold Fusion all the time, every day, and I have to say it's damn easy to learn and use (and write badly, but that's something else). If all you know is HTML the tag structure won't confuse you and so on. BUT...I just picked up PHP a few months ago and I love it. So much nicer. So much easier to read. Even though my Cold Fusion is still much stronger than my PHP, I would never recommend using Cold Fusion.

  • by tm2b ( 42473 ) on Tuesday October 31, 2000 @04:30AM (#663231) Journal
    Perl can't be taken seriously as a high-end web site development language. For large complex sites (slashdot really isn't either - it's a very straightforward single application), perl just doesn't have the performance one needs, and it is very difficult to maintain.

    Sure, perl works great as a quick way to put out code that works - but remember that it was designed as a report language, not a dynamic content engine. While there's an apparent similarity of these two tasks, they scale very differently.
  • I don't understand. I can take something coded in ado and move the databases and just change the connect string.... I moved one app from Access to something called to Pervasive SQL to Microsoft SQL and never changed the app code much at all...
  • If you know how to code and you get the proper tools you can debug your code real easily in C. Apache is done in C so if it is good enough for a web server then it is good enough for a web application as well.

    TCl is also used in Story Server and that program sucks. It is slow, it is not scalable, it forks processes as does ASP each time you go out of the . There are much better and faster things that tcl.

    I don't want a lot, I just want it all!
    Flame away, I have a hose!

  • I wrote ASP code daily, and have developed some rather complex apps in it. There are a few things in this article that smell like the author fell prey to marketing drivel or really has no experience with the tools.
    ASP makes programming easier by supporting untyped variables
    This tends to make my job harder, not easier. But then I cut my teeth on Pascal, C and Java, not VB. I, for one, don't like my variables shape-shifting on me (and they do that, just as they do in Perl).

    We used VBScript for our code, and we wish it had try/catch keywords; without these, writing error-handling logic was more cumbersome because we had to do manual checks in the code to see if errors had occurred. (ASP also supports JScript, which has try/catch keywords.)
    Well, the solution there is to use JScript, or write your error-prone stuff into functions (such as ADO SQL queries, object creation, etc.) so you only have to write the error-trapping code a minimal number of times. Code reuse = good

    ASP development tools are widespread and generally quite mature
    They are? The only decent one I've found is Visual InterDev, and it's lacking a lot of features that other MS development environments have and developers come to depend upon. And it's only in its second version.

    The biggest thing that they left out is the documentation. In some places, the ASP & VBScript docs are great, sometimes they suck, sometimes they're just plain wrong, or nonexistent. Every time I go into MSDN, it's a crapshoot unless I'm looking up something I had looked up previously and need a refresher on (like which is the search string and which is the string being searched in instr(); the tooltip just says "string, string2").

    The article also glosses over some of the completely undocumented, or barely documented, things that really drive developers nuts. Like when will 4-digit years be displayed, and when will 2-digit years be displayed? Answer: unless you write your own function to split the date into its pieces (day, month, year) and compose a string, it depends on the server's regional settings and the currently-logged-on user's regional settings.

  • The biggest problem with web scripting languages, is that they are just that - scripting languages. They're being pushed as more than they are. If you need great performance, and a REAL language, why not write your own server, or base one off of an already existing server? That means write your program to the API of a server - like apache - or if you need extreme specialization, code something your self. I'm getting to the point where I'd like to try something like Eiffel to help me to improve the security and stability of my web based applications.
  • With the exception of your Python recommendation (I prefer Perl, so let the holy wars begin :-), I second everything you just wrote.

    Java Servlets and JSP is basically a "Slow Prototyping" environment and the long time it takes to just change a single line of code and then give that a try simply makes JSP a bad choice.

    PHP has been good to me for small projects, but recently a PHP based application blew up in my face when our client started a cooperation major web site. Basically, we got slashdotted and PHP showed that it did not scale well, despite having a really big machine.

    Friends have made me turn to Perl/FastCGI and we are currently moving the above-mentioned PHP-based site to this. Let's see if this serves our needs.

  • Actually after checking out the various links, I think you may have either intentionally misled or unintentionally misunderstood in regards to what an IDE is. Syntax highlighting does not an IDE make. What needs to exist (in ZD's mind) is something like Cold Fusion Studio or VC++ where you have some of the nifty auto complete and context tools. Personally I find syntax highlighting to be enough for me in vi.

    On a side note, if someone were so inclined (maybe me when i have time) we could use mozilla to create a PHP Studio similar to what people are working on for zope.
  • Good observation. I work with WebLogic and Tomcat on a regular basis and I think they should have at least given mention to commercial engines. I believe their intent was to showcase the most affordable option in each category, but they didn't explicitly say this. Also, benchmarking the free implementation (Tomcat) is a politically safe thing to do, but they might have been criticized for choosing to benchmark one commercial app server but not another.
  • I can't really say if PHP is easier to learn that CF, but I do know that I first used PHP 3.0 for a MySQL enabled calendar project a few months ago. I had almost no problem moving into it's coding style and syntax. It was incredibly easy to implement, and documention, help threads, and FAQ's are all over the web.

    Now, at work we occasionally have to work with CF. I find it's coding style and syntax clumsy: everything needs a stupid tag around stranglely named commands like CFIF, CFELSE, CFENDIF, etc. And I can't seem to find good help resources online.

    PHP's coding style let's you insert blocks of code into your html wherever you want, it doesn't require excessive tags, it's easy to modularize with include files (CF might allow this but I haven't found it yet), functions, and even object-oriented programming.

    So I guess I just haven't had the right experience with CF or maybe I would like it better. But for my money (and PHP don't cost none!), I'd go with PHP.
  • (regarding Cold Fusion:)
    It's easy and fast for NON-programmers to learn, develop, etc.
    Here's a true story: A (non-programming) friend of mine works for a company who decide to set up a scripted website. They're pretty much IT-stupid.

    They get their design ideas together and hold a meeting to decide on a platform. I've been selling my friend (their most IT-non-stupid member of staff) on a Free solution (php) and he puts this point of view at their meeting. The management decides that Cold Fusion is what they want.

    They buy Cold Fusion and hire a developer (spending about 2 grand) The developer screws up and doesn't deliver anything that looks like it's going to work. Panic, as they have demo and launch dates looming.

    After getting the go-ahead from management, my friend locates an off the shelf php app that does most of what they need. He's now modifying it to fill in the gaps, and both their launch and demo have been successful.

    Now I'm not drawing any conclusions about Cold Fusion - they were unlucky with their developer - but it's interesting to consider:

    • they didn't consider doing the development in cold fusion themselves. Producing any reasonably complex app requires the ability to think like a programmer. It therefore needs a programmer, no matter how wonderful the IDE.
    • It was possible to find a suitable php solution in such short order precisely because php is Free Software. Online help, ideas and solutions abound because of the prevailing ethos among php developers.
    • php is obviously not that intimidating to learn. My friend's previous experience with writing software consisted in copying character by character some programs published in computer magazines of the early eighties :-)
  • Seriously, don't use Java to code unless you're not worried about efficiency; Java lags like hell, even when fully compiled into classes.

    Also, consider one thing: the only scripting language that ASP didn't beat out was PHP. So before you go assuming that all of Microsoft is evil, think about the things that they did right: ASP's performance, as shown in this article; DirectSound and DirectDraw, which still beat the pants off of OSS and svgalib; and Win2000 Professional, proof that an NT workstation can be as versatile as 98 and still be ultra-stable.

  • by Morgaine ( 4316 ) on Tuesday October 31, 2000 @04:43AM (#663279)
    Why are the various scripting languages in such overwhelming favor?

    For two reasons, and they're both true:

    (i) A lot of web programmers simply don't have the background to use professional development standards, nor the attention span nor attention to detail required for successful non-trivial programming in C or C++. As a result, if they used these relatively low-level tools the result would be fairly horrendous. It's *much* easier to generate buggy code in inherently unsafe languages than in safe scripting ones. Pragmatically, it makes sense.

    (ii) The web moves at a break-neck pace, and there just isn't the time to produce a well engineered product using C/C++ before the requirements have changed yet again. Scripting languages allow you to make ad hoc changes without blowing your whole foot off every time. Errors tend to be comparatively minor, easy to diagnose, and the language usually stays in control rather than bombing out altogether.

    In a nutshell, scripting languages make a lot of sense in this application area. That said, they're definitely not the answer to everything.
  • There are certain things about Cold Fusion that make it a really, really excellent language to use. It's easy to crank out web sites stupid fast. The documentation is good, and the dev community strong. It's easy to write reusable code, and it plays nice with custom code. Administration and DB connectivity are no-brainers; Cold Fusion Studio is an absolute dream to work in.

    Some shortcomings include the fact that it isn't a top speed performer, but to be honest, the bulk of websites out there will run perfectly well given a reasonable server environment and intelligently-written code. That last note, however, points out CF's biggest weakness: it's all too easy to code in for idiots, so you'll often end up with idiotic code if your project isn't managed properly. Yes, any web developer can pick it up and run with it; this is a Good Thing (I seem to recall something about 'more eyes' being good...) So long as you have a competent tech reviewing and leading code development, you can get some pretty nifty results from Cold Fusion.

    Cold Fusion's greatest weakness is spawned directly from it's greatest strength: it's a damn easy language to learn and use. If you're good, you can do some slick stuff really, really quickly; if you're not so good, you can spawn a codebase that is impossible to maintain. Blame the meat, not the product.

  • Sun's J2EE is making inroads into the financial sector. I'm currently consulting for one of the world's largest banks, and they're making heavy use of JSP, Java Servlets and EJBs in a number of seperate ecommerce/ebusiness-related projects. Tomcat, Apache JServ and JRun are in use for projects using JSP and Servlets, whilst IBM's Websphere and BEA's Weblogic are in use for projects using Enterprise Java Beans.

    Using Java for this sort of stuff has a number of advantages, from what I've seen:

    1. Java is an open, non-proprietary language, so coders are easier to come by than when you're using platforms like Vignette or Cold Fusion.
    2. A lot of proprietary software packages deliberately make it easy to hook into them from a Java program (forgive me if I'm not using the right terms here - I'm not a programmer). You've also got JDBC to make it easy to hook into databases.
    3. If circumstances change, you can switch to a different engine/application server easily. So, for example, if BEA decide to double the licence cost of Weblogic, you can just switch to IBM's Websphere or iPlanet instead. That's not so easy to do if you're using a proprietary language.
    4. Portable. Develop on NT/Linux, deploy on Solaris/AIX/whatever.
    These guys are also playing around with Cocoon, although I've yet to see it actually deployed.

    You'd actually be surprised at how much open source stuff is in use here. I've come across Apache, Samba, rsync, Perl, ssh, as well as the aforementioned Tomcat.


  • While people keep saying how Perl is insufficient to the task, thousands upon thousands of programmers will quietly, surely, quickly, efficiently, and superbly get their job done using it.
  • Whilst ADO may provide a common interface to all the DB implementations the datasources do not all support the same features - you would struggle to use an Access datasource for any 'real' db application, it's just too limited.

    JDBC is almost identical to ADO in alot of its functionlity and the drivers supplied by various vendors seem more coherent than using ODBC connections through ADO. You often get many errors when using JDBC via ODBC and so far I have yet to see one which is a limitation of the Java side of things!

    All in all I'm sure that there must be a better way of handling database access than through either ADO or ODBC... if only someone would ocme up with it!

  • I thought the note that someone was trying to port ADO to PHP is interesting. ADO is very nice for database independence. It's always the same. Oracle, SQL Server, Access. I don't know PHP, but are you saying you have to code specifically for one database? Geez, that'd be a big pain in the ass.
  • by N8F8 ( 4562 ) on Tuesday October 31, 2000 @05:08AM (#663286)
    Here [] is a list of editors to use with PHP. Personally I prefer HTML-Kit []. HTML-Kit is free, extensible and supports new standards very quickly. The IDE is very similar to ColdFusion/HomeSite.

    From personal experience I would put ColdFusion and PHP tied for the top slot. CF is cleaner and easier for building small apps but PHP has MUCH better support and is better for medium size apps. Not to mention the easiest to learn. ASP sucks. Really there is no such thing as ASP since its really a hodgepodge of VBScript, JScript and HTML. With Microsoft's .NET it gets even worse with 16+ languages available. PHP is simple, has decent string handling and excellent online support. PHP+Apache+MySQL is a killer combo. Want an easy install? Check out PHPTriad [] for Windows. Chances are than any question you could come up with has been asked and answered in one os the the support groups [].

  • It's interesting to note that they didn't say which JVM they were using. The IBM JVM and Sun's 1.3 JVM are supposed to be worlds better than the Blackdown 1.2 JVM on Linux. Not to mention, there is quite a bit of tweaking that can be done with just JVM settings (e.g. set Min/Max heap equal to keep heap reallocations down).

    Also, I just have to note that nobody mentioned the testing methodology. Were they running the JVM for a long time? Or did they just fire it up for a few seconds? In the long case, the JVM will get into a steady state. In the initial case, most servers will be creating new objects and threads until they have adjusted to the load. A good rampup time is around 20 minutes.

  • I had the opportunity to read this article yesterday. I passed it around on a few mailing lists.

    Now in all of the languages with low pages per second I want to make a few comments.

    First just as an example since I do CF about half of the time where I work ColdFusion has features examples, caching queries, structures(NOT C like structures think associative arrays), XML transformations of data (WDDX), and several other features that can make things such as pages per second irrelevant.

    I am also of the opinon that they did very little tweaking of these servers because my own test results reflected much higher amounts in almost every language, putting CF, Php, JSP all on the same playing field.

    They used Tomcat beta 5 to determine that JSP could only do 13 pages per second.. what kinda valid test is that against polsihed products like php and CF??

    The point is that part of the test IMO is totally invalid.

    Now to move on to some finer points of the article that further reflect IMO the fact that the reviewers were biased.

    They reffered to php as an esoteric language and rated it as a C, an A being the best, in programmer productivity, this has PHB speak, and marketing written ALLLLLLL over it.

    So my basic conclusion is that this article is basically useless and it is nothing more than fun to read....

    I wont even touch the fact that each langauges have different feature sets that make them very well suited to certain orientations of development....

    Blah, Use your own brain and experience, once again ZDNet proves to me they have some clueless people.


  • Even that Cocoon is a greate idea, the shear amount of work required for transofrming XML into something else is huge. This is one of the main reasons it is so slow. It is very hard to make it perform, and performance is very important, especially for the large websites.
    Maybe the performance will be better once version 2 is out. But I doubt it. The solution is probably in processing XML/XSL on the client
  • Users must make a concerted effort to keep track of the independently changing components of PHP they are using
    I've just started doing development in PHP, and I've really noticed this as a problem. It's not the size of the API that's a problem -- it's the lack of organization. There's nothing like modules, there's no good naming convention, and there's so damn many functions.

    PHP is an evolved language, and it really shows. There wasn't a conscious and conservative philosophy behind it. That's both a plus and a minus -- but I think more minus than plus. Everything is there, and that's great -- but it's hard to find it, or when reading code to figure out where it came from.

    I can also understand why they didn't cover Perl or Python, because both of these aren't really web scripting languages, they are general purpose. Of course, there are HTML embedded versions of both of them but they don't seem to have caught on, which is too bad. And Zope/DTML/Python isn't really scripting either, but considerably more than that (though I'm under the impression that Cold Fusion attempts to be something similar).

  • No shit, Sherlock!

    But the original poster dude seems to think it funny that Microsoft made the changes. So funny in fact that he stopped reading in the middle of a sentence, and thus completely missed the point of the article...

    "Our design goals for writing test applications were to keep the algorithms as similar as possible on all platforms (for comparability) as well as to write code that was easy to understand and quick to develop. Fast performance was not a goal."

    "When performance does become important, various techniques are available that can make dramatic differences in speed."

    (My bold, again)

    What's funny is the hair-trigger, knee-jerk, tenuous-as-you-like anti-Microsoft brigade, like this guy and the moderators who thought he was meta-funny.

    On a more serious note though, it's important to realise that different products are often aimed at different niches, and a "one size fits all" benchmark is close to useless.
  • by Pac ( 9516 ) <> on Tuesday October 31, 2000 @04:49AM (#663310)
    This article is rather simplistic and poor, both in content and in conclusions. I will not discuss the fact that the "winner" is probably the only potential advertiser (PHP does not advertise, Microsoft and Sun won't advertise only for yet another article about ASP or JSP), but let us see what was left out, misinterpreted or plainly wrong:

    a) Python, Perl: How do you write a serious article about web scripting languages leaving these two out? Perl is the mother of all scripting language, Python is a rising star with lots of supporters and amj already huge codebase. And both perform as well as any of the examined technologies.

    b) Their priorities were "of speedy development, ease of use, and a complete and powerful API". In a real corporate environment, maintainability and portability would probably outshine all three, ruling CF and ASP out (my opinion, yuor mileage may vary) and leaving the stage for PHP, Python and JSP (more or less in this order, from worst to best).

    c) How on earth would COM support make ASP harder to write? In my experience, access to COM objects let you write smaller and sipler scripts.

    d) PHP is probably as easy as ASP to learn, it fells rather natural to any C/C++ programmer and it has probably the most powerful API for Web programming of the pack. The the author did not had the time or the will to learn the APIs ("Users must make a concerted effort to keep track of the indepen dently changing components of PHP they are using")

    e) Also, the lack of an standardized database API in PHP is botha curse and a blessing. First, there are some PHP libraries out there addressing this issue. Second, the trade here is speed for convenience. Third, all data acess function were made similar, so changing database is not harder than it should be. And finally, PHP supports ODBC.

    f) Tomcat is a reference implementation. There are faster alternatives out there.

    I will not go on. Forget this article.

    If you need speed, ease of use, a fair price (let us say, zero or less), good portability and good mantainability, use PHP, Python or JSP. Or even, if you are really sure your code will never have to leave a Windows box, ASP/COM.
  • by AndrewHowe ( 60826 ) on Tuesday October 31, 2000 @04:49AM (#663311)
    Yeah, but it's not as funny if you don't selectively quote. Here's the entire paragraph:-

    "For example, Microsoft Corp. has rewritten the Nile benchmark we used in these tests in several ways to demonstrate optimization techniques. The company ended up with an application with quite different application logic and database design from ours (but that generates the same pages we do) that runs about twice as fast as the speed of our version on similar hardware."

    There you go, and I added some bold of my own. How do you like that?
  • I think one of the big reasons is that most popular scripting languages have considerably better string handling support than traditional compiled languages. And since string processing is pretty much what most web scripts do most of the time, that's a good thing. Think strings in C/C++ and you get the point. While there are certainly many advanced string classes available, C/C++ still puts certain semantic constraints on their use. Scripts usually have few or none of these constraints.

    As an aside, I think Delphi is one of the most suitable traditional compiled languages for web development. That's because of the decent string support, the clean and readable syntax, the good speed, and excellent database connectivity.

    The other main advantage that scripts offer is cross-platform portability. A set of PHP pages should port pretty well from Linux to Win32 depending on what they do. The same can't be said for binary DLLs or even their source code.
  • by onion2k ( 203094 ) on Tuesday October 31, 2000 @04:51AM (#663315) Homepage
    ASP isn't a language. Its a container for other languages. Its used with VBscript, JavaScript and PerlScript, alongside HTML (And others..). There are no commands in ASP.

    As far as I remember ASP was designed to be a sort of glue that holds together a bunch of custom COM objects and DLLs. It was designed to be an operating environment.

    In my experience building dynamic web sites (not much.. few years) ASP and PerlScript, with a drop of VB in times of boredom, have always been a good, flexible team. Depends what you're doing..
  • Making a good dynamic site is more complicated than sticking some php/java/vbs/whatever code in the middle of an html file. First, you really don't want to put your programming logic and your html in the same file, for two reasons: 1) programmers and designers should not interfere w/ each other's work, and 2) program code stuck in the middle of text is not maintainable; for large applications you really want to create libraries of functions and do things in a structured way. Second, you probably want to treat your whole website as an OO application, to handle a hiearchy of common pieces (ex. navigation) as well as looks or themes.

    There are *many* technologies out there to do these things right. Apache with mod_perl and either AxKit or the Templating Toolkit (or others) can do it. I hear PHP can do it using the right libraries. Java servlets, for all their verbosity, can do it using something like's Tea system.

    I have never used ColdFusion or ASP myself, but I know many people who have, and I've repeatedly heard that they're great for quickly building something, but very bad for managing complexity.

  • by tzanger ( 1575 ) on Tuesday October 31, 2000 @05:21AM (#663321) Homepage

    Perl can't be taken seriously as a high-end web site development language.

    Howso? Oh wait, I think I hear something:

    For large complex sites (slashdot really isn't either - it's a very straightforward single application), perl just doesn't have the performance one needs, and it is very difficult to maintain.

    Where's the proof? Mod_Perl takes up a whack of memory, sure, but the speed is right in line with the rest of them. What large, complex site doesn't have a cluster of machines with a shitload of memory on each? And as far as your maintainability arguement goes... I can show you code in just about any language which is a nightmare to maintain. Hell I could show you spaghetti code in C++ which I personally thought was impossible until I started cleaning up one particular in-house project.

    Perl may seem to facilitate nasty coding practises but in reality it all comes down to the programmers. Are they going for geek machismo or are they working toward something which is maintainable? Perl has a wonderfully clean OO syntax; I prefer it to C++. The built-in regexps are great for formatting stuff after the database has had its try.

    Perl ain't perfect, but it is certainly up to the task, IMO.

  • I looked through the ASP source used for this article and it is absolute spagetti. I hope this page does not represent most of the ASP out there on the web. No wonder these guys only got 49 req/sec. As an experienced ASP programmer I can confidently say that I could get better performance than these guys with only half the hardware and the same functionality. I am thoroughly disgusted. I am not familiar with any of the other scripting languages that were evaluated, therefore I cannot comment on the source used. If the source looks anything like this ASP, I would take these performance results with a grain of salt.
  • My bias against CF may be even outdated, since the last time I saw it being used was two years ago. But, and I commnet from a software development professional perspective:
    a) It still seems to suffer from performance problems.
    b) It is not portable.
    c) CF experience is not transferable from a field of application to another. With Java, PHP and ASP, I can easily use/hire developers without web/internet experience and have them learn something that will complement their knowledge (in Java, C/C++, VB, respectively). And the contrary is also true, I can easily take the web developers and grow them into full-fledged programmers. It does not seem to aply to CF.

    As for your first point, I never said Perl is easy to learn. I was only pointing that leaving Perl out is unfair and incorrect. Perl codebase running real life sites probably outnumber CF,PHP and JSP codebases taken together. And what you say of CF is probably true for Python or ASP too.

  • by Anonymous Coward on Tuesday October 31, 2000 @04:04AM (#663334)
    "PHP is relativeliy new and it's not mature enough for corporate use."

    Is this a joke ?

    PHP has been here since 1994. It's older than the other languages in the chart.

    Also, they state that PHP has no uniform database API: This is false:
    You can use ODBC for all kinds of database. However, you have the alternative of using the direct APIs to improove performance.

  • by TurkishGeek ( 61318 ) on Tuesday October 31, 2000 @07:44AM (#663337)

    Meanwhile you will have ended up with two different languages to support in the same production environment. This may not be a problem for a small design shop where you have a couple developers that know both languages and the code that everybody works on; but in a big company environment, it makes life very difficult.

    Despite being a useful "hack language" to create small, simple contraptions; PHP is not exactly the most readable/maintainable language on Earth. Add to that the thousands of Web designers who believe they became programmers by just writing some simple logic in PHP, and you have a lot of poorly written code in a poorly documented (yes, I know about the online manual. Go see for yourself how poorly Oracle functions in PHP are documented, for example.) language. Just like Perl, the flexibility and power comes at the expense of readability and maintainability.

    I fail to understand why anybody would want to use PHP with JavaBeans if they know enough about Java to figure thise setup in the first place. I don't think there is anything in particular that you can do with PHP but not with JSP. I don't think the JSP functionality can extend any more, since anything that can be done on the server side in Java can be done in a JSP page.
  • PHP.. PHP is in the same boat, but you can develop middle-sized applications before grinding your teeth. The language itself feels likc one giant hack
    Is it just me, or can you really not do ($object1->method1())->method2() in PHP? Or $object['index']->method() . Like, really simple chaining of expressions.

    Maybe it's just me (correct me, I'll thank you!) But I seriously fear that PHP doesn't follow the basic principles of parser construction, and that the object system was a total hack -- not even a messy language extension (which would be bad enough), but just a straight out hack.

  • I'm afraid you misunderstand what .NET is all about. First of all, what you are refering to is actually the ASP+ component of .NET
    It bring several advantages over the current ASP model (and some much-needed changes IMHO):

    Code is stored separately from HTML

    On first run, code is compiled into native x86 binaries which are cached until you edit the source again

    There are no more "script" languages -- you can use full VB, C++, C#, perl, COBOL, or any other supported language. (I fail to see why more choice is somehow a problem)

    You can mix languages in the same project if you wish -- your web classes can be written in high-performance C++, but glued together via Visual Basic for maintainability. You can even inherit and override the C++ classes in VB

    Security model -- all ASP+ pages run under a security context. If the user under which your site is running doesn't have access to write to %systemroot%, then any attempt to write to that directory will yield access denied.

    All of the functionality is based upon the Common Language Runtime. Since all the languages are full-blown, you can do just about anything you wish (provided your service is running under a user context that supports what you are trying to do.) Also, a *nix port of the .NET runtime is planned.


  • PHP.. PHP is in the same boat, but you can develop middle-sized applications before grinding your teeth. The language itself feels likc one giant hack and there is WAY to much built-in, no module support to speak of, and the "unified" DB driver sucks (ODBC has a performance hit). It's shoddy OOP and function support causes headaches.

    True, the ODBC layer has a performance hit, but there are abstraction layers out there that give you a consistent API, phpLib for one. I don't use phpLib, I've got my own class library that I wrote. I can use mysql, msql, mssql, sybase, oci8 or pgsql by changing one variable in the little file I require() that's got db connection/auth data in it.

    Also, pay attention to the PEAR project that's a part of PHP 4.x. They're working on a unified DB class.

  • by Pac ( 9516 )
    Perl is the mother of all scripting language, Python is a rising star with lots of supporters and amj already huge codebase

    scripting languages
    an already huge codebase

    access to COM objects let you write smaller and sipler scripts.

    simpler scripts

    The the author did not had the time or the will to learn the APIs ("Users must make a concerted effort to keep track of the indepen dently changing components of PHP they are using")

    That the author did not had the time or the will to learn the APIs ("Users must make a concerted effort to keep track of the independently changing components of PHP they are using") does not change this.

    Preview is your friend... :)

  • by latneM ( 7876 ) on Tuesday October 31, 2000 @05:04AM (#663353)
    Check out this link [] and here as well [] to see just how much they vary. Granted, the benchmarks are from a vendor and are likely going to be tweaked to make their product (Resin [] looks good), but you can see an order of magnitude difference between Tomcat and some of the others.

    I will chime in with my own little opinion that it is far cheaper to buy the hardware to get the performance you need from any technology you choose (within reason) than it is to train a staff to a new technology.

    And the best example of tuning a Java web app I've heard was a bank's app running on a 16-way Ultra-Sparc. Not pleased with performance they considered moving to an E10K. Then someone pointed out that they were using green threads. For the non-Java guys, green threads (as opposed to native threads) are managed by the VM and cannot use multiple CPUs. Their app was pegging one CPU and leaving the rest idle. Moving to native threads gave them an instant speed, um, boost would be an understatement.

  • by Phill Hugo ( 22705 ) on Tuesday October 31, 2000 @05:37AM (#663354) Homepage
    Try Zope.

    ZSQL Methods are completely independant of your actual database and you can change your external database with a couple of clicks (if you need an external one in the first place. Zope has a long running persistant object system of its own which keeps instances of things alive along with their data until you specifcally delete them - even between reboots!

    The underlying Python DB access is specific to whatever database you use but in Zope Land it is wrappered around Zope DB drivers which the ZSQL Methods talk to. Similar to what the DB.php stuff in PHP4 does but with a more compelling reason to use it.

    They also encourage code resuse as you can template your queries just like your HTML..

    SELECT * FROM users
    <dtml-if username>
    WHERE user=<dtml-var username>

    Then when you call them, their magic happens and out pops the results in a python list.

    Made me wonder if they included Zope in this round up if Zope would have A or D for tools, its web interface being its own tool really.

  • by under_score ( 65824 ) <{mishkin} {at} {}> on Tuesday October 31, 2000 @04:05AM (#663357) Homepage
    I used to do a bit of WebObjects [] development back in the OpenStep days. WebObjects had three great things going for it: great tools, fantastic database connectivity middleware, and really solid web scripting and tag extentions. Recently, I have been doing Java 2 Enterprise Edition development. At my day job, I am working in a high availability application server environment, and in my night job, I am prototyping a educational web system. In that second role I am using JSP's. (Dislaimer: I love Java compared to C++ but hate it compared to Objective-C.) As the article points out, the tool support is missing, and I personally find JDBC to be a pretty weak database interface, but the actual JSP technology is really cool! I've been working on custom tag extentions and they really rock - solving the problem of separating display code (html) from business logic and model code (accomplished with the use of JavaBeans and EJB's). Personally, I think that the Java platform is the way to go in the long run. JSP's are a really good step to completing the platform and the Tomcat reference implementation is a great tool for prototyping.
  • It's not quite as good as the template functionality, but what i do is create for every page, two files. foo.php and foo.ihtml. here's an ultra simple example

    $username = "Bob";


    Hi ! How are you today?


    as noted, it's not as nice as the phplib templating, but it's better than nothing.

    "Don't trolls get tired?"
  • by Mr Neutron ( 93455 ) on Tuesday October 31, 2000 @04:08AM (#663365)
    IMHO, one of the most exciting things to come out of the Apache XML project (or Apache in general) is Cocoon []. Cocoon includes the eXtensible Server Pages (XSP) Processor [] which allows complete separation of content and presentation. XSP is what JSP wants to be when it grows up. It provides tags for the inclusion of Java logic into dynamic XML documents - other languages will be supported in the future. This, combined with the XSLT engine (Xalan []) provides a very powerful content generation and formatting framework.

    Anyone who has to design, implement and support large, web-based applications should check out Cocoon.


  • JSP is not a good scripting engine for Java in my opinion. It forces you to put all your code and your HTML together in one place. A real mess. I have the same problem with ASP and PHP.

    Check out WebMacro: []

    WebMacro is a Java servlet template engine which allows you to separate this stuff. You write pure Java code in the back end, and straight up HTML with some formatting codes in the front.

    It makes everything really clean.
  • You pointed up a good difference between open source products and proprietary ones: cost vs value. I haven't used Cold Fusion myself, but I have used Lasso extensively and that's one of the main proprietary competitors for ColdFusion. One of the big problems I've had with Lasso is getting help when I'm stuck. For a product that costs at least $1100--for a fairly stripped down package--, I want to have some kind of support at least for the first 90 days. About all you seem to get from the vendor these days is a mailing list and searchable archives. Big deal. You get that with PHP, and its free. So, my question given that Lasso, ColdFusion, and PHP do the same things, is what is the business case for using one of these closed source products? And in terms of a DB API, you're right everyone is using either ODBC or JDBC these days and PHP supports ODBC, so again, what do products like ColdFusion and Lasso give you that open source systems like PHP don't? Is it a warm fuzzy feeling that some corporation is "supporting" the thing? BTW, I'd like to point out that I'm not singling Blue World(Lasso) out by any means, its just that I've noticed a trend for diminshing support and candor among vendors in general thats been going on for a decade. This is one reason why open source appeals to me so much.

  • by mosch ( 204 ) on Tuesday October 31, 2000 @05:46AM (#663375) Homepage

    Have you written any large projects in PHP? I mean really large, mission-critical projects. If so you'll quickly see that while it has strong points, it's far from perfect.

    The database connectivity is far from perfect, and ODBC isn't the magic bullet some people like to think it is. While you can use ODBC to connect to an Oracle database, it will offer significantly lower performance than using the ora_ functions.

    If you want an example of the lack of uniformity in the database API, look at odbc_fetch_row, it takes a statement handle, and optionally a row number. If the row number is omitted, it returns the next row. Now look at pg_fetch_row, it takes a statement handle, and a mandatory row number. If you omit the row number, it just plain doesn't work.

    Look at the functionality of something as simple as 'break'. One would assume that break would exit any looping construct, whether it be for, foreach, or while. Well, you'd be right that it exits for or while, but it doesn't exit a foreach.

    And there are other inconsistencies too, which are obnoxious, for example 'is_array, is_long, is_dir, and is_double' all do what you'd expect. but it's not 'is_set', it's 'isset'. If you take a reference to $this in the constructor for an object, it's not the same reference that the new class returns. (Bug 7454 [])

    And they're right, debugging support for PHP is horrible. The debuggers that are out there only work on certain versions, so if you're doing development against the CVS version of PHP in order to get the latest bug fixes, they won't work, because of changes to the Zend internals. error_log is the equivalent of debugging with printf, and if you add your own error handler, there's a bug which prevents it from showing the error message. (Bug 7283 []).

    PHP has been here since 1994, but it's been massively rewritten at least twice. Once in PHP3, and again for PHP4. It has a lot of potential, enough that I'm using it on large, important projects. But I wouldn't dream of using it on a large, important project that had to be done in 2 weeks. The language still needs time to stabalize.

    "Don't trolls get tired?"
  • I won't make any comparisons to PHP or ColdFusion, I haven't used them.

    But in terms of performance, my company moved from ASP to JSP for performance among other reasons. My company creates Intranet solutions, Web-based training, dynamic-content Web sites, etc.

    ASP has a few major glaring issues.

    1. Performance: When scripts are asked to perform complex operations, such as dynamically creating one of our site administration screens that have more tables, frames, than a big horse can ----, ASP crawls. As our systems got more complex, we moved them to VB COM components, and later to VJ++ COM components for speed. When we started switching to the full Java technologies, the testers reported a big increase in speed and usability, even though the applications were getting more complex. Before we "officially" switched from ASP to JSP, I ran a few very practical tests on both, to see how fast they might run in our applications. JSP flattened ASP, normally by a factor of 10, sometimes by 100. (I did this test 18 months ago, with Apache JServ)

    2. Less bugs in my code. ASP is a breeding ground for bugs. Because its interpreted, SYNTAX ERRORS can exist in your code and you won't know about them til some client calls up having used some obscure branch of an If statement that missed testing.

    3. Less bugs in their code. Ever heard of a "Catastrophic Error?" If you haven't you haven't used ASP for long enough. If you use this technology for a long time AND REALLY PUSH IT HARD, it will snap on its own. This is my biggest problem with ASP. I've had cases where my code was correct and when executed would nearly bring down the server. The solution was sometimes as simple as switching the order of two non-initialized variable declarations.... this leads me to believe there are great flaws within the ASP engine. Because no one can probably believe this point, let me just give you an example....the following program might work:

    Dim A = 5
    Dim B = 6

    Foo A, B

    While this one might bring the server down:

    Dim B = 6
    Dim A = 5

    Foo A, B

    I've seen this happen! I haven't the slightest clue as to what caused it, but it often happens on very large scripts (running the above code isn't going to demonstrate the problem).
  • Pros: Flexible if somewhat haphazard language; growing pool of support.

    Cons: Relatively new; few tools; lacks unified database API.

    Bottom Line: Not mature enough yet for widespread corporate use, but holds promise.
    I have starting moving my web development projects (at least the largest one I am working on) to a PHP/JavaBeans solution. I no longer have to mess with any of the database API's in PHP, as my JavaBeans do all the dirty work. Currently, JSP seams to be very immature, based on the research I have done.

    Using a PHP/JavaBean model, I try to keep the API (HTML) layer as thin as possible. In addition to being able to add other interfaces easier (XML, Java Applet, etc.), I can easily migrate to a JSP front end if the JSP functionality catches up and/or passes PHP. There are currently some things my site currently does in PHP, which JSP does not support, and would take way to long (and more java skills than I have) to program into a bean.

    This should prove to be an interesting discussion to read through.

  • by mosch ( 204 )
    phplib was an excellent library for use with PHP3, however the best parts of it (namely session support) have been included in PHP4 standard, so there isn't much need to look at it anymore, except for legacy use, or if PHP4 is still too young for your purposes.

    "Don't trolls get tired?"
  • Because raw performance matters less due to network latency or connecting to other servers (your RDBMS or other backend). Given that setting up a TCP connection and downloading the HTML and images take a certain amount of time, any savings from writing in a compiled language are neglible. For example, say the user's computer can download a page in five seconds. Say my Python program takes 0.5 sec, while your C program takes 0.005 seconds (100x faster); who cares about 0.5 vs. .005 sec for the actual processing?

    Also, I think people often envision themselves running Amazon-scale services with thousands of hits per second and therefore need CPU usage pared down to the bone, but practically I think many Web sites are low-volume. The one I work on for my day job probably can expect 5000 or 10000 registered users, tops, and so the CPU is never heavily loaded at all, so there's no reason to give up the ease of programming and debugging for unneeded speed improvements.

  • For Perl users out there, don't forget about AxKit - an implementation of some of the same technology as Cocoon, but in a mod_perl framework (with a few differences too). Of course we support some different technology, and have a few different tacks on the same ideas, but the idea of using W3C recommendations to implement a server framework is the same.

    For the person in this thread saying that Cocoon is slow, you might be interested to know that Covalent had to drop Cocoon and replace it with AxKit for the Apache mailing list archives at - I don't have specific details of why Cocoon couldn't hold up (it continually crashed when the hits went higher than 3 hits/sec), only that AxKit does hold up to the strain (Of course, I'm biased)
  • They seem to have forgotten Mason: []

    All the goodness of Perl, embedded in your HTML.

    But of course, they'll never get advertising dollars from this...

  • by Adam Wiggins ( 349 ) on Tuesday October 31, 2000 @02:24PM (#663393) Homepage
    Anyone have any recommendations for a good JSP server? I've used Apache JServ for a while and it's horribly unstable, frequently locking up and requiring a kill -9. Tomcat seems nice, but I was unable to get it working over SSL even after many hours of tweaking config files. I've been planning on looking into Enhydra, which I've heard good things about.

    Any others I should be considering?
  • Microsoft's next "evolution" of ASP is really cool and will blow ASP (and JSP/PHP/CF) out of the water, IMHO. Of course I may be a bit biased... but... uh... well, just read up on ASP+, it is pretty cool. :-)

"Our vision is to speed up time, eventually eliminating it." -- Alex Schure