The Web continues to evolve, and with it the purpose and power of Web scripting languages. I’ve blogged about scripting languages – many times, RE: many issues – in the past; with the rise of .Net and the imminent release of PHP 5.0, perhaps it’s time to take another look at these languages.

Outside of the compiled vs. interpreted language differentiation, I don’t know what the best definition of Web scripting languages is. For example, I consider Perl a Web scripting language (one of it’s many uses), yet Perl is compiled – at run time.

Oh well. Consider this a look at the following Web scripting languages:

• ASP
• ColdFusion
• JSP
• Perl
• PHP

There are other contenders – such as Lasso, a horrible, horrible language – but I will stick those in the preceding list. And I leave out the templating systems, except as they may pertain to a specific language (such as smarty on PHP).

All opinions expressed (except as linked, obviously) are my opinions; all errors are mine, as well.

ASP

First of all, let me begin by saying that I haven’t done any professional ASP coding – stuff I’ve been paid for – and I don’t have any experience with ASP.Net or whatever the fuck it’s called. So ignore the following if you’re already rolling your eyes.

That said, when I taught myself ASP, I didn’t build a HELLO WORLD page – I built a password-protected, session-enabled CMS that had a visitor section and admin section (add, edit, soft-deleted users and articles etc). So I don’t have a lot of experience, but I know a bit about scripting languages.

When I first began work with ASP, I was surprised that it was so well thought out. When I needed a function – based upon my work in other languages or it just seemed like it should be there, it was.

On the other hand, VBScript just totally blows. I just don’t like it. I do have VB experience (again, minimal), but … so what? I would have vastly preferred to use JavaScript as the logic for the ASP pages (ASP allows this), as JS is such a strong language. However, this doesn’t make a lot of sense – the whole “When in Rome, do as the Romans do…” point of view. The default is VBScript, most (all?) ASP coders are familiar with VBScript and probably not as familiar with JS, and I think there is a setting you may have to make on IIS to use JavaScript (could be just a default change; I can’t recall).

There is a lot going for ASP, however, and – as mentioned – I don’t know the whole ASP.Net framework, and I’ll bet that’s even better than the base ASP language. Also – very importantly – if you’re a dedicated MS house, ASP is probably the best bet: ASP is more tightly integrated into the MS framework than any other scripting language (leaving aside the debate if that’s a good thing or not, OK?).

Bottom Line Pros:

• Tight integration with MS systems
• Supported natively on MS’s IIS (no extra costs)
• Excellent session control
• Vast library of functions and other tools
• Can call COM and COM++ objects

Bottom Line Cons:

• Running on non-MS products (i.e. *NIX) requires third-party products (ChiliSoft, etc)
• Native on IIS – the overwhelming choice of deployment – and IIS is a relatively porous server
• Logic language – VBScript – is weak
• User-defined function ability appears limited to COM objects

ColdFusion

This is probably the language that I’m most familiar with – I’ve just worked at more jobs where this was the language of choice. Not necessarily an endorsement; not necessarily a ding. Reality. So be it.

ColdFusion – originally a product of Allaire, purchased around 2001-2 by Macromedia – is probably the poster child for simplified dynamic Web development. While other languages may scale better or support more C-type functions better, ColdFusion is the easiest language to hook up to a database and template out a dynamic site.

ColdFusion has excellent – almost transparent – database interaction features. It also makes handling sessions – another huge Web-language issue – relatively trivial. Combined with a tag-based format that reads as English, this makes ColdFusion an ideal language to allow newbies to begin experimenting with database-driven sites.

Not surprisingly, the strengths of ColdFusion also work to its detriment: Simplification reduces the ability to do the complex (at least as proportionately easily). One example of this is the most basic: Because CF is so easy to code, there are a lot of individuals out there who are (shiver!) running CF sites who really don’t have programming chops. CF allows this – double-edged sword and all that. It’s hard to find a Java programmer who doesn’t know some basic best practices (uh, say separation of logic and presentation as much as possible). Most CF coders don’t understand this basic concept.

Bottom Line Pros:

• Easy to use; easy to understand
• The fastest way – such as for demos, proof of concepts – to get a dynamic Web site up and running
• Tag-based language makes sense for HTML coders; database access is reduced to simple SQL and asking what is in result row X for column Y. Very transparent for the uninitiated
• Runs – as third-party app – on almost every platform/configuration

Bottom Line Cons:

• Simplification at the expense – at times – of the ability to do the complex
• Requires third-party product (i.e. ColdFusion) to be installed
• The latest release (no longer numbers ) – ColdFusion MX – is now rewritten on a Java core, which is good and bad: Good, as it allows Java programmers to get access to way more info/extend further; bad, because the regular CF programmer is not Java ready
• There have been changes that create havoc – for example, v5 introduced the CFGRAPH tag. As of version 6 (MX), the tag is deprecated and is now CFCONTENT, I believe. Deprecated after one release. Doesn’t inspire confidence – will the code I write today work tomorrow??

JSP (Java Server Pages)

As with ASP, I have limited experience with JSP – mainly to teach myself how they work and all that.

There really isn’t a whole lot to say about JSP except the following, which will double as the Pros and Cons of the scripting language:

• JSP seemed to first appear as a defense against ASP; this defense – leveraging Java in a scripting language, while clunky, worked well
• JSP suffers from the same problems as Java: Compiled (JSPs are compiled upon first hit [slow]; zippy afterwards); complexity (for scripting developers, OO is hard); requires the whole Java infrastructure to be in place – coding and server – to be used. Often daunting. Sun has fucked up really badly on this, in my (inane) opinion
• JSP benefits from the same strengths as Java: Many functions, robust OO infrastructure, large support network. And where ever Java goes, so will JSP. So it’s not a static language.
• Often a third-party product (sometimes free; sometimes not) to run JSPs on a given server: Tomcat, JBoss, any of a handful of servlet handlers and so on.

Note: Russell Beattie has an interesting blog entry about JSP. Kind of a State of JSP entry: The good, the bad, and the fugly…

Perl

Before it was simple – or practical – to create a database-driven site, there was Perl. Perl CGIs, along with Unix include files (remember .shtml?), were the dynamic Web.

Today, Perl-driven sites are dwindling; many that are left (such as Slashdot) are holdovers from when Perl was the only way to do things. If these holdovers were launched today, they’d be in one of the other four languages described here, in all likelihood.

Perl, for all it’s strengths, was not designed as a Web scripting language. It was just a simple leap to make it such: Perl excels at text handling/transformation. HTML is a ASCII-text language. 1 + 1 = A dynamic solution. However, the lack of a Web-centric foundation makes Perl somewhat awkward to work with for Web development, especially for code monkeys (as opposed to trained developers).

For example, most scripting languages come built with constructs to handle the basic HTML GET and POST parameters (and so on). Until the Perl CGI module(s) came along, handling these variables page to page (such as a registration form) required a developer to create a custom subroutine to parse and make these variables available. Doable, but not clean or consistent (the biggest drawback).

And while Perl does have database connection tools (through the Perl DBI), Perl’s forte – as mentioned above – is text handling, and is often used in conjunction with flat files (delimited TXT files) as a non-relational database. Perl rocks for such work.

Bottom Line Pros:

• Ubiquitous. No matter what server you’re on (*NIX or Windows), Perl will be installed. So a user wanting a quick dynamic app – say a guest book – on their site can use/commission Perl and be confident that it’ll work, even if they move to another platform in the future.
• There are tons of fully functional Perl scripts floating around that one can use/modify to get a site app up and running in a hurry
• Probably the strongest language for handling any sort of text transformations (Python is supposed to be strong this way, as well. I’m just not familiar with it)
• Very fast language
• Incredibly powerful search and replace functions (RegEx etc)
• Free – open source. And there is a strong open-source community behind Perl, creating new modules and so on
• No matter the scripting language a developer knows, there is a better chance that this developer knows some Perl than any other second scripting language. It’s that ubiquitous

Bottom Line Cons:

• Not designed as a Web scripting language, and it shows. This is a serious liability
• While Perl is not too hard to pick up, it’s hard to master: A well written Perl script can look like a bunch of punctuation thrown up on a page.
• RE: Preceding point – As a very non-English language, it can be hard to maintain, especially non-commented code
• Hard language to really master well enough to do a whole site (well) in the language. This is not true of, say, ASP or PHP

PHP

PHP is currently my favorite language. It combines the Web-centric designs of ColdFusion and ASP with the robust text-handling ability of Perl to make a language that is not without its flaws, but one that is ideal for Web development.

PHP was designed from the get-go as a Web scripting language: PHP originally stood for Personal Home Page (today, PHP = PHP: Hypertext Preprocessor…yeah, just rolls off the tongue…).

As mentioned, it combines the best of many languages, including Java, into its framework. With the C-like syntax and expected higher-level functions (example: all the math functions), PHP can – out of the box – handle almost any Web task needed.

And with a little extra effort/expertise, PHP can be tweaked with non-standard options (such as ClibPDF) to handle virtually anything you can throw at it.

I thought that PHP would die out – be drowned out, if you will – in the tidal wave of (somewhat) proprietary scripting languages (ASP on Windows side, JSP on *NIX side). I was quite wrong. PHP seems to have grown in importance and visibility. It’s interesting.

One major downside of PHP is the way the language keeps changing: Moving forward is OK, but it seems like everytime I look up a function (at the great online resource php.net), there is a note limiting it’s use: (PHP 4 >= 4.1.0).

The leap from v3.x to v4.x was huge and to leave v3 users behind was a good more. But the mess is that there are a lot of v4 functions and so on that don’t work unless you have version 4.x.y, which is somewhat problematic. At it frightens me to see what the new version – 5 – will bring (currently a release candidate; so almost there).

Bottom Line Pros:

• It’s designed and built out as a scripting language. While some are extending its use as a shell-scripting language, it’s a Web scripting language first. This is a enormous plus
• Steals – uh, leverages – the best of other languages (C, Java, Perl) so the syntax/structures are familiar to coders and just about every function/structure needed is available
• Rapid coding is possible. Java/JSP may be more robust(?), but PHP is much faster to get up and running. Only ColdFusion is faster in this respect
• Fast language, scales well, runs on *NIX and Windows
• Open source; lots of contributions; the language continues to advance

Bottom Line Cons:

• The updates don’t seem too well thought out – lots of updates/additions that require newest/newer version of PHP
• Trying too hard to be all things. For example, the function disk_free_space() is the same is the function diskfreespace() (the latter is an alias). Will one be deprecated in future releases? Which one? Did I pick the wrong horse (alias)? Also a maintenance issue.
• It is an open-source product, so there is no company behind it guaranteeing its future (such as MS behind ASP)
• Reminiscent of Perl in many ways, but without the bare-bones structure of Perl (which is also a good thing, as Perl can be so damn punctuation heavy)
• Pet peeve: The array variable – same as regular variable. In Perl, an array called foo is identified as @foo; in PHP, it’s $foo (same as non-array variable). Yes, there are functions to show the difference, but – from a readability/maintenance standpoint, the Perl notation is preferable, to me.

Conclusions

The first thing to take from this (very rough) comparison is a given that I approached this exercise with: Languages are not right or wrong, they are just potentially convenient.

The best car? For what? Road rally or taking 12 kids to soccer practice?

Ditto for languages.

That said, some rules of thumb for choosing/using a scripting language: