4 Web Scripting Languages Compared
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.
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#
I could not justify my existence if I were a turkey farmer. Would I terminate myself? Undoubtably, yes.
Fortunately VB7 will support try/catch/finally blocks.
I could not justify my existence if I were a turkey farmer. Would I terminate myself? Undoubtably, yes.
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.
Zigbee Central: A Zigbee weblog
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!!!
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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.
Source code is a lot like a parachute; it needs to be open in order to function properly.
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...
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.
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
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)
--------------------
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.
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!
Only 'flamers' flame!
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).
-POIU
---
---
"Don't anthropomorphize computers. They hate that."
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.
--
Proud member of the Weirdo-American community.
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
/ The Arrow
"How lovely you are. So lovely in my straightjacket..." - Nny
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.
When someone yells "Stop" or goes limp, or taps out, the fight is over.
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.
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 =)
Any technology distinguishable from magic, is insufficiently advanced.
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.
Neutron
I get my kicks above the
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!
Helping with organizational effectiveness is our job.
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 (dot.com, 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....
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.
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.
"It is our blasphemy which has made us great, and will sustain us, and which the gods secretly admire in us." - Zelazny
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...
---
DO NOT DISTURB THE SE
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!
Only 'flamers' flame!
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).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 = goodThey 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.
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.
"Fighting the underpants gnomes since 1998!" "Bruce Schneier knows the state of schroedinger's cat"
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.
-- Solaris Central - http://w
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.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
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.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
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.
Obliteracy: Words with explosions
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!
Better the pride that resides in a Citizen of the world, than the pride that divides when a colourful rag is unfurled
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.
---
DO NOT DISTURB THE SE
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.
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
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.
Jeremy
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
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).
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.
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.
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..
http://twitter.com/onion2k
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 go.com'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.
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.
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.
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.Zigbee Central: A Zigbee weblog
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...
Try Zope. www.zope.org
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>
</dtml-if>
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.
Phill
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.
Helping with organizational effectiveness is our job.
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
----foo.php
$username = "Bob";
----foo.ihtml
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?"
Anyone who has to design, implement and support large, web-based applications should check out Cocoon.
Neutron
I get my kicks above the
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.org
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.
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.
-Pete
Soccer Goal Plans
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?"
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 http://archive.covalent.net/ - 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)
Matt. Want XML + Apache + Stylesheets? Get AxKit.
http://www.masonhq.com
All the goodness of Perl, embedded in your HTML.
<cynic>
But of course, they'll never get advertising dollars from this...
</cynic>
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. :-)
I could not justify my existence if I were a turkey farmer. Would I terminate myself? Undoubtably, yes.