in reply to CGI/Perl vs. ASP

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.

Replies are listed 'Best First'.
Re: Re: CGI/Perl vs. ASP
by $code or die (Deacon) on Mar 25, 2001 at 01:45 UTC
    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
[reply]
      $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.

[reply]
        Funny, I deleted my original "hesitation" about VBScript regular expressions before I posted.

        You're right, a colleague of mine was quite jealous a few weeks back when I showed him regular expressions. He looked pretty happy when he found he could use it in VBScript, but hasn't actually got it working yet.

        Cheers,
        $code or die
        $ perldoc perldoc
[reply]
        Looking at the documentation for VBScript's pattern property, I don't see any indication that the (?:) syntax is supported in VBScript. I think it makes more sense to use the VBScript reference, rather than perlre, to determine the features of VBScript.

        [BTW, (?:) in Perl is not a lookahead; it's a non-capturing group. Lookahead is (?=) and (?!).]

[reply]

In Section Meditations