CGI/Perl vs. ASP

[nysus]

Ok, I'm probably throwing bloody meat to a pack of pirannahs, but I'm interested to hear thoughts on this debate...I'm a newbie. Please do your best to remain unbiased. :)

[dws]

A few thoughts...

In Process vs. Out of Process

ASP runs "in process" in the web server. It's dynamically bound in (by DLLs). ASP scripts, wether they are Visual Basic, JScript, or PerlScript, don't run as separate processes. Startup can be fairly fast, and session state can be maintained across invocations.

CGIs, whether they be in Perl or in some other language, run in separate processes. They incur a per-invocation startup cost, and use the file system to cache session information between invocations.

(Both ASP and CGI can "cache" session information in URLs and in hidden form fields.)

If you're running Apache and control the web server, mod_perl is also an option. This allows Perl scripts to run in process, and is considerably more flexible than PerlScript on IIS.

Language Choice

Which of Visual Basic, JScript, or Perl is more flexible? All provide ready access to OLE components, though if this is how you're going to develop, the documentation is better for VB and JScript.

If you're going to be doing any type of sophisticated parsing or string manipulation Perl is an obvious choice.

If you're going to be doing any sophisticated page generation, consider also the facilities each language makes available, either directly or through readily available components. On the VB side there's... uh... On the Perl side there's CGI.pm and the Template Toolkit.

And consider which language had the best choice of off-the-shelf componentry for reuse. The standard Perl distribution has a lot of useful stuff, and more is available from CPAN or PPM. Reusable stuff is available for VB, but not in the form of reusable objects (unless you consider instances of OLE things to be Objects).

Development Considerations

Which are easier to develop, ASP scripts or CGI scripts? Since CGI scripts are stand-alone, they can be developed and debugged in isolation from the web server, with minimal scaffolding. ASP scripts are rather more difficult to develop and debug. Visual Interdev helps somewhat, but judging from the howls of pain from my comrades several cubicles over, I'll stick with CGI as long as possible for development, and migrate into an in-process solution as late in the process as possible.

[$code or die]

Just to add to\clarify some things you said:


• ActiveState has PerlEx and PerlIIS dlls - these run in-process like ASP, but the scripts you write for them are the same as standard CGI scripts written in Perl. So they are quicker, etc than perl.exe, but other than that - no difference.
• Regular expressions (based on perlre) are available now for both VBScript and JScript.
• You can write you own classes in VBScript so you can reuse objects without using OLE.

I have sometimes used the PerlIIS dll for this because it's free and in-process. If you do this - don't forget to undef\close the objects you create or they'll hang around until you kill the webserver process.

$ perldoc perldoc

[Ovid]

$code_or_die wrote:

Regular expressions (based on perlre) are available now for both VBScript and JScript.

I can't comment about Jscript because I haven't used it, but I have found serious issues with VBScript's regex engine. A regex as simple as "(\d+)(?:\.log)" has repeatedly failed for me because the lookahead keeps generating an "unknown quantifier" error with the lookahead's question mark. Since we're using VBScript 5 in my company, I should be able to use lookaheads.

Plus, no one at my shop has been able to directly access the data captured by parentheses (i.e. with $1, $2, etc.). We've read through the documentation, but to no avail. I have to set the Regexp object to match globally and then loop through the "matches" property in the Regexp object to get to them. This has been consistent on all of our machines. Either this is poor documentation on Microsoft's part, or their regex engine is fundamentally broken.

The result of this is that I have avoided regular expressions in VBScript and gone back to old ways of extracting data. Not fun!

These are clearly bugs, but I'm not expecting MS to figure out what to do anytime soon. Consider the following quote from them where they try to explain what regexes are good for:

For example, if you need to search an entire web site to remove some outdated material and replace some HTML formatting tags, you can use a regular expression to test each file to see if the material or the HTML formatting tags you are looking for exists in that file.

As I well know due to my own painful forays into this area, regexes should not be used to parse HTML. It's one of the more common newbie errors with regexes (along with "how do I match an email address"?). Microsoft has - how astonishing! - taken a great idea, broken it, and then given bad advice on what to do with it.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[$code or die]

Ok, So I moved this to meditations because it didn't fit in the "Seekers of Perl Wisdom Category.

On to your question - I have to say that I hate ASP! At my company, most people are familiar with ASP using VB script. Although people have started to get interested in Perl since I started, my current project is using ASP - and I'm writing it in PerlScript.

Once I got my head around the difference between PerlScript and Perl, I am faced with the problem that all my code looks ugly. People complain that Perl code looks like line-noise, well PerlScript is terrible - code mixed with raw html, mixed with here docs, mixed with god know what else, it makes it difficult to reuse code and very difficult to document. Also my editor doesn't quite know how to color-code the syntax!

However, there have been some benefits. In ASP with VBScript there is no built in sleep function. My colleague was going to install a component to do this, but I wrote him a nice bit of Perl that he can include in his scripts. Went something like this:

<script language=PerlScript>

sub wait_for {
   my $wait_for = shift;
   sleep $wait_for;
}

</script>

The flip side of this is that I can also use functions that my colleagues write in VBScript.

However, the whole way that ASP works seems backwards to me and makes maintaining and documenting code very difficult. I can't really speak about ASP with VBScript of JScript, but as far as PerlScript goes - it sucks. The only nice thing about ASP is the Session and Application Objects. But these can be implimented in straight Perl if you use the right modules.

$ perldoc perldoc

[tilly]

This is the wrong comparison, and anyone who is trying to sell you something based on this comparison is playing slimey games and should know it.

CGI/Apache is comparable to and should be compared to CGI with IIS. Because process startup is so heavy on NT, IIS generally loses this.

Now if you want to compare IIS running ASP with something, you should compare it with mod_perl. Performancewise if you have reasonable hardware you are limited by your connection to the internet, so performance is not an issue. Apache wins on stability, flexibility, portability, support and price. Which might just have something to do with why Apache is the market leader and IIS - despite having one heck of a marketing budget behind it - is not...

[jlawrenc]

I have written ASP code in the past. Have also written VB objects that I used in ASP pages. Gotten results using ASP.

I have write mod_perl code. Write perl modules that I in mod_perl. Get good results using mod_perl.

For me, one big disticntion between the two is that my mod_perl environment is completely Open Source. My ASP environment was a mix of open and closed source. For some that is no big deal but for me OSS is my salvation and on that basis alone I will go the Perl-mod_perl-Apache route before I will go the ASP-IIS route ever again.

The biggest disadvange that I see with the Perl-mod_perl-Apache route is that you will need to roll a number of your own pieces and strategies. Whereas the ASP/IIS world has already sorted out a few of the complicated details for you. Sessions come to mind. It is considerably more involved to set up effective session management on the Perl-mod_perl-Apache side than it is on IIS.

The big plus to counter the implementation complexity is flexibility and the chance to understand EXACTLY what's being done and where it happens in the code. As someone who has to get a job done you have to choose which path is best for your situation.

The one thing to consider is that going the OSS route may not only be better for you but I feel it is better for our society in general.