MsgBox "Done"
End Sub
On the same machine, the previous code took 12 seconds to append 50,000 A’s to a
string; with this code, inserting 50,000 A’s into a previously allocated string is
instantaneous! Clearly, the issue isn’t string handling per se but the allocation of
strings. In the GoSlow_Click subroutine, each of the 50,000 times that tstr = tstr & “A”
is called, tstr is reallocated.
The problem with this solution for ASP developers is that VBScript provides a Mid
function, not a Mid statement, which would be required for use on the left side of the
equals sign.
ASP.NET will have similar performance when manipulating strings in the same way,
but ASP.NET does allow you to use the new StringBuilder class as an alternative. The
StringBuilder class has better performance when manipulating lots of strings.
What ASP doesn’t provide is a flexible, powerful, and truly scalable programming
environment. For example, in Listing 1-3, when declaring the variable x, I don’t specify a
type. I can’t, because all variables in VBScript are the Variant data type, able to hold any
data, but not permanently a particular type. For instance, I could have said x = “duck”
and then followed that with x = 7 and that would be perfectly valid code. The lack of
strongly typed variables makes VBScript prone to all sorts of errors not seen in strongly
typed languages.
Recall that the first line in the SayHelloASP example in Listing 1-3 is an Option Explicit
directive. Without this directive, VBScript will happily create a variable the first time it’s
used. Thus, if you have a variable named x1 and you mistype it as xl (x and the letter l,
not x and the numeral 1), VBScript will happily create a new variable xl with no value.
Not needing to declare variables seems convenient. In fact, a review of scripting
languages even gave points to ASP and another scripting environment for not requiring
variables to be declared, but this isn’t appropriate for professional developers creating
reliable, scalable sites.
Another problem is the ability to mix and match standard HTML and scripting. More to
the point, the problem is the necessity to intersperse code directives within HTML. In
addition to hurting performance by requiring a context change each time a script section
is entered and exited, this intermixing code into raw HTML makes it extremely difficult to
separate the presentation from the core of the application.
A concrete example of this is the difficulty I have when working with SportSoft Golf to
create content for syndication. Syndication relies on a business model very much like
that of an Application Service Provider. SportSoft Golf provides the content. Their
customers link the SportSoft Golf site to their own sites. The actual location of the
content—whether it’s on the customer’s site or on the SportSoft Golf site—should be
transparent to the ultimate consumer of the content. To accomplish that, the content
provided by SportSoft Golf must look like the content of each of its customer’s sites.
To perform this magic of creating content that looks and feels like the home sites of
many different customers requires a separation between presentation and content.
Although this can be done using ASP, it is painfully difficult. One common solution is to
use a complex set of include files that allow content to be included separately. Using
include files alone isn’t sufficient, but it can work in combination with a complex set of
variables that allow presentation details, such as the colors for tables, to work their way
into the content.
Maintaining multiple include files and allowing the unstructured sharing of presentation
details between the files defining the content and the files defining the presentation is a
daunting task. This, combined with the real and perceived weaknesses of VBScript, has